this post was submitted on 28 Aug 2024
524 points (97.1% liked)

Programmer Humor

32561 readers
421 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] dohpaz42@lemmy.world 4 points 2 months ago (1 children)

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.

[–] PotatoesFall@discuss.tchncs.de 2 points 2 months ago (1 children)

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

[–] dohpaz42@lemmy.world 3 points 2 months ago

What I suggest is not the same as using git rebase. It’s pretty automatic and easily abortable.