-1

The sequence of operations is

  1. Branch
  2. Do work on branch
  3. Master had commits by other people
  4. Rebase on master to "merge" in changes from master
  5. Do a merge into master

These steps I understand. But what if I want to reuse this branch in case there are some other changes later related to this branch?

  1. Master has commits by other people
  2. Rebase branch on master OR merge in master to branch ???

QUESTION

Should I do a merge or rebase?

Bob
  • 4,128
  • 4
  • 22
  • 75
  • 2
    There are endless articles about the two approaches. I suggest you going through some of them, they'll give you a good idea about the difference. – Maroun Nov 19 '19 at 16:03
  • Probably a duplicate: https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions?rq=1 – isherwood Nov 19 '19 at 16:04
  • This is something of a personal preference, but if you rebase your branch it might seem cleaner assuming there aren't merge conflicts. In that case, a merge commit might be cleaner. At a certain point, a branch can become too far gone and sometimes I just manually reapply the changes in a new branch from master. It loses the history though. :-/ – SapphireSun Nov 19 '19 at 21:02

2 Answers2

1

This is mostly a matter of preference and situation. Rebase requires a forced update to remote, so I rarely use it. In most cases, merging in Master gets you what you need without blowing up the remote branch (at every place it's being used).

Rebase is useful when you want to clean up your feature branch's history and no one else is using the branch. It keeps all the commits to master out of the feature branch's commits.

isherwood
  • 46,000
  • 15
  • 100
  • 132
  • 1
    But if I'm the only one using the remote branch, it shouldn't matter? – Bob Nov 19 '19 at 16:04
  • Another big rebase benefit is creating a single clean stack of commits for future readers. Reading repeated merges into a branch can be a nightmare b/c readers also have to understand all the changes in `master` over the branch lifetime. – Kache Nov 19 '19 at 21:39
  • That's sorta what I was referring to with my second paragraph. – isherwood Nov 19 '19 at 22:09
0
  1. Branch : branch1
  2. Do work on branch
  3. Master had commits by other people

3.a. git checkout -b branch2ForFuture --> Creates another branch. Branch from branch1

3.b git checkout branch1

  1. Rebase on master to "merge" in changes from master
  2. Do a merge into master
  3. branch2ForFuture is available for future work However Step 4 needs to be repeated every time you need to merge your changes in master. and trust me, it is big pain
Tilak
  • 27,830
  • 17
  • 73
  • 125