gitworkflows – how exactly to graduate a branch?

I have a git branching model pretty much like the one described in gitworkflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html and here http://members.cox.net/junkio/git/MaintNotes.html

I have some doubts about how exactly to graduate a branch and what to do with commits that fix bugs that only happen when 2 different branches interact.

  • git merge with --no-ff and --squash
  • Tag multiple branches in git?
  • What does git config do?
  • My git branch on github should be only 2 ahead but it is also 2 behind
  • Pushing updates to a pruned Mercurial branch
  • How can I review or secure remote branch deletions?
  • Specifically, I have these branches:

    • production: exactly the same as what’s deployed in our production server

    • hotfixes: forked from the tip of ‘production’, where I fix bugs and later fast-forward ‘production’ to it (and re-deploy)

    • several feature branches: every new feature is created in isolation

    • test: where I merge every feature branch that’s mature enough

    • all: where I merge every feature, no matter how new or untested it is

    Say I merge feature branches F1 and F2 in that order into ‘test’. It turns out that they don’t play nice together, so I commit fixes C1 and C2 (directly into ‘test’); I later merge a third branch F3 and continue committing fixes for bugs that happen because of these branches not interacting well (if I found a bug in one specific feature, I would fix it in it’s own branch and then re-merge). I later want to graduate only F2, because F1 and F3 are not ready yet (or because the client is on a whim), so I merge that branch directly into ‘production’.

    What to do next?

    • What to do with the bug fixes that were in ‘test’ that involved F2 interacting with F1 or F3 (like C1 and C2)? Do I cherry-pick them into the corresponding not-yet-graduated branch? Wouldn’t this be a bit too much manual work?

    • What about ‘test’? Do I discard it and build it again from the new tip of ‘production’? If so, how to avoid losing the bug fixes for branches that aren’t yet in ‘production’? cherry-pick again? Is there a way to update ‘test’ that does not require reset/rebase?

    • Would it have been better to revert the merge(s) of F1 and F3 into ‘test’ and once I have only F2 in there, merge ‘test’ into production’? Note that this model also requires me to revert the bug fixes that relate to the branch I’m reverting.

  • For how long can you restore/recover a deleted branch on GitHub?
  • How to transplant patches in svn
  • Find all the commits there are in lab branch but in master branch
  • Pushing to Git from webstorm
  • How can I use version control in a more powerful way?
  • How to limit pushing operation to allow only commits that are signed with GPG in github
  • One Solution collect form web for “gitworkflows – how exactly to graduate a branch?”

    The complexity of this model comes from the common branch ‘test‘, where too much operations are done.

    I would rather:

    • isolate the current “integration in progress” F1+F2+F3 in its own branch ‘integ
    • reset test on prod (provided everybody is clear on the consequence of a reset, and is ready to reset his/her own local cloned branch test).
    • merge integ on test (getting back all the work done on those three features, but based on prod)
    Git Baby is a git and github fan, let's start git clone.