Other people's git workflows

• https://speakerdeck.com/ewoodh2o/release-management-git-workflow
• http://zachholman.com/talk/how-github-uses-github-to-build-github/
• http://nvie.com/posts/a-successful-git-branching-model/
  • https://github.com/nvie/gitflow
  • http://dev.datasift.com/blog/hubflow-github-and-gitflow-model-together
• http://scottchacon.com/2011/08/31/github-flow.html
  • http://news.ycombinator.com/item?id=2946118
    • http://news.ycombinator.com/item?id=2946942
• http://git-scm.com/book/en/Git-Branching-Branching-Workflows , http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
• http://www.reddit.com/r/webdev/comments/z2jk2/best_git_workflow_i_have_found_so_far/
• https://sandofsky.com/blog/git-workflow.html
• http://sethrobertson.github.com/GitBestPractices/#workflow
• http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
  • http://news.ycombinator.com/item?id=4612331
• http://semver.org/ (not git-specific)

Notes on my current favorite git workflow

i like https://speakerdeck.com/ewoodh2o/release-management-git-workflow for small projects, or, for projects where there is a separate release manager or ops team, a variant of this where 'develop' and 'master' are two separate repos (the motivation being so that you can have different access control on each repo; the 'develop' repo is 'owned' by the lead dev, and the 'master' repo is owned by testing/ops; this encourages testing/ops to take a hard line when the lead dev and testing/ops disagree on how strict the criteria should be for the transition from staging to release).

Also, why not use --no-ff when merging develop into master? Not sure i understand the reason for not doing that. I'm going to try it someday.

Notes on the git commands needed to do various things in this:

Merge/rebase

The short of it is: if you are the lowest hierarchical level in a tree of development branches (i.e. a single person's working branch), then always rebase when you pull from higher levels of the hierarchy. If, however, you are not the lowest level (you are someone else's upstream), then merge.

Details and discussion

• rebase when pulling from master
• merge when going up in hierarchy
  • http://gitguru.com/2009/02/03/rebase-v-merge-in-git/ -- this also suggests to rebase when going down in hierarchy, but the below suggests otherwise
• don't rebase anything that others have pulled
  • http://lwn.net/Articles/291304/
  • "Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history." -- man git rebase
  • http://changelog.complete.org/archives/586-rebase-considered-harmful
• if you have a hierarchy with team integration branches in the middle, those branches should NOT be rebased! because the whole point of those branches is so that everyone on the team is pulling from them.
  • ""You are supposed to clean up your history before you make it public": Yes (with caveats), but this only addresses patch atomicity. It does not address synchronization, which is the real problem. "it makes it easier for others because you have designed your patches for the head of the upstream repository": And so has every one else. And when patches which conflict with yours get merged first, your patch no longer applies. What to do? As it scales up you need middle men. They are a synchronization point for folks working on the same area of code. It has to be public or synchronization can't happen. But what if you find a bug in this amalgamation? Rebase? It's not yet gone upstream, it's still being worked on. Do you push a patch upstream which you know to be bad, along with a patch which fixes it, or do you rewrite history.T he point is it's a tough decision and people are making the wrong one. They're rebasing. And that fucks things in about half a dozen ways, as outlined by Linus." -- http://www.reddit.com/r/programming/comments/6ube0/synchronizing_development_rebase_vs_pullmerge_git/?sort=top
  • "I thought it was always pretty obvious that rebasing is only for the lowest levels of this heirarchy." -- http://www.reddit.com/r/programming/comments/6ube0/synchronizing_development_rebase_vs_pullmerge_git/?sort=top
  • ""why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer."http://kerneltrap.org/Linux/Git_Management

Protecting github repos

" A remote repository can disable such operations with the setting receive.denyDeletes to prevent any ref deletion, and avoiding non-fast-forward branches with the receive.denyNonFastforwards. If either of these are set, then deletes have no operation and pushes cannot overwrite code which doesn’t strictly follow it in history. (This is occasionally a useful operation; it may be necessary to provide a means to elevate this in certain situations if necessary.) " -- http://alblue.bandlem.com/2011/11/git-tip-of-week-gc-and-pruning-this.html

Tools

• http://www.git-legit.org/
• http://blog.datomic.com/2012/10/codeq.html

Links

Intros

• http://git-scm.com/book http://gitimmersion.com/
• http://www-cs-students.stanford.edu/~blynn/gitmagic/
• http://www.slideshare.net/pbhogan/power-your-workflow-with-git

Hubs

• https://plus.google.com/103751101313992876152/posts/XRT3CsuwBTo

Cheatsheets

• http://web.archive.org/web/20130118164335/http://cheat.errtheblog.com/s/git
• http://www.ndpsoftware.com/git-cheatsheet.html

Misc advice/tips

• http://andyjeffries.co.uk/articles/25-tips-for-intermediate-git-users
• http://metacircus.com/hacking/2011/02/18/play-git-like-a-violin.html

Random useful answers to questions or gotchas

• http://git-scm.com/2011/07/11/reset.html
• http://gitguru.com/2009/02/03/rebase-v-merge-in-git/
• http://stackoverflow.com/questions/1419623/how-to-list-branches-that-contain-a-given-commit?lq=1
• http://stackoverflow.com/questions/7131703/how-to-know-which-branch-a-git-log-commit-belongs-to
• http://stackoverflow.com/questions/3133449/why-does-git-rebase-give-me-merge-conflicts-when-all-im-doing-is-squashing-comm
• git log --first-parent
• git config gc.pruneExpire never

links

See also notes-computer-programming-git