Question

I’m working on a project where we’re trying to get to grips with using git in the most efficient manner (for us) and have decided to create 2 branches for 2 sub-teams to work on, along side the master branch.

Sometimes we will commit into master if it’s something generic that should go into both branches and then we want those changes in the both of the other branches.

1. Should that be a merge or a rebase into the 2 other branches?

2. Is this an insane workflow to be going down the route of? If so, suggestions please!

Answer 1

I don’t see the point of creating two branches for two teams. Work should be separated depending on its nature, not on who will work on it.

This is what I’d suggest:

• Use feature branches: Most of your work should be on these topic branches, except tiny commits (such as typos, etc.).
  When you have a feature, bug fix, or a ticket that should be processed: create a branch feat-something, and work in there.
• Use a dev, or release-X (where X is the release’s number) branch: When a feature‘s branch work is done, tested, and works, rebase it into dev.
• Never commit on master, this branch should only be rebased into by the lead developer, CTO, whatever. Rebase dev‘s work into master when you feel it’s needed.

This is (basically) how we work on a very big project. You can work without the dev branch if your project isn’t big.

Check out this famous article that shows a pretty well done workflow: A successful Git branching model.