175
Git Rules (lemmy.ml)
submitted 10 months ago by yogthos@lemmy.ml to c/programmerhumor@lemmy.ml
you are viewing a single comment's thread
view the rest of the comments
[-] pixelscript@lemmy.ml 5 points 10 months ago

You don't. One of the core aspects of Git is that it fully expects conflicts to be inevitable, and it gives you tools to resolve them.

I will say that if you learn to aggressively rebase branches, you can at least occasionally reduce the complexity of conflicts.

If you are working on a long branch and three other branches that conflict with your changes land in the meantime, a simple merge will force you to reconcile all of those conflicts in one big stinky merge commit.

If you instead rebase after each individual branch lands, you resolve the same number of conflicts but in three smaller, focused steps instead of one big ugly one. You also don't get a merge commit full of redundant deltas that serve only to resync your branch to master; all the conflict resolution becomes baked in to your individual branch commits.

Spreading out the problem is not reducing the problem. But it can make fixing the problem less daunting, which has a similar effect.

[-] pcouy@lemmy.pierre-couy.fr 3 points 10 months ago* (last edited 10 months ago)

That was the point of my comment, unless they wrote this ironically.

Sorry you went through the trouble of writing all of this explanation, I hope this is useful to someone else

this post was submitted on 12 Feb 2024
175 points (100.0% liked)

Programmer Humor

32715 readers
722 users here now

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

Rules:

founded 5 years ago
MODERATORS