What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.
Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.
When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.
What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.
you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then
git statuswill tell you that the remote branch and your local branch have diverged by as many commits as you rebased.Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.
When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.
What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed
randomlychronologically, but rather related commits following one another.And of course, you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.