git commit different set of files to develop and master

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

Answer 2

With git-flow the master branch holds the tip of the latest release, the flaw in that statement is when you work on software that requires compilation.

In that case the master branch is the source release branch from which you create the actual release. If you look at the branching model this by definition you would need all your supporting files in the master branch as well. That way you can always create the binaries of the latest release.

In your case, you say that you don't want the customer to have a bunch of files they don't need which means you need some extra work after you do a release. In git-flow terms, after you do a git flow release finish, you need to do an extra step of compiling your release. The result of the compilation should not be under revision control. With the original git-flow software you need to start the compilation process by hand, if you use my fork, git-flow (AVH Edition), you can actually do this automatically by using hooks.

I'm willing to say that 99% of the projects on github, that require some sort of compilation have all their supporting files in the master branch as well.