I am currently working on featurex
branch. Our master branch is named branch our-team
. Since I started working on featurex
, more changes h
For other people coming upon this post on google. There are 2 options, either merging or rebasing your branch. Both works differently, but have similar outcomes.
The accepted answer is a rebase. This will take all the commits done to our-team
and then apply the commits done to featurex
, prompting you to merge them as needed.
One bit caveat of rebasing is that you lose/rewrite your branch history, essentially telling git that your branch did not began at commit 123abc but at commit 456cde. This will cause problems for other people working on the branch, and some remote tools will complain about it. If you are sure about what you are doing though, that's what the --force
flag is for.
What other posters are suggesting is a merge. This will take the featurex
branch, with whatever state it has and try to merge it with the current state of our-team
, prompting you to do one, big, merge commit and fix all the merge errors before pushing to our-team
. The difference is that you are applying your featurex
commits before the our-team
new commits and then fixing the differences. You also do not rewrite history, instead adding one commit to it instead of rewriting those that came before.
Both options are valid and can work in tandem. What is usually (by that I mean, if you are using widespread tools and methodology such as git-flow) done for a feature branch is to merge it into the main branch, often going through a merge-request, and solve all the conflicts that arise into one (or multiple) merge commits.
Rebasing is an interesting option, that may help you fix your branch before eventually going through a merge, and ease the pain of having to do one big merge commit.