Best way to manage local feature branches with git?

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/

  • How can I use git for projects templates?
  • git workflow for keeping custom-modified open source software up to date?
  • Git: Deny deleting remote branch via push (like receive.denyDeletes), but only if branch is not fully merged
  • Merging one change to multiple branches in Git
  • Override author on git merge
  • Git: How to be sure untracked config files aren't silently deleted
  • 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.

  • Dockerfile strategies for Git
  • setting the work-tree of each bare repo
  • How should I use the git branches?
  • Git pull fails : unable to update local ref
  • What happens in the child branch if I delete a parent branch in git
  • Sad story - git+ssh+ruby
  • One Solution collect form web for “Best way to manage local feature branches with git?”

    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.

    Git Baby is a git and github fan, let's start git clone.