4 ms·

I agree with you for the most part but most of you would be better off if you keep this in mind : Don't rebase commits you have already pushed.

sytse 12y ago
Exactly, if you have pushed it other developers might have referenced, merged or cherry-picked your code. Even if you marked it as a work in progress. And to roll back to a previous state it is not needed to rebase and/or have a linear history. Also see my article about this https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/
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 ago
  GitLab 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.
marrs 12y ago
Git won't let you push a modified history without a force anyway, and you can set up the remote to refuse these pushes if you want.

4 ms·

I agree with you for the most part but most of you would be better off if you keep this in mind : Don't rebase commits you have already pushed.

by thewarrior 12y ago

sytse 12y ago
Exactly, if you have pushed it other developers might have referenced, merged or cherry-picked your code. Even if you marked it as a work in progress. And to roll back to a previous state it is not needed to rebase and/or have a linear history. Also see my article about this https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/
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 ago
  GitLab 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.
marrs 12y ago
Git won't let you push a modified history without a force anyway, and you can set up the remote to refuse these pushes if you want.