Revision history [back]

I could place these packages in separate git repositories, but I feel that would be inconvenient as the number grows and as many of them will be very application specific.

All packages in a single git repository must be released together. So if you find a bug in one package and would like to release a new patch release you will need to release the other packages in the same repo too even though they havent' changed.

It basically comes down to how closely related the packages are. If they are tightly coupled you should keep them in a single repo. If they are not (e.g. the packages are for completely different and unrelated application) you might better keep them in separate repos.

Should I place the src folder in git instead? What about the CMakeLists.txt file then? I guess that file is system specific.

No, the workspace itself (the src folder and the CMakeLists.txt file in the root of the source space) should not be part of your repository. The rational is that users might want to clone your repository together with other repositories and build them together in a workspace. That wouldn't be possible if your repo already contains this. Also the CMakeLists.txt file only applies to the case when you are using catkin_make. But there are other build tools (e.g. catkin_make_isolated and catkin_tools) which don't use that file.

Or do you recommend to make the full work space folder as repository and just make git ignore the build and devel folders?

Neither nor. You either want: * package_a, package_b, and package_c to be three separate repositories or * if of put all three packages into a single repository clone that repo in your src folder:

workspace_folder/
  src/
    repo_containing_pkgs/  <-- git repo
      package_a/
      package_b/
      package_c/

The src folder should always be created by the user when he creates a workspace and decides what sources to put into that workspace.

For each solution I am interested in the instructions that a new developer would need to checkout and build the application. For instance I am somewhat in doubt about what catkin (e.g. catkin init work space) does behind the scenes and how much of this should be in git.

The workflow usually looks like this:

• The user creates workspace_folder/.
• The user creates workspace_folder/src/.
• The user populates the source space of the workspace with whatever packages he wants to build. There are multiple options how to do that:
  • The user manually calls git clone / hg clone / svn checkout / <download a="" tarball="" and="" unpack="" it=""> / whatever else you want to imagine.
  • The user uses the tool rosinstall_generator to collect a list of repositories and uses a tools like wstool or vcstool to fetch a set of repositories. This can e.g. be used to build a full ROS distribution (see from-source instructions).
• Build the workspace with any of the build tools (catkin_make, catkin_make_isolated, catkin_tools).

If you don't want users to build your packages from source all the time you can also release your packages to provide binary packages of it. That way users can just install the Debian packages using apt install ros-kinetic-your-pkgnames.