In addition to squashing commits, you can merge with `--no-ff` to create s merge commit and semi-linear history showing when new code arrived.
Don't use Git rebase
11–20 of 88 posts
Re: Don't use Git rebase
#12There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.
I would think squash a poor default policy; it destroys information in the granularity of commit, and in the commit messages.
Re: Don't use Git rebase
#13There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.
I use git merge --squash so I can commit garbage. The garbage in the feature branch then disappears. It doesn't make sense to preserve those individual commits because they are not intended to work, they may contain code that doesn't even compile, etc. The problem with git commits is that they are immutable and exist forever so you want to get it right on your first try and every commit should be a single "unit" of change that produces a new valid version of your software. Create a feature branch, commit code (often with "WIP" as the commit message) that isn't finished yet and then git merge --squash when it's ready with a proper commit message.
Re: Don't use Git rebase
#14What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
The main use case for rebase for me is to add automatic rebases on pull to the git config. Normally if you pull from the remote and have local commits not in the remote, you'll have an "extra" merge. Automatic rebase on pull takes care of this, to avoid those useless merges.
They are not useless: they record when git used its fallible automatic merging logic to reconcile changes in two different branches. It works most of the time, but you really want to keep a record of it for later troubleshooting.
Have a look at https://github.com/git/git/blob/master/Documentation/merge-s... to get some idea what is going on behind the scenes in automatic merges.
Re: Don't use Git rebase
#15this is a narrow view based on someones versioning habits , the point of rebase can also be a solid linear history that allows multiple teams to fork and pull request features between forks. If developer chooses to play merging inside his own repo, fine but as soon as you have large teams working on their own you will end up in merging hell between developers and teams.
say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there's team c, d , e .... n giving non conflicting input to your codebase.
the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.
in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can't merge any more cause of other developers conflicts.
Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.
Re: Don't use Git rebase
#16If you want every commit to compile then have your CI system check this; no need to blame a useful tool.
Re: Don't use Git rebase
#17What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
The major usecase I have for rebase is code review. If your code review stage happens at the point of merge/rebase/whatever into master, then rebase allows you to present the feature changes in a digestible way for the reviewers (split up into nice individual commits that make sense individually and are small enough to read and review without too much effort). The classic open source "send patches by email" workflow works this way.
The author is correct that a rebase may require resolving conflicts; but then those conflicts need resolving anyway if you choose to merge instead. It is also possible to miss a "semantic conflict" that doesn't make git complain but produces a commit that doesn't build -- you can put in tooling that checks that each commit builds individually to avoid the "oops, bisect on master isn't much use" issues.
Re: Don't use Git rebase
#18What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
The major usecase I have for rebase is code review. If your code review stage happens at the point of merge/rebase/whatever into master, then rebase allows you to present the feature changes in a digestible way for the reviewers (split up into nice individual commits that make sense individually and are small enough to read and review without too much effort). The classic open source "send patches by email" workflow…
Ok, if your set of changes is too large to review in one piece, and you put in the work of refactoring your changes into a speedrun-style best possible history so they are cognitively review-friendly, I grant that this is a valid use case for rebase.
Though erasing the real history is still a serious drawback, and the unit of code review is still too large. Not many projects work like this, however.
Re: Don't use Git rebase
#19> Graphs of non-linear history, “train tracks”, can be intimidating. They certainly felt that way to me to begin with, but there’s no reason to be scared of them. There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based.
It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use:
CLI: tig
GUI: gitg, qgit (Linux)
Re: Don't use Git rebase
#20There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.
I use git merge --squash so I can commit garbage. The garbage in the feature branch then disappears. It doesn't make sense to preserve those individual commits because they are not intended to work, they may contain code that doesn't even compile, etc. The problem with git commits is that they are immutable and exist forever so you want to get it right on your first try and every commit should be a single "unit" of c…
By rewriting commits and using `git rebase -i`, `git commit --fixup` you can avoid the garbage and still have smaller commits that passes tests and are easy to review.