How many branches should I have ? How do I know it?
We have 1 master branch before we released to customer.
Now, we’re at the bug fixing state, and we also want to continue working on new feature.
How many branch should we have to minimize the conflicts between developers ? 3 or 2 ?
I’m thinking 3
- Bugs Fixes
Any suggestions on this will be much appreciated ! I’m open for any advice.
3 Solutions collect form web for “How many branches should I have ? How do I know it?”
The way our workflow works is this:
Every time we add a feature or fix a bug, we create a new branch, appropriately named. (i.e. “redirectFix” for a broken redirect)
We create a pull request to our development, and someone on the team tests to make sure it works.
We merge to the development branch, and erase the specifically named branch.
We ensure everything on the development branch works, and then we push to the master branch.
Doing everything in small branches like this helps minimize conflicts, and make them quite easy to fix, in my opinion.
The benefit of git (e.g., with respect to SVN) is that creating and merging branches are easy and cheap operations. Therefore, you can ideally have one local branch for each new feature under development/testing. Then, you need one additional local branch synchronized with the remote production repository on the server, to ease local merging and push new features once they become ready.
There is no single best answer, it depends a lot on the company and the setup (testing, staging, etc.).
Atlassian has a nice page that compares the workflows, you may want to take a special look at the Gitflow Workflow:
The general idea is that your master is for complete releases only, the development is the one you’re developing in, but every feature or bugfix gets a separate branch. They cost close to nothing.