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...
For further actions, you may consider blocking this person and/or reporting abuse
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!
Challenge: Trying to GIT GUD
jacks50 ・ Aug 12
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.
Awesome, thank you for sharing Oh My Git!, looks very cool!
Thank you for this writeup. It makes me feel like I'm not crazy for wanting to request these things during code reviews.
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.
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!
I feel you!
I am curious, do you consider lazygit and the likes as GUI tools or terminal then?
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 :)
Loosely related: the Linux kernel development process is quite an interesting read!
learn git branching is a web based game about learning git and the fundamentals. It's good for learning the basics of git
what kind of a madman person someone would have to be to ask the things in level 3? :D
goot post!
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...
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!
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. 😃
I would like to avoid naming some of my colleagues 😏. Thanks!
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.
It's crazy how fiery posts get so much traction on blog sites.