Scaling up Git to Team Usage

Question

For the last 3 years I have used git on an almost daily basis for all my pet projects and at work for small projects that were not in the global SVN repository. My workflow is quite similar to the famous git branching model from http://nvie.com/posts/a-successful-git-branching-model to sum it up:

• I work in branches, one branch for one feature (I.e. not mixing up the bugfix with the new feature, etc.)

• I commit really really often, often just 2-5 lines, biggest commits are usually new functions etc. I heavily use the interactive committing tool to semantically organize my commits (i.e. while fixing an import declaration and something in a function, I tend to split that up in two commits when the changes are not related).

• Finally I tended to use git merge with the --no-ff option, because I kind of like the visual branch-history graph in gitk.

• Never really used rebasing (except for fixups)

Of course this workflow never had to face merge conflicts as serious as teams working on the same codebase face.

Now I have read here and there, that some projects are very concerned about keeping a "fast-forward" history. Why is this important? What is your choice in that respect?

I can imagine that a 'linear' history is easier to handle when looking at histories, but: It is also valuable to have the true history in my opinion. The linear history without fast-forwards is more similar to SVN histories maybe, but my git commits are usually a lot smaller than the average SVN commit, these are - I think - more comparable to a branch-merge in git (at least my usage). Working without -no-ff would kind of "clutter" the history in master (This is my concern about fast forward merges).

Answer 1

There are some common best practices when working with a shared Git repository. The ones I am familiar with are these:

• One commit per feature
• No commits that break the build
• Try to rebase everything onto the master branch

How different teams work may vary, so I don't think there is a single answer to this question. Different teams will choose to be less strict about breaking the build for example.

The main thing, in my opinion, is to try to always leave the repository in a working state. Your co-workers should be able to check out any commit and start working from there without build problems or other obvious bugs. Build and test everything before commit.

To have a good overview of a shared repository it is a good idea to only add one bugfix or new feature per commit. Some features do need more commits but then the commits should be organized per sub-feature if possible (for example one commit could add new API endpoints needed for feature X, then another commit adds the actual feature in the frontend application). This also helps with not breaking the build, as half-implemented features are bug magnets.

Having a linear commit history simplifies a lot of things but is not required. I think this will vary a lot between projects. Some will likely require you to always rebase your changes on the tip of master, while others will accept feature branches. Having a linear history helps immensely with keeping track of build/version numbers. Git describe can be used without the short hash if you have a linear history, for example.