Programming

17313 readers

177 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

Why Git is hard (roadrunnertwice.dreamwidth.org)

submitted 1 year ago by [email protected] to c/[email protected]

55 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 22 points 1 year ago (2 children)

I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).

[–] [email protected] 8 points 1 year ago (1 children)

That being said, I still don’t mess around with rebase for anything

Rebasing has a worse reputation than it deserves. It's something you just get used to - just like how git use is, when you started using it. There are a couple of strategies to make it easier and less anxiety inducing:

Before starting a rebase of a long branch, create a new branch. That way in case you seriously mess up, you can just delete the rebasing branch and rename the old branch to restore everything (you can usually get away with rebase abort. This is just added safety). Even in case of a successful rebasing, you can just keep the backup branch around, as a faithful record of actual development history.
Do only one (or max 2) operations in a single rebases. Do this over multiple rebases to get what you want.

After a while, rebasing becomes as simple as commit or merging.

[–] [email protected] 2 points 1 year ago

Rebasing and merge conflicts are the top ways that git can turn into a mess. I know that rebasing could (in some circumstances) make merge conflicts less of an issue, but I just mostly think the value of "commit grooming" is overrated. I don't want to argue about this, if you like doing it, go ahead.

[–] clif 5 points 1 year ago (1 children)

I had to check and make sure I didn't type the comment above because it sounds exactly like me.

All UIs do things slightly differently, the CLI is always exactly the same... Everywhere. UI for non trivial conflict resolution? Definitely. For everything else, CLI.

And, I'm also reticent to use rebase unless I have to. Gimme that good ole FF :)

[–] [email protected] 1 points 1 year ago

UI for non trivial conflict resolution? Definitely.

I dont know about that... Never found they help that much in conflict resolution. They give you some nice buttons for accept their or accept our changes but really I find more often than not those are what breaks code as you often want a mash-up of both sides - which needs to be manually done even in UIs.

Otherwise it is just find the marked sections in the file, and make it look like what you want it to after the merge/rebase. And that is the hardest part - figuring out what it should look like. Which is made easier if you only ever have small commits and merge back to master frequently minimizing the amount your branches drift from each other.