DEV Community

Cover image for Seriously, you need to learn git

Seriously, you need to learn git

Lucy Linder on July 22, 2024

WARNING: ranting incoming. I have seen countless articles about git (one of the hottest subjects out here), yet I am still puzzled at how few deve...
Collapse
 
derlin profile image
Lucy Linder • Edited

A big applause/thanks to @jacks who took the challenge seriously and shared his experience and learnings. If you are looking for answers, check it out!

Collapse
 
trevorbenson profile image
illuminatus

Your game sounds scarily familiar! I liked your article, and definitely agree people should learn git, especially beyond the bare minimum steps to push/pull and open a PR.

I'm just as comfortable in git's CLI client rebasing interactively to edit the commits, reorder them, or squash/fixup them together. I can also use the reflog to full effect, although this is where I prefer IDE tools which nicely graph the reflog entries and dig into each for quick analysis. But the visual graphing isn't super helpful if someone doesn't even know what the reflog is.

I also suggest anyone looking to learn more about git check out the Oh My Git! game. It teaches git in the premise of it being a time machine and has visual and CLI interface, so someone can definitely learn the CLI steps and work towards mastering git. The game is in GitHub and you can even create new levels for the game and submit them as Pull Requests.

Collapse
 
derlin profile image
Lucy Linder

Awesome, thank you for sharing Oh My Git!, looks very cool!

Collapse
 
fyliu profile image
fyliu • Edited
  1. Thank you for this writeup. It makes me feel like I'm not crazy for wanting to request these things during code reviews.

  2. I'm able to do all these things but some are faster with lazygit or git-gui. Is there a good way to split a commit with just commandline? I can think of resetting and just git add -p to stage the partial changes.

(my own rant coming) I especially want to tell one contributor to squash all his changes (he makes small nonsense commits and git merges from main so rebasing is not possible) into one and then split that into logical commits where he removes or splits off unrelated changes into a separate branch if he wants to keep them for another PR. But even before settling on the final code, there's the half a dozen changes that need to happen for the code to work as required. Getting to the working code is a challenge, then getting to the minimal code is another one. By the time that's done, It's been 2+ months and I just squash all the changes rather than wait for him to make it nice for the merging.

Collapse
 
moopet profile image
Ben Sinclair

Start by learning git the hard way. Stop using your IDE or git UI for a while

I literally struggle with GUIs. People at work just sigh when I have to use them because they know what's coming. The command-line makes sense to me, looking at pictures of things and remembering where menus are and what icons are supposed to represent gives me anxiety.

Something like SourceTree is hard mode!

Collapse
 
derlin profile image
Lucy Linder

I feel you!

I am curious, do you consider lazygit and the likes as GUI tools or terminal then?

Collapse
 
moopet profile image
Ben Sinclair

I've tried to use them and I see how they can be a good thing, but I get lost and go back to the command line. I never got on with file explorers like mc or ranger either :)

Collapse
 
derlin profile image
Lucy Linder

Loosely related: the Linux kernel development process is quite an interesting read!

Collapse
 
mmustaphak profile image
Mustapha Kura Mohammed

learn git branching is a web based game about learning git and the fundamentals. It's good for learning the basics of git

Collapse
 
prwnr profile image
Rafał

what kind of a madman person someone would have to be to ask the things in level 3? :D

goot post!

Collapse
 
trevorbenson profile image
illuminatus • Edited

level three: you pushed your commits 1 to 5, but your reviewer asks to change something in commit 2, reorder commits 3-4, meld commit 5 into 4, change the commit message of commit 1, and rebase your branch to master.

  • change something in commit 2 (rebase:edit)
    • definitely
  • meld commits 5 into 4 (rebase:squash/fixup)
    • definitely
  • change the commit message of commit 1 (rebase:reword / commit --amend)
    • especially if there is jenkins or circleci or anything which requires specific syntax to automerge or do specific CI tasks.
  • rebase your branch to master
    • All the time without being asked by a reviewer too, just to get the code to merge into the base branch of the PR.

The only one I don't think I've been asked is to simply reorder the commits. Although I guess if 2 different features were in a single branch, I could see wanting all commits for feature 1 to come first and then feature 2 after, if they were completely independent of eachother. It could make testing feature 1 easier to checkout the last commit prior to feature 2.

However, I'd have to argue that should have been 2 separate PR's anyway, feature 2 could have been based off the feature 1 branch if they are related. A reviewer with that much OCD but not asking for separate the PR's, at least in my experience, is not extremely common. Although I've seen when 20-30 tickets end up in a single feature branch tied back to a single epic (jira terminology), so its definitely not unlikely to happen either...

Collapse
 
derlin profile image
Lucy Linder

I agree the reorder alone doesn't really make sense. However, you may need this skill of e.g. Commit 2 and 4 should be squashed. In this case, you can first reorder then squash. I see other use cases for the reorder (locally when you start fixing one commit multiple times, you can bring it at the top and then amend, amend, amend).
The game is really just a game to sustain my arguments, I hope in real life your reviewers have more sense 😁

I agree with your answers, thanks for sharing!

Thread Thread
 
trevorbenson profile image
illuminatus

Yep, and of course the interactive rebase and just moving the pick'd commit up and down solves the trick. I've done this myself often enough for my own nitpicky reasons. 😁

Also just like you say to work on something without changing a commit history deeply over and over moving it to the top then fixup/squash together, amend/reword the messages, and then reorder it back into place before opening a PR. Which of course if anyone likes their PR to look clean, its nice to do as much of that as possible prior to opening a PR! All the force pushes to fix the origin branch after a PR is opened look kind of messy when its not based on review comments. 😃

Collapse
 
derlin profile image
Lucy Linder

I would like to avoid naming some of my colleagues 😏. Thanks!

Collapse
 
ronww profile image
ronww

While I can split a commit into n smaller commits, needing to do so would mean I had done something wrong. (Probably means I should have done refactoring long before.) The changes in a commit need to be big enough to build and test with no unexpected* test failures.

Where I work, our most important rule for commits is "Test then commit." Any unexpected* test failures must be either resolved or justified before doing the commit. As such, we don't use the stage as this risks committing code that differs from what was tested.

As a team leader, I require my teammates to either properly use rebase or to not use rebase. By properly, I mean each revision created is tested and fixed/justified before being committed.

Far too often, I encounter strings of untestable commits resulting from lazy use of rebase. I would much rather have a testable merge-commit (preceded by unrebased commits) than a series of untestable commits.

Untestable commits make bisection so very much harder to do.

*Unexpected test failures occur when either the changes don't (completely) fix the intended issue or are new issues either uncovered or caused by the changes. Expected failures are from issues that are known but not yet addressed by code changes.

Collapse
 
siddharth_singhtanwar_6a profile image
Siddharth Singh Tanwar

It's crazy how fiery posts get so much traction on blog sites.