If I saw this in my code… I’d just… I’d have a mental breakdown
You need to merge more often.
Rebase. That’s where the real trauma is.
Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git
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?
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 rerere functionality, which stands for “reuse recorded resolution”
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
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.
I usually squash my local into a single commit, then rebase it onto the head of main. Tends to be simpler
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.
Git flow eliminated 95% of merging issues for my team
I know this is a joke, but those errors/warnings/messages screenshot is not from git. That looks more like results from a compiler of some sort.
Looks exactly like Visual Studio 2022.
I guess the joke implies that automated (or incorrect manual) conflict resolution causes code that doesn’t compile. But still not git’s fault. They should probably have merged earlier and in rare cases where that wasn’t possible, you have to bite the bullet and fix this stuff.
When people do a bunch of bulk renames on every commit, then you get this kind of problem a lot. But yeah still not gits fault
In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).
This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.
Also, git pull --rebase is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.
Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.
not scary at all
I have seen some juniors really shoot themselves in the foot with rebasing, and I’ve been there as well before. I agree it can be useful, but it definitely requires understanding of what is going on :P
rerere makes resolving these almost bearable