1

I am looking at some of the finer points of branch management with git and was basing a few of my decisions around this article:

http://nvie.com/posts/a-successful-git-branching-model/

Now we have a slightly simpler scenario here, remotely on origin we have master and development_branch. As far as all the developers are concerned development_branch is the main place to clone from, and we only merge from development into master when we have a stable release.

Now with that in mind we have a bunch of stories each sprint which we need to get through, so what we currently do is clone development_branch then make a new branch for that story/feature we are working on, such as product_description_feature. This local branch is then worked upon so if we need to pick up another task or do a fix of some sort we have the clean development_branch to return to and branch from.

Now the question comes around the process to work this way, currently the safe option seems to be the following process:

  • Clone development_branch
  • Create new branch for the task (we will call it feature_a in this example)
  • Commit into feature_a branch until task complete
  • Switch to local development_branch
  • Pull any new changes from origin down (usually a frequent thing anyway)
  • Merge changes from feature_a into development_branch
  • Push development_branch local to origin
  • Create new branch for the next task

Now that works fine, everyone is happy, however take the following scenario where you want to pull more regularly:

  • Clone development_branch
  • Create new branch for the task (we will call it feature_b in this example)
  • Commit into feature_b branch
  • You realize a blocker and have to pull latest changes
  • Switch to development_branch
  • Pull development_branch origin into local
  • Switch to feature_b
  • Merge from development_branch local into feature_b
  • Continue working until done

Now that seems safe and everyone is happy, however I am not sure if I NEED to switch to development_branch and pull down then switch back and merge into my local feature branch. So am I just being overly cautious here and should just pull from development_branch origin into local feature_b branch?

This seems like it should be fine to do as all i'm doing is taking the changes directly into my local feature branch without updating my local development_branch, then if i were to need to push changes I would again switch, pull, merge, push.

So can someone confirm if this is good practice or not etc?

Also without polluting the question too much, as these feature branches only exist on each developers machine, what happens in the case of someone half doing a task, then someone else needing to pick it up? You can push that branch to origin and let them take it down then work on it, but then it would require cleaning up further down the line, so I assume there is no nice way to solve this problem but I would be interested in hearing how other people solve the issue without creating a wasteland of out of date feature branches remotely.

A couple of other things to mention, we are currently just ffwd merging, so although in the original article cited it mentions NOT ffwd merging I cannot see how you can do this without creating a HUGE amount of remote branches. I am using Tortoise GIT rather than command line, however this should not really change anything.

Grofit
  • 17,693
  • 24
  • 96
  • 176
  • To me, one of the main reasons to go with a distributed revision control system like GIT is to avoid getting into branch/merge hell. Personally it sounds like your team is doing way to much branching as opposing committing early and often to the mainline. Of course we also employ continuous deployment and code review before pushing changes to central repo. – Mike Brant Apr 05 '13 at 15:52
  • 1
    Branch in git are just lightweight pointers referencing a commit. Although you might end up with a lot of feature branches by having them on the remote repo, it does not add any significant overhead. You could indeed delete and get rid of the feature branch after the feature is merged into your `development_branch`. Another acceptable practice is to use rebase for adding your (unpushed local) changes on top of changes from the remote when you synchronize, and then push your new rebased changes back to avoid extra merges in the history and have a more linear one. – Tuxdude Apr 05 '13 at 16:15
  • @mike-brant You are right, one of the reasons we moved to git is to remove the merge and branching nightmares of non distributed VCS. However as it becomes easier to branch and merge it makes it easier for you to make better use of branching and merging. I agree with pretty much everything the author of the article linked to says in that using his way (for right or wrong) which is why I am advocating working this way. We don't really bother with code reviews, as we have an environmental build script which runs a suite of unit, integration and acceptance tests so if they pass good to go! – Grofit Apr 06 '13 at 09:00

1 Answers1

2

If you want the latest updates from another branch, you can skip the two branch switches.

git fetch
git merge origin/development_branch

As for your questions regarding workflow, it's all a matter of policy. My place of work uses project branches, and we just take it upon ourselves to clearly spec out their lifespans. We know when a branch is born, and we know when it needs to die. This is the benefit of using the -d flag to delete branches.

git branch -d feature_branch

By doing it this way (and not with -D), you can ensure that the branch has been merged back into the mainline. It will stop you otherwise. So, you can be fairly liberal with this delete command.

TheBuzzSaw
  • 8,648
  • 5
  • 39
  • 58
  • Yeah as we are using ffwd merging its not like its an issue if we delete the branches after they are created if they do somehow get onto origin. – Grofit Apr 06 '13 at 08:56