Since Frogatto & Friends moved from its own SVN repository to a Git one on Github, some people have got confused by the appearance of true merge commits in history due to them working on their master branch directly, pulling from upstream and pushing again. I don’t personally think that this is the best workflow, but for former SVN users it appears to be the most suitable transitional option.
But Git isn’t a 1:1 equivalent solution — and I won’t get too deep into that subject, so I’ll explain instead what the method that works best for Frogatto (without merge commits!) at the moment is.
$ git config branch.master.rebase true $ git config rebase.stat true
The first line sets a configuration option that tells Git to try rebasing our local master against upstream after using git pull on it. The result of a rebase operation is that local commits not merged upstream are temporarily removed from history, the branch is reset to its previous diversion point, fast-forwarded to the new upstream HEAD, and the local commits are then rewritten on top, giving the user the choice to solve conflicts by hand as they appear, should they appear at all. The second line makes automatic and manual rebase operations to display a summary and stat display of changes merged in the fast-forward operation. I’m not entirely sure why this is not the default; normal fast-forwards and true merges (controlled by the merge.stat option) on git pull and git merge already do this.
See also git-rebase(1) for further information on what the rebasing procedure entails.
Once the configuration is adjusted with those two lines, it’s safe to git pull right away and later git push once everything is ready for committing to the Github repository for everyone to see.
For Frogatto’s SVN-inspired linear approach to history this means that merge commits won’t be generated and they won’t pollute history and confuse people who are not used to distributed version control systems.