3 ms·

I still haven't seen a better git branching model than https://gist.github.com/17twenty/6733076 https://gist.github.com/17twenty/6733076 (aka feature branching

I still haven't seen a better git branching model than https://gist.github.com/17twenty/6733076 https://gist.github.com/17twenty/6733076 (aka feature branching model). I've found this model works well for smaller apps and can scale easily with modularization and feature flags.

sytse 11y ago
That is not a bad model and you'll prevent merge commits. However in GitLab flow I advocate against rebasing of commits you pushed: "However you should never rebase commits you have pushed to a remote server. Somebody can have referred to the commits or cherry-picked them. When you rebase you change the identifier (SHA1) of the commit and this is confusing. If you do that the same change will be known under multiple identifiers and this can cause much confusion. If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit." I think that "Your codebase should be clean but your history should represent what actually happened.". But if you want to use your model GitLab does support it, GitLab EE and .com allow you to rebase and merge from the web interface http://doc.gitlab.com/ee/workflow/rebase_before_merge.html http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
- jzelinskie 11y ago
  I basically use the model described in this gist and dislike the fact that our review history is basically lost when we rebase to fix the commits. Rather than "what actually happened", we prefer logical commits so that when you run `git blame`, you can see a commit that makes sense rather than "WIP". What we really want is a code review system that has _changesets_ so that we can keep our git history clean, but also have a full history of our code review. I'm really surprised that in all of these GitHub discussions, there hasn't been much raised about their insufficient code review system.
  - piotrkaminski 11y ago
    https://reviewable.io https://reviewable.io deals with changes in this way and has no problems with rebasing, even distinguishing between deltas in the branch vs the base when diffing. Only works on top of GitHub, though, sorry. (Disclosure: I'm the founder.)
  - invisible 11y ago
    Phabricator solves this problem but it does so using patches (outside of "git"). It works pretty well but there does wind up being dependency problems if code doesn't get merged quickly enough.

sytse 11y ago

That is not a bad model and you'll prevent merge commits. However in GitLab flow I advocate against rebasing of commits you pushed: "However you should never rebase commits you have pushed to a remote server. Somebody can have referred to the commits or cherry-picked them. When you rebase you change the identifier (SHA1) of the commit and this is confusing. If you do that the same change will be known under multiple identifiers and this can cause much confusion. If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit." I think that "Your codebase should be clean but your history should represent what actually happened.". But if you want to use your model GitLab does support it, GitLab EE and .com allow you to rebase and merge from the web interface http://doc.gitlab.com/ee/workflow/rebase_before_merge.html http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

jzelinskie 11y ago
I basically use the model described in this gist and dislike the fact that our review history is basically lost when we rebase to fix the commits. Rather than "what actually happened", we prefer logical commits so that when you run `git blame`, you can see a commit that makes sense rather than "WIP". What we really want is a code review system that has _changesets_ so that we can keep our git history clean, but also have a full history of our code review. I'm really surprised that in all of these GitHub discussions, there hasn't been much raised about their insufficient code review system.
- piotrkaminski 11y ago
  https://reviewable.io https://reviewable.io deals with changes in this way and has no problems with rebasing, even distinguishing between deltas in the branch vs the base when diffing. Only works on top of GitHub, though, sorry. (Disclosure: I'm the founder.)
- invisible 11y ago
  Phabricator solves this problem but it does so using patches (outside of "git"). It works pretty well but there does wind up being dependency problems if code doesn't get merged quickly enough.