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:
development_branchfeature_a in this example)feature_a branch until task completedevelopment_branchfeature_a into development_branchdevelopment_branch local to originNow that works fine, everyone is happy, however take the following scenario where you want to pull more regularly:
development_branchfeature_b in this example)feature_b branchdevelopment_branchdevelopment_branch origin into localfeature_bdevelopment_branch local into feature_bNow 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.
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.