Maybe I’m just a wizard, or I don’t know what y’all are talking about, but rebases aren’t special. If you use git reflog it just tells you where you used to be before the rebase. You don’t have to fix anything, git is append only. See where the rebase started in reflog, it’ll say rebase in the log line, then git reset --hard THAT_HASH
Pushing without fetching should be an error. So either they got the error, didn’t think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.
Continuing after merge should be pretty easy? I’d assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly git rebase -i and then delete lines look like they were already merged?
See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don’t know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.
To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.
May be I’m just old school, and a grumpy old person, even though I’m not that aged.
Sounds like the onboarding process needs to have a step in it that says “here’s a link to a git tutorial, read this and get familiar with using git, as it’s an integral tool that you will use every single day on the job”. Bonus points for providing a sample repo that juniors can use to mess around with git, extra bonus points for including steps in the onboarding materials for the juniors to set up their own repos to play around with.
Same… My usual strategy: rebase, if conflict abort and merge, if no conflict continue; merge always with explicit commits to master / main (no fucking squashing); keep task references in branch names and commit messages.
Same, but typically I will just resolve the conflicts during the rebase. Makes for cleaner commit history. Merge commits are for combining multiple big unrelated pieces of work together, where rebasing would be too annoying (let’s say 100s of commits each).
In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.
Yeah if you have two branches, both with a bunch of commits which all modify the same areas of code, and reordering the commits doesn’t help, I can see how it is easier to merge.
I fail to see the benefits of “clean” git history
Well, if the commit history is clean and mostly linear, it’s much easier to read, understand and review. git blame will also be much nicer which is really important for debugging big codebases. Of course it’s a tradeoff, as usual.
Continuing on a squash merged branch is very annoying, and I had to deal with this in one repo regularly…
Luckily I was annoyed enough to research about this and found out about rebase --onto "main merge commit""branch merged commit".
Maybe I’m just a wizard, or I don’t know what y’all are talking about, but rebases aren’t special. If you use
git reflogit just tells you where you used to be before the rebase. You don’t have to fix anything, git is append only. See where the rebase started in reflog, it’ll say rebase in the log line, thengit reset --hard THAT_HASHPushing without fetching should be an error. So either they got the error, didn’t think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.
Continuing after merge should be pretty easy? I’d assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly
git rebase -iand then delete lines look like they were already merged?See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don’t know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.
To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.
May be I’m just old school, and a grumpy old person, even though I’m not that aged.
Oh, the human interaction is annoying! Yeah gotcha. That makes more sense!
Sounds like the onboarding process needs to have a step in it that says “here’s a link to a git tutorial, read this and get familiar with using git, as it’s an integral tool that you will use every single day on the job”. Bonus points for providing a sample repo that juniors can use to mess around with git, extra bonus points for including steps in the onboarding materials for the juniors to set up their own repos to play around with.
Same… My usual strategy: rebase, if conflict abort and merge, if no conflict continue; merge always with explicit commits to master / main (no fucking squashing); keep task references in branch names and commit messages.
Same, but typically I will just resolve the conflicts during the rebase. Makes for cleaner commit history. Merge commits are for combining multiple big unrelated pieces of work together, where rebasing would be too annoying (let’s say 100s of commits each).
In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.
I fail to see the benefits of “clean” git history
Yeah if you have two branches, both with a bunch of commits which all modify the same areas of code, and reordering the commits doesn’t help, I can see how it is easier to merge.
Well, if the commit history is clean and mostly linear, it’s much easier to read, understand and review.
git blamewill also be much nicer which is really important for debugging big codebases. Of course it’s a tradeoff, as usual.Maybe I just haven’t been exposed to bad examples. Never had any issues with blame and merge commits.
Continuing on a squash merged branch is very annoying, and I had to deal with this in one repo regularly… Luckily I was annoyed enough to research about this and found out about
rebase --onto "main merge commit" "branch merged commit".