问题
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.
Should that be a merge or a rebase into the 2 other branches?
Is this an insane workflow to be going down the route of? If so, suggestions please!
回答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.
回答2:
It depends whether these are 2 separate projects sharing some common stuff; if so then make a separate library and use submodules - instead of stuffing everything in one repo.
Otherwise I would advise against approach described. It might come to the point where those two branches have diverged so much that merging them might become almost impossible. Since git is a distributed system make all main development on master, create branches on as-needed basis per feature implemented and merge often. Use tagging to mark important development milestones.
回答3:
Reversing:
2) No it is not an insane workflow. Your subteam members presumably have their own repositories and branches. When the subteam has a stable product they push it to their branch in the main repository. The integration lead will then take what is on a sub team's branch in the main repository and merge/rebase into master if appropriate (as you say something to be shared).
1) So assume that subteam A and B both branched off of master at Tag-M1 and that subteam A's work is now back on master at Tag-M2. Meanwhile subteam B has moved along to Tag-B2. Should you rebase or merge onto branch-B. I think you want to avoid rebasing branch-B off of Tag-M2. Your subteam B members are pulling from branch-B; when you rebase you will be changing the history on branch-B which will complicate subteam-B pulls.
Note that your subteams might prefer 'git pull --rebase' when updating from the main repository.
来源：https://stackoverflow.com/questions/10598262/git-workflow-with-3-branches-advice