I consider myself above average in terms of Git know how. But I’ve come across situations using rebase where you’re stuck resolving the same conflicts over several commits.
I still don’t understand that part quite well.
This doesn’t happen when you do a normal merge though. Making it easier to manage
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”
Holy shit! I never took the time to read about it rerere. But it all makes sense now.
However, it’s still a lot of extra steps for what could otherwise be really simple with a regular merge.
Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It’s it really worth all the hassle? Especially if you’re using a squash merge in a pull request…
I don’t think rerere applies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.
Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.
That could happen if the base branch has changed a lot since the last time you rebased against it. Git may make you resolve new conflicts that look similar to the last time you resolved them, but they are in fact new conflicts, as far as git can tell.
Only if there are changes in the same files and on the same lines in both branches. And if you’re a commit freak, you should probably be squashing/amending, especially if you’re making multiple commits of changes on the same lines in the same files. The --amend flag exists for a reason. No one needs to see your “fixed things”, “changed things again”, “fixed it for real” type commits.
What I do locally on my branch is my own business.
Honestly, when doing a merge/pull request into the parent branch, that’s when you squash. You don’t need the entire history of a development branch in main.
What I do locally on my branch is my own business.
Lol ok, but don’t expect git to read your mind. Like I said earlier, if people take a day or two to understand the tool, they can adjust their personal workflows to work better within the confines of git.
Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git
I consider myself above average in terms of Git know how. But I’ve come across situations using rebase where you’re stuck resolving the same conflicts over several commits.
I still don’t understand that part quite well.
This doesn’t happen when you do a normal merge though. Making it easier to manage
You could try making enabling git’s
rererefunctionality, which stands for “reuse recorded resolution”. This should largelyhttps://git-scm.com/book/en/v2/Git-Tools-Rerere
https://stackoverflow.com/a/49501436
Yeah I saw someone else’s answer and I totally learned something new today.
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”
You can improve the situation with git rerere
Holy shit! I never took the time to read about it rerere. But it all makes sense now.
However, it’s still a lot of extra steps for what could otherwise be really simple with a regular merge.
Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It’s it really worth all the hassle? Especially if you’re using a squash merge in a pull request…
I don’t think
rerereapplies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.
Yeah that’s what I did as a workaround. Reset (soft) to the first parent commit and do a single commit with all the changes.
I usually squash my local into a single commit, then rebase it onto the head of main. Tends to be simpler
Ditto.
That could happen if the base branch has changed a lot since the last time you rebased against it. Git may make you resolve new conflicts that look similar to the last time you resolved them, but they are in fact new conflicts, as far as git can tell.
All it can take is one commit in the parent branch. If your branch has many commits because you’re a commit freak then your fucked.
Only if there are changes in the same files and on the same lines in both branches. And if you’re a commit freak, you should probably be squashing/amending, especially if you’re making multiple commits of changes on the same lines in the same files. The
--amendflag exists for a reason. No one needs to see your “fixed things”, “changed things again”, “fixed it for real” type commits.What I do locally on my branch is my own business.
Honestly, when doing a merge/pull request into the parent branch, that’s when you squash. You don’t need the entire history of a development branch in main.
Lol ok, but don’t expect git to read your mind. Like I said earlier, if people take a day or two to understand the tool, they can adjust their personal workflows to work better within the confines of git.
I agree.
Unfortunately, from experience, nobody seems to have time for that. They just learn git pull, push, add, commit and merge and that’s about it.
Sometimes they’ll use checkout and end up in detached head and have a panic attack. That’s when I come in. lol
You and I have very different opinions on what is a reasonable expectation for our respective teams.
You think it’s unreasonable for a software developer to take one to two days to learn a tool that’s basically ubiquitous in their field?
No, I think it’s a perfectly reasonable thing to do, my coworkers on the other hand…