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 mergewith the
--no-ffoption, 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).