Question

I have recently started developing a new library, and use Git for revision control. I decided to follow the immensely popular blog post A successful Git branching model to manage branching. It is about time for me to make my first release, and I would like some advice on managing specific sets of files as I describe below.

On the develop branch and feature branches, I want all the “supporting files”, such as the makefile used for compilation and the readme.md file used by doxygen to generate documentation. (Note these are just a couple of examples. I have many more “supporting files”.)

The blog post also says that a commit to master branch is a release by definition. I want the release to include all the “binary files” (which includes, for example, the object files resulting from compilation and the html files containing the documentation). These files should be committed to the master branch, so that customers could just clone from the repository with the tag and get the required release.

I prefer not to have the “supporting files” in the release (since I don’t want to give the customers heaps of files they don’t want or cannot use). Similarly, I prefer not to have the “binary files” be version-controlled in the develop and feature branches. Thus, I want to commit one set of files to develop, and another set of files to master. (Of course, there’s also a set of files which are “common” to both branches.) However, I am skeptical about keeping the master and develop branches out of sync as just described.

Does my proposed model sound good? If so, how should I deal with having different files committed to develop and master? Is there a better way to handle this situation?

I have gone through each one of the comments on the said blog page, searched the internet, and also searched here on StackOverflow. From the search results, this post GIT repositories with some different files seems to be the only one anywhere close to my question. Neither of these helped me figure out the solution.

Answer 1

IMO the proposed solution is not good. A common solution to your problem is:

• version control all “supporting files.” If you care whether these file are modified or deleted then they should be under version control
• don’t version control “binary files,” if they are simply generated by the compilation process. The code that is compiled and the Makefiles are what matter. You might possibly have binary files in say a ‘bin’ folder if they are used to compile the code.
• create a build process around the package that you want to deliver to the client. You can either build a package for the client which they can access, or you can have them run your “package script” themselves. The “package script” can clone the repo, build the package, and delete the repo just by executing it on the command line.

To learn more about the git branching model and and how they apply to development check out http://git-scm.com/book/en/Git-Branching