4 ms·
A good usecase for pushing rebased work is at the end of a feature branch. For example, you've been working on a feature branch with a team for a time and now t
by gitaarik 12y ago
A good usecase for pushing rebased work is at the end of a feature branch. For example, you've been working on a feature branch with a team for a time and now the feature is done and the branch can be merged back into master. However, the history of the feature branch might have been polluted with merge commits. To prevent merging these merge commits back into master, you can rebase the total feature branch on to master. It should be clear to the team that at this point, nobody is to work on that branch anymore and go back to master, or create a new branch (from master).
- sytse 12y agoGitLab CEO here. I personally don't like this workflow since you lose the history of what you did tested and it someone cherry-pick/referenced or merged code it will give problems. But some organizations prefer this workflow and if everyone is aware that they should not reference code it feature branches it can work. The linear history is certainly nice. The rebase just before merge is a bit of work. In GitLab Enterprise Edition there is an option to do this automatically when pressing the merge button.