CODEWITHSUNDEEP
gitmergerebase
Łukasz Szkup
Łukasz Szkup

Reputation: 117

Git rebasing process

At work I was told that I should always try to rebase rather than merge when using Git. So far I'm not very happy with that approach as merging has always been easy, usually generating fewer conflicts and reflecting the real natural way of how the code was developed (in branches). Rebasing usually causes tons of conflicts and makes the history of changes linear which does not reflect the reality.

Anyway, the guy who asked me to do it, showed me the process I should follow to reduce to number of conflicts:

  1. create a branch
  2. do a few commits
  3. rebase on top of master and solve conflicts
  4. push

Now, he also asked me to do the following each day before continuing my work on that branch:

  1. rebase on top of master as the first thing in the morning
  2. do a few commits
  3. rebase again and solve conflicts
  4. push

The most frustrating part is point #3 as even when my commits are really small, the number of conflicts at this point is massive.

When I asked another workmate for advice, he told me that we should not rebase more than once and that's why I have that nasty conflicts. But in this case, if I get back to a branch after some time, I may not remember if have already rebased or not. That's why I always prefer merging which is easier and it's hard to go wrong.

Anyway, if I still wanted to stick to the request of using rebase, what would be your advice? What is the "correct" process I should follow in my case when I come back to an old branch that has already been rebased? Or how to easily detect whether it's already rebased if I should not rebase it multiple times?

Upvotes: 1

Views: 49

Answers (1)

Allen
Allen

Reputation: 4749

$ git config rerere.enabled true

Rerere (reuse recorded resolution) could be your friend :]

Upvotes: 2

Related Questions