A much simpler solution: don’t use the git CLI. And in my professional life I don’t know a single person who does. The shortcomings of git have long been abstracted away and as problematic as the CLI is, it’s now just an internal library of the tools we actually use.
Also the git pull criticism is weird. Yeah it exists on paper, and year every so often once in a blue moon there’s a conflict after a pull with rebase, but… this doesn’t even begin to dent the oodles of time saved from just doing Ctrl+T in IntelliJ and be up-to-date with no further input. Why waste 20 minutes 40x-100x a day instead of 45 minutes once every 3-6 months? Especially this case:
My favorite version of this is when the novice has followed someone’s dodgy advice to set pull.rebase = true, then they pull a shared branch that they’re collaborating on, into which their coworker has just merged origin/main. Instant Sorcerer’s Apprentice-scale chaos!
I’m sorry, but are you collaborating or competing on a shared branch? If it is a collaborative effort, maybe just talk about it? And in fact, unless the other person is an utter asshole, they’ll have done so before merging in the new changes from main. That’s not even to mention that in 99,95% of cases or so, that exact scenario is perfectly fine and gets resolved without any issues whats-o-ever and no user input necessary. Bringing us once again to the situation where you save a moderate amount of time multiple times a day by always just pulling.
(edit)
Don’t get me wrong, all of this criticism is of course valid. But it feels like a very arcane case, as no project should be able to produce the issues frequently unless there’s some underlying problem in either the mode of collaboration or the structure of the project in the first place, and the usage of git is long abstracted away and the tools handle virtually any and all edge case, including making merging far smarter than if you were to use the CLI.
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).
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.
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.
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 :)
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.
I usually use a gui but I know plenty of colleagues who exclusively use cli. I’ve never understood if it’s an ego thing or what but it’s an incredibly popular way to use git
I exclusively use CLI, it’s not ego at all, I simply find typing what I want to be quicker than clicking buttons. I’ve written a bunch of aliases to automate my common workflows.
When I need to help a colleague who’s made a mess of something, I can easily give them the command to fix it rather than finding the right options in their GUI of choice and it’s often because of some broken abstraction in the GUI they got into the mess in the first place.
I do have a huge ego, but I’ll claim it’s a total coincidence that I use CLI git.
My main reason to use mostly CLI is the better error messages I get when something goes wrong.
My secondary reason is that my preferred GUI tools for git didn’t used to have support for operations I do often such as ‘cherry-pick’ and ‘rebase’. I think that is mostly solved now, but my habits change slow and I’m used to the CLI.
Haha fair. My experience though, is that cherry picking is easily done in gui and I’ve honestly never attempted on cli because it only takes me three clicks in Fork
There are things that my GUI of choice lack, so I occasionally type out a command, although I did also bind a couple of commands to GUI buttons, so there’s that.
A much simpler solution: don’t use the git CLI. And in my professional life I don’t know a single person who does. The shortcomings of git have long been abstracted away and as problematic as the CLI is, it’s now just an internal library of the tools we actually use.
Also the
git pullcriticism is weird. Yeah it exists on paper, and year every so often once in a blue moon there’s a conflict after a pull with rebase, but… this doesn’t even begin to dent the oodles of time saved from just doing Ctrl+T in IntelliJ and be up-to-date with no further input. Why waste 20 minutes 40x-100x a day instead of 45 minutes once every 3-6 months? Especially this case:I’m sorry, but are you collaborating or competing on a shared branch? If it is a collaborative effort, maybe just talk about it? And in fact, unless the other person is an utter asshole, they’ll have done so before merging in the new changes from
main. That’s not even to mention that in 99,95% of cases or so, that exact scenario is perfectly fine and gets resolved without any issues whats-o-ever and no user input necessary. Bringing us once again to the situation where you save a moderate amount of time multiple times a day by always just pulling.(edit)
Don’t get me wrong, all of this criticism is of course valid. But it feels like a very arcane case, as no project should be able to produce the issues frequently unless there’s some underlying problem in either the mode of collaboration or the structure of the project in the first place, and the usage of git is long abstracted away and the tools handle virtually any and all edge case, including making merging far smarter than if you were to use the CLI.
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).
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:
After a while, rebasing becomes as simple as commit or merging.
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.
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 :)
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.
I do, I find it much simpler than using the GUIs
I usually use a gui but I know plenty of colleagues who exclusively use cli. I’ve never understood if it’s an ego thing or what but it’s an incredibly popular way to use git
I exclusively use CLI, it’s not ego at all, I simply find typing what I want to be quicker than clicking buttons. I’ve written a bunch of aliases to automate my common workflows.
When I need to help a colleague who’s made a mess of something, I can easily give them the command to fix it rather than finding the right options in their GUI of choice and it’s often because of some broken abstraction in the GUI they got into the mess in the first place.
I do have a huge ego, but I’ll claim it’s a total coincidence that I use CLI git.
My main reason to use mostly CLI is the better error messages I get when something goes wrong.
My secondary reason is that my preferred GUI tools for git didn’t used to have support for operations I do often such as ‘cherry-pick’ and ‘rebase’. I think that is mostly solved now, but my habits change slow and I’m used to the CLI.
Haha fair. My experience though, is that cherry picking is easily done in gui and I’ve honestly never attempted on cli because it only takes me three clicks in Fork
Yeah. Cherry pick was the killer feature for CLI back when I was forming habits. Seems like it’s built into most tools now, which is really nice.
There are things that my GUI of choice lack, so I occasionally type out a command, although I did also bind a couple of commands to GUI buttons, so there’s that.
I mostly agree. The caveat to this is I’ve had to learn CLI for programmatic use cases like automation.