Which git commands do you struggle with?

Which git commands and concepts do you have a hard time wrapping your head around and using regularly?

And with the commands you struggle with: Do you use them despite your difficulties or do you generally avoid them?

Source of the cover image. 😄

Comments

[Lucia Cerchie]

I struggled with git-cherry-pick so I wrote a tutorial on it github.com/Cerchie/git-cherry-pick...

[Ben Halpern]

Nice!

[Rense Bakker]

I struggle with the existence of git cherry-pick :p

[Arif RH 🎮]

Nice sir. Thanks!

[Alain D'Ettorre]

Rebasing: concept is clear, I can do a dead simple rebase, but rebasing in general is a struggle, so much that I almost always end up merging. My bad, I know.

[Isaac Lyman]

I support you, it's okay to merge. (I also don't really understand rebase)

[csgeek]

rebase just pulls in the changes from a branch and keeps your changes on top. if you do a -i with rebase it lets you squash, reorder commits and a bunch of other things. It's very powerful IMO.

[Isaac Lyman]

So is it the equivalent of making a fresh branch off of the other branch, then cherry-picking all your commits back onto it? E.g.:

git checkout working-branch
git commit -m "My commit"
git rebase main

==

git checkout working-branch
git commit -m "My commit"
git checkout main
git checkout -b new-working-branch
git cherry-pick {commit hash of "My commit"}

[csgeek]

Sure, but if you have 15 commits on your branch you'd have to cherry-pick all 15s. rebase is much easier to use, but it is equivalent if you want to use that.

It has other features (squash, reorder, etc) which are really handy that I mentioned earlier though for the standard behavior that is equivalent.

[Jan Küster]

Rebase is so underrated but also so hard to grasp, which is why also often use merge or squash merges.

[Chris Watson]

I can handle interactive rebasing, but it does sometimes get you in a muddle. The thing is, you have to solve all the same conflicts as a merge, just not all-at-once and it keeps the history cleaner.

[Nicholas Stimpson]

It's not so much the individual commands as the entire philosophy. And the multiple commands that do the same thing. Or nearly the same thing. Or almost the same command that does something entirely different. So you're left feeling like "You're in a room with multiple exits, all the same".

[Ben Halpern]

Have you considered using a tool or abstraction that helps? Just curious.

[Nicholas Stimpson]

I use TortoiseGit mostly. And eGit in Eclipse. And I used to use SourceTree. They all help a bit. But when things go screwy, I inevitably end up back at the command line.

[Michael]

At least when you enter a wrong command you don't get eaten by a Grue

[matthew-salerno]

revert has screwed me over a couple times. I think I get it now but it took a couple painful lessons to learn that it was not "revert back to this commit" but was actually "revert this commit and keep future commits." I ended up deleting my working commits and keeping my broken ones 😂🥲😭

[sandeshsapkota]

do we have this command in git ! really ?

[matthew-salerno]

Yup the man page even tells me not to do exactly what I did. Although it's not as bad as I made it sound as it doesn't actually remove the commit, it just makes a new one that makes it as if the commit never happened.

[sagefright]

Agreed, I recently went on a rant about revert and got it all out of my system.
twitter.com/AndyHails/status/15103...

[Murtuzaali Surti]

The commands which I don't use often!

[Om Bhamare]

Lol

[Garrett Mills]

A lot of submodules stuff feels... suboptimal for end-users. One that gets me occasionally:

1. Clone repo with submodules & initialize submodules
2. Edit file in a submodule and commit/push it
3. Commit disappears into the ether.

This is because submodules check out a detached head instead of a branch, so committing on top of the head doesn't make the commit the new head of the branch... so next time you pull it disappears.

[Amelia Gapin]

I will NEVER grasp submodules. Every time someone at work brings them up as a suggestion, I run away

[ytjchan]

Can git reflog show the commit hash?

[Wormhole Cowboy]

Kept forgetting to pull after adding a readme on Github. Then I wouldn't be able to push because of conflicts, so I had to learn how to use rebase.

[John Peters]

Visual Studio Code has a plug-in named GitLens. It is so good that I don't issue git commands any longer.

It includes rebasing,
auto resetting to any commit, changing the head pointer, full Visual commit history with code drill down ability to see modifications. Not to mention syncing, pushes and pulls, commits and branching.

[Matthew Ondash]

Oh for sure! Interactive rebase with GitLens is the bees knees! And managing branches and stashes has never been easier. Pair it with the Git Graph extension and it's a whole new world :D

[John Peters]

It's helped me out of terrible messes I did to my local and remote repos many times.

[Roneo.org]

git commit --fixup

[sagefright]

WTF?1 Just read about this as a result of your comment. What is the point?!

[Thomas Hansen]

Jeff Bezos has a rule; "Two pizza should be sufficient to comfortably feed a software development team". So what on earth does this has to do with git you may ask?

Well, if your git branches ends up looking like a x-mas tree, or guitar hero (LOL!), this is a symptom of complexity, often originating from the size of your team, resulting in that you've got too much "administration overhead". People that initially sees Magic's source code, are often shocked to see the sheer number of projects (40+), without realising that by segregating its projects to such an extreme extent, it's much easier to segregate teams into smaller more easily managed chunks of code, again resulting in that you can create smaller autonomous teams, not interfering with each other, making it easy to "feed each team comfortably on 2 pizzas".

Conclusion? If your git branches looks like "guitar hero", you're probably doing something wrong elsewhere in your organisation. Rethink the way you're working, find the underlying symptom, and watch your "x-mas tree automatically turn into a Redwood tree" ... ;)