CODEWITHSUNDEEP
gitmergeworkflowrebase
nowox
nowox

Reputation: 29096

What strategy to push and rebase a living branch?

I would like to understand whether or not the use of a rebase strategy on a already pushed branch is a good solution to keep the master's log history clean.

The situation is that I am developing a feature on an existing project and I am the only developer on this particular feature. However, I do not want to keep it local until it becomes ready to merge. Instead, I want to regularly push my work to get feedback and give possible inspiration to my colleagues.

Unfortunately, during the development the master is also evolving. To avoid my branch diverging too far from the master I can either decide to merge or rebase it with the master.

Because rebasing is rewriting the history, the community (SO) is usually discouraging me of doing so. Especially when I have already pushed some of my work. Despite these recommendations I feel that rebasing my work on the top of the master is sometime still the correct way to do.

Let's imagine my work after few weeks in both situation with rebase and a more usual merge strategy:

Solution with merge                Solution with rebase

G    master origin/master              n feature origin/feature
| e  feature origin/feature            m
F/|                                    l
E |                                    k
| d                                   /
| c                                  G master origin/master
D/|                                  F
C |                                  E
| b                                  D
| a                                  C
B/                                   B
A                                    A

When the final merge comes, dragging the full history of my development back on the master will lead to a complex log, sometime hard to read.

The rebase solution leads to an easy fast-forward merge and eventually to a cleaner log. 

H    master/origin/master
G \    
| e                                  n master origin/master
F/|                                  m
E |                                  l
| d                                  k 
| c                                  G 
D/|                                  F
C |                                  E
| b                                  D
| a                                  C
B/                                   B
A                                    A

However, this solution does not come without pitfalls. Other developers must follow some rules if I don't want to be hated by anyone.

  1. A branch named feature/<name>-u (for unstable) may sometime be rebased on the top of the master
  2. On these branches, no official releases will be made
  3. I must never commit on the top of a foreign feature branche

What other point should I worry about?

Of course there is a third solution which is to squash the feature as a one commit on the master which can be an alternative to this workflow. This is good for keeping the feature clean on the master, but it does not help for keeping the feature branch clean.

Upvotes: 0

Views: 76

Answers (1)

Marcelo &#193;vila de Oliveira
Marcelo &#193;vila de Oliveira

Reputation: 22321

I think you should use the "merge" solution. Do not rewrite history because you never know if someone has based in your "old" commits and this could lead to a big mess in the future. The history graph in the "merge" solution is clear enough to understand specially if you commit properly (atomic commits) and write good commit messages.

Upvotes: 1

Related Questions