0

I have a parent branch and child branches.

when I want to merge a child branch into a parent branch , it's said that Re-basing the branch is the best way to merge.

If we're rebasing all the changes made in the other branch will come into the current child branch right ?

Then when someone wants to see what are the new changes made in the child branch will have the changes of the other branch too right.

Can someone throw some light on Rebasing vs Pull request vs Merge ?

I'm trying to find the best way go about merging the branches.

Dan Ram
  • 151
  • 1
  • 14
  • 1
    *"when I want to merge a child branch into a parent branch , it's said that Re-basing the branch is the best way to merge"* This, as a sweeping statement, is profoundly misleading. Rebase and merge are different operations, with different usages, and none does the other's job. – RomainValeri Nov 13 '19 at 08:54
  • I thought rebasing gives good git history line diagram with the benefit of merging. where as merging is just merging the source code – Dan Ram Nov 22 '19 at 02:12
  • Define "a **good** git history". What would it even mean? The only important characteristic of a *history* is to be truthful, or else it's just a story, pretty or not. – RomainValeri Nov 22 '19 at 07:31

2 Answers2

3

First of all, based on my experience, if your scenario is the team(multi people) is developing the branches at the same time. Then Rebase will not suitable for that. Because if one of your colleague execute the rebase, it can modify all commits. Meanwhile, if another person is developing this branch, it is very likely that the public parent node could not be found, and the commit could not be submitted.

rebase can make the history more clear(one line), but merge not.

Rebasing vs Pull request vs Merge

  • Pull request

Pull request just used to raise a request to decide the way on how to "solve" commits between branches. After the pull request raised, you can decide the strategy on which merge type you would choose.

For better explain the Rebase and Merge, here I set the scenario first:

Assuming that you have two branches, master and develop. develop is the branch that is pulled from the master at (3.added merge.txt file)commit:

enter image description here

And now, set HEAD is at 6.added hello.txt file, which is the most recent commit of the master branch.

  • Merge

Based on the above scenario, execute git merge develop. Below is the result shown:

enter image description here

The Git will do a Three-way merge automatically by following the common ancestor of the two branches (3.added merge.txt file), the latest commits of the two branches (6.added hello.txt file) and (5.added test.txt file). Then a new commit will generated based from the modified content in the merge, that is, commit 7. Merge branch 'develop'. This is the effect of the merge, which simply merges the two branches and generates a new commit.

  • Rebase:

Also, based on the above scenario, execute git rebase develop. Below is the result shown:

enter image description here

You can see that the develop branch and the fork are disappeared.

When performing a rebase operation, git will extract the changes(6.added hello.txt file) from the current branch(master), and this changes is start from the common ancestor of the two branches(3.added merge.txt file).

Then let the master branch points to the latest commit(5.added test.txt file) of the target branch develop . And apply the changes which extracted just now to this latest commit.

If there are multiple changes to the extraction, then git will be applied to the latest commit in turn. As shown in the following, left is the initial state, and right is the state after the implementation of rebase:

enter image description here

In one word, the git rebase extraction operation is a bit like git cherry-pick(just similar, but not same). After rebase executed, it will cherry-pick the current commit sequentially, and then sent to the target branch. After that, the extracted commit on the original branch is deleted.

Summary:

You can see that the result of the merge can reflect the timeline, but rebase will disrupt the timeline. Both of them can all achieve code combined, just for public branch, like master, do not suggest use Rebase.

Also, the trouble for merge is roll back commit node. But for rebase is after rebase is finished, you will not know where you pulled out the development branch, this is what I mentioned disrupt the history timeline.

Merlin Liang
  • 13,166
  • 1
  • 7
  • 18
  • For a bigger team of 6 people what would be the preferred way of combining two branches.... Merge or rebase ? – Dan Ram Nov 22 '19 at 08:05
  • 1
    @DanRam, **Merge** is better. This could keep a very completed history which benefit for team leader to check. – Merlin Liang Nov 22 '19 at 08:06
  • Thanks for your valuable feedback :) I appreciate it. If you don't mind , why would merge be a better option than rebase ? I didn't the understand the term "Completed history which benefit for team leader to check" do you mean teamleader can't check completed history if it's rebased ? I think even in rebase we get one git history line right ? for team leader to see ? I read somewhere if we rebase it may afftect the commits done by others as it would alter... so does that mean merge would not affect those previous commits ? – Dan Ram Nov 22 '19 at 08:22
  • So far we have neve done any rebase and the project is running with Merge only but would it be a bad idea to move towards rebase now ? could it alter previous commits ? is there any advantage rebase provides over merge command ? – Dan Ram Nov 22 '19 at 08:23
  • 1
    @DanRam You could refer to the pics I shared in my answer. If I am a team leader, I want to clearly know the completed history about this repos. **Merge** can let me know "ohh, at node 7, someone create a branch from master and made 3 commits in that feature branch. Then merge them back at node 10", see second pic. Yes, **rebase** can also let me know the completed history. **BUT**, what it trouble brought is I will never know what happened on this repos before.I just know "oh, there are commits here". Not sure it is easily to understand, I think it's better if we can talk it with some pic. – Merlin Liang Nov 22 '19 at 08:39
  • @DanRam. For whether it is bad or good, this depend on your team. The advantage of Rebase is its history is very clean, it is a straight line. Also, if you want to roll back to some specific node, it would be very convenient. – Merlin Liang Nov 22 '19 at 08:41
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/202865/discussion-between-dan-ram-and-merlin-liang-msft). – Dan Ram Nov 22 '19 at 09:07
1

My advice is to get experience using both rebasing and merging. Then you will know what suits you best. It also depens on how many people are working on the project and their git knowledge. If they are not experienced with git usually merging is the best option.

Personally I prefer rebasing and keeping the repository history clean.

And, a pull request is a method of submitting contributions to a project and it is just a different thing from the ones mentioned above.

yanislavgalyov
  • 161
  • 8
  • Hi , how pull request is different from Merge or rebase ? without doing any merge or rebase request...I'm able to Merge two branches using Pull request. Can you explain more please – Dan Ram Nov 22 '19 at 02:04
  • There are 6 people working on the project. Would rebasing not preferrable for bigger team like this. If yes or no, could you please explain me the reasons – Dan Ram Nov 22 '19 at 08:02
  • @DanRam, 6 people is a small team and can easily go with the rebasing strategy. As for pull request this is just a mechanism to merge code *with review*, behind the scenes it is a simple merge. (and again, you can rebase your branch and create a pull request, not sure how to explain it, just try it with your own repository) – yanislavgalyov Nov 26 '19 at 10:53