Treat commits as immutable data. Don't try to amend, squash or rebase.
Having one commit merges is overrated
Ask HN: What made you finally grok Git?
71–80 of 94 posts
Re: Ask HN: What made you finally grok Git?
#72Implementing it.
Once I read somewhere it is just a key - object, append only, DB then it seemed easy to implement the core of it, so I did. It's simpler that it sounds.
Re: Ask HN: What made you finally grok Git?
#73Earlier quoted context omitted.
You do that by merging. For people who love a clean, linear history, this can be frustrating, because it creates a new commit that doesn't add anything new, it just merges two branches. At my current project, PRs get merged very slowly, and after every PR gets merged, we merge master back into all the branches, which has lead to a ridiculous number of merge commits, and the guy who loves clean history won't stop comp…
It seems like a lot of headaches could be avoided if you just don’t have people share branches. Then you just rebase master and force push away with reckless abandon,
That's certainly a possibility. But what if two people have to work on a big feature together?
Re: Ask HN: What made you finally grok Git?
#74Earlier quoted context omitted.
It seems like a lot of headaches could be avoided if you just don’t have people share branches. Then you just rebase master and force push away with reckless abandon,
That's certainly a possibility. But what if two people have to work on a big feature together?
Break the big feature up into smaller changes. Vertical slices help with that: https://news.ycombinator.com/item?id=33384275 Each change is merged to `master` after a relatively short amount of time. What some people call "trunk based development".
I've yet to build a big feature that wasn't worked on by 4 or 5 people at the same time. Since they're different vertical slices, they're different branches (and tickets). But even then you might have a frontend and backend person collaborating on the same branch for a small slice of functionality.
This is also not a problem as even with one branch for two people who work with it. In git there are constantly more actual branches around than you "realize". E.g. here there's 3 branches going around and you just merge/rebase them. One branch is the one in the shared repo. The other two branches are the local branches of the same name on each of the two developer's machines. They need merging or rebasing just like you merge/rebase with `master` itself.
Depending on what you changed, you'll have weird looking history and conflicts to solve (or commits to skip). Which needs some head wrapping around but git itself so far has never been confused by my "reckless force pushing" on a shared branch. It helps if you don't have two people actually changing the same parts of the code though. Then you're in a world of hurt for conflict resolution but it's not the force pushing part that creates the hurt. That's just always bad.
Before you bring this back into `master` you'll want to squash all this into one commit and thus all the weird history ceases to exist.
Also, communication is key. If someone force pushes, tell the other person and help them resolve any rebasing/merging conflicts w/ your knowledge of the changes you made. If two people sit in opposite corners, force pushing "their world view" without tell each other, you definitely will be loosing code.
Re: Ask HN: What made you finally grok Git?
#75When I realised it was all about share-xor-mutate, just like all reasonable systems:
Rebase and force-push on your own branches only (they are mutations), pull-request when putting stuff onto other branches.
I also find the whole git tree WAY easier to read if it's fast-forward-only, and no merge commits.
Atlassian's not as popular as they used to be I guess, but I found Bitbucket presents the best view of the git tree ever. When I wanted to do anything advanced, I'd look at the Bitbucket view, do local git commands in my shell, push, and then watch Bitbucket again.
Re: Ask HN: What made you finally grok Git?
#76What's important to understand about git is that it allows time travel, and time travel enables changing history, and changing history is a really bad idea. Do not ever change the history without knowing what you're doing. In git, this means mostly rebasing and other stuff that messes with existing commits. Messing with existing commits can be fine as long as you're messing with the only existing version of that comm…
I just ran into this problem last night... if you shouldn't rebase after pushing to remote, how do you update a PR days after you originally created it to be on top of the latest origin/master and be able to resolve merge conflicts locally?
I do! As long as we understand it's "my branch" that's being reviewed. I can push/rebase/squash a bunch of times until the reviewer is happy. Once the reviewer's happy, my branch becomes one new commit on top of master.
Re: Ask HN: What made you finally grok Git?
#77I have not grokked git — it hasn't been necessary to. Understanding some of the basics, knowing enough of the commands to run, and figuring out which StackOverflow answer applies to my current situation is good enough. If I have to spend too much time knowing its internals and delving into its philosophies, then it is not a useful tool that lets me get on with my tasks.
Kinda. I wouldn't be able to tell you too much about the internals of VSCode. The 'trouble' with git is, though, that what happens when you run the wrong command can vary from "easy to fix" all the way to "you just lost your work, you shouldn't have run that command". Which means you need to either be very careful anytime you run git, or you need to learn more about git to avoid the footgun aspects of it.
It's kinda sad though because off the top of my head i suspect it's really difficult to actually lose your work. Ie between the fact that the content store stores.. well, all content, until it's GC'd, and the obvious reflog, you can almost always get back your data.
The downside to this though is the type of novice most likely to make a mistake in "losing" their data will also not know how to recover their data.
Re: Ask HN: What made you finally grok Git?
#78[deleted]
Re: Ask HN: What made you finally grok Git?
#79don't get it yet, but learning / realizing that it can remote into other machines and execute commands (via SSH/server, so no other server software - like an HTTP server - is necessary) was definitely eye-opening.
Re: Ask HN: What made you finally grok Git?
#80I remember Git from the inside out and Learn Git Branching were very helpful when I started using git. The Git Command Explorer was good as well. Links from my notes below:
Git Command Explorer
- https://gitexplorer.com/ - https://news.ycombinator.com/item?id=28888763
Learn Git Branching
- https://learngitbranching.js.org - https://news.ycombinator.com/item?id=18504948
Git from the inside out
- https://codewords.recurse.com/issues/two/git-from-the-inside... - https://news.ycombinator.com/item?id=9272249