对多个开发人员使用git分支

Question

We have a project, that has multiple developers. Each developer has his own feature branch and once the feature is complete, it is merged with master and pushed to the remote repository. The problem arises:

1. If several people are working on features and they all push their changes and one of the features is buggy. Is there a way all of the features can be pushed to a secondary master in remote, run tests and if everything goes well, push to the master in the remote?

2. Lets say all the developers are working on their feature and an emergency fix comes up, how is that best handled? It is possible that some of the developers have pushed already, but we want to push only the emergency fix?

Answer 1

Ad 1. Yes, it is possible. Just create another branch in the remote repo as the "secondary master" if you wish so. You can name it whatever you like, for example devel .

Ad 2. Our team has branch called production , which should be the exact same version of what is running on production servers and from which we are deploying. So when we need to apply hotfix, we don't have to worry about the current status of master - we just apply it to production .

I recommend to read this, at least for inspiration: A successful Git branching model

Answer 2

Those are all easy to do with git. The idea would be this:

• One master branch which is "stable"
• One staging branch which tracks master and gets the feature merges first: this is where final testing is done.
• Numerous feature branches.

If an emergency fix is done on master, this can be handled in several ways:

• cherry-pick the commit to each feature branch. You can also apply the fix to some other branch and cherry-pick from there. Cherry-picking is extremely localized, and can go across to and from any branch (in principle).
• merge master into the feature branch, including any "upstream" changes in one go
• rebase the feature branch onto master. This is essentially the previous item, with one major difference: a rebase will rewind and replay all the branch's commits onto the tip of master, so when the branch is merged after rebasing, it will have a very linear implementation history, and all the branch's commits come in a consecutive series.