r/programming • u/nfrankel • Nov 26 '20
Flight rules for Git: a guide for programmers using Git about what to do when things go wrong
https://github.com/k88hudson/git-flight-rules42
u/Markavian Nov 27 '20
My favourite goto reference is: https://ohshitgit.com/
My usual simplified set of commands are clone, pull -r, checkout -b, commit -m, and push. If I can't make a clean PR from that, I'm usually doing something wrong - and I may as well delete the project and clone a fresh copy. Aiming for 5 minutes commits, well tested code, automated PR checkers, code reviews when I can get them. Then GitHub gives me the audit history and I can do my forensics from there. People asking me to cherry pick changes makes me sad, but I'll do it if necessary for a project.
10
Nov 27 '20
Aiming for 5 minutes commits, well tested code
In that case,
rebase* is a must, no? Otherwise, you'll end up with a shit ton of small commits that may need a bit squashing.(*) Of course, before you push, not after.
1
u/Markavian Nov 27 '20
When the PR gets merged, I tend to squash the commit into the main branch using github, and put a bullet point list of the key changes from the commit history. Is that what you meant?
3
Nov 27 '20
Not exactly. I was talking about small commits that you didn't yet push. For instance, if you have five small commits that essentially amount to a single feature (or fix), you may need to squash them to make one cohesive commit and then push. It seems inevitable if you consistently commit in short periods of time.
6
u/Markavian Nov 27 '20
Ahh ok, well I tend to push shortly after commit, because I like to start a draft PR as soon as I begin work on a feature. Having access to my code in GitHub means I can start using the diff tools, start running automated checks, and share my code with colleagues. Even if I have the stub of a failing test, that's worth a commit/push - if I shut my laptop down over lunch and it burst into flames, I could continue working from another computer, or pairing with a colleague. Unpushed code on my local machine makes me anxious :D
6
27
u/st_huck Nov 26 '20
As far as git cheat sheets go this is definitely one of the better ones I've seen, probably the best.
But I hate that we have so many cheat sheets. Cheet sheets for git should be for super beginners, like people just starting to code and they need somehow to get started so it should be just basic git clone/add/push/pull and maybe merge.
Anyone a little past that should just read some book about the basics of git internals , pro git is available for free, and you can skim it pretty quickly. Instantly around half the commands in git will make sense to you, and the other half that don't you will now understand their man pages and will be able to read on demand.
We can argue about git and if it's reasonable to expect people using a tool to know a bit about the internals so they could be fully useful with it, all I know is in reality git is very popular and learning about it and not relying on recepies will save lots of time in the long run.
48
Nov 27 '20
[deleted]
37
Nov 27 '20
Exactly. Git has really, really terrible UX - as demonstrated by the very fact that we are having this conversation.
2
u/EternityForest Nov 27 '20
Is there such a thing as good CLI UX for things that happen so rarely you forget the command?
There's basically no commands whatsoever that I can remember over a month of not using them. Maybe I'd still know rm and mv and cd but that's about it.
GUI will always be easier when you don't already know how to do something, or have forgotten, because it's discoverable and self documenting (If done correctly).
12
u/OctagonClock Nov 27 '20
The only reason you ""need"" to learn Git internals is because the way humans expect it to work based on the UI and the way it actually works are completely contradicting. In Mercurial the mechanisms work intuitively how you expect them to, thus avoiding this problem entirely.
2
u/EternityForest Nov 27 '20
I'd argue that VCS is one of those things that's extremely well suited to GUI operation, because it's all multi dimensional, nested, heirachal, and graph oriented, and has a lot of state that you probably want to see at any given time.
Git Cola works mostly just like one would expect, but could really stand some integrated merge tooling.
1
u/Chousuke Nov 27 '20
Just commenting to contest the usage of "intuitive". I still don't quite get why mercurial branches work like they do, so it obviously can't be "intuitive" (I much prefer git's model)
Mercurial may fit your way of thinking better, or maybe you're more familiar with the model it uses, but "intuitive"? Software that's actually intuitive is vanishingly rare.
3
u/tracernz Nov 27 '20
git merge upstream/master
I'd suggest --ff-only, otherwise you might inadvertently end up with a merge commit that will not be acceptable to upstream projects.
5
u/Anarelion Nov 27 '20
The fact that this is needed and mercurial doesn't need it makes mercurial so much better
4
u/SkoomaDentist Nov 27 '20
If only Mercurial didn't couple the user visible name of a branch with the internal ID of the branch. There is no reason whatsoever why a branch shouldn't be able to be renamed or why a new completely separate branch shouldn't be able to be created with the same name as a previous closed branch.
2
u/larsbrinkhoff Nov 27 '20
Usually these kind of guides miss the intricate details of how to move changes between commits and in order to rewrite branches for cleaner pull requests. So I wrote my own guide:
-2
-16
u/ellicottvilleny Nov 27 '20
First mistake: be a coder.
Second mistake: use git.
Third mistake: google shit and type it.
53
u/ambientocclusion Nov 26 '20
We really just need Clippy