Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

231–240 of 435 posts

Re: Idiot Proof Git

#231

Post by __blockcipher__ »

RadiozRadioz wrote: post #134
ccity88 wrote: post #90

Earlier quoted context omitted.

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use…

The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important. In my experience mentoring juniors new to git, those who are jus…

> As a really simple example, one of the most frequent things I see from juniors using git GUIs is adding files to a commit that they didn't intend to (say stuff that's not in the .gitignore, but doesn't belong in the commit). In the CLI, they probably don't know about -a, so they would be forced to add files/directories individually and think about what to include. Most GUIs I've seen include a "Stage All" button front-and-center, which is very tempting for a new user to click (or, worse, they make staging an opt-out thing). I do not know if this specific example is the case in GitHub Desktop, it's something that I see regularly.

I agree with your general point, but on this specific point I'd be remiss if I didn't mention that I see an insane amount of people regularly use `git add .` to add every file, because they don't realize they actually want `git add -u` (only add already-tracked files) 99% of the time.

But as a counterpoint, since your example is about giving devs a limited set of commands, you naturally wouldn't be giving them `git add .`. But it's definitely something that frequently comes up in crappy git tutorials.

Re: Idiot Proof Git

#232

Post by __blockcipher__ »

GuB-42 wrote: post #215
alexb_ wrote: post #48

What's the deal with squashing commits anyways? I'm genuinely asking, because I've only worked with "squash everything before you put it up for review" but have never really figured out why past "it's what we've always done".

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing is lost, what you see is what really happened and you won't make a mess with inappropriate push --force. The downside is that it looks messy since you are going to see every typo and you will have some non functional code in your history. People using that workf…

It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understanding of the codebase. Why do I say that? Well, because once you've come across a useless typo commit for the 12th time, you start to very quickly see how such commits needlessly bloat the history and make it far harder to understand (and make things like git blame much more unwieldy), while not actually offering any benefit.

It doesn't matter to me at all 3 months later to know that you initially had a typo in your first commit and then fixed it the subsequent commit. That should just be a single commit.

There are some very rare edge cases where having the whole messy history can offer some insight of how a certain mistake ended up being made, but IMO in 999/1000 cases that's not the case.

Re: Idiot Proof Git

#233

Post by __blockcipher__ »

wackget wrote: post #110
eru wrote: post #59

Earlier quoted context omitted.

So there's (at least) two uses for commits. The first is to keep a log of what you are working on. For me, that's lots of small and dumb commits. The second is to provide a story for review. Most of the time, when the change you are putting out for review is small and simple, you can just put it all into a single commit. Sometimes, your change is more complicated and it makes sense to break it into a series of relate…

Why wouldn't you use a local branch (or something?) for your ugly commits and then merge everything from that branch into the main shared branch when you're done?

Because then you're going to merge in the ugly commits and make everyone who needs to look at the history in the future have to work that much harder to understand what's going on.

Re: Idiot Proof Git

#234

Post by evandale »

Izkata wrote: post #188
evandale wrote: post #154

Earlier quoted context omitted.

You'll have to elaborate with specifics because in my experience it doesn't matter if there's 100 or 10000 commits - git bisect works great in both instances.

It works, but it works better when you have the original 10000 commits. You can tell exactly what the committer was attempting when the bug was introduced. It may have been as a fix to something else, it may have been a typo when linting, it may even have been been intentional and the bug report is wrong. Other comments I made on another recent git post: https://news.ycombinator.com/item?id=33395616 https://news.ycom…

Hah, I must admit I thought you meant that you preferred squashing! Agree 100% that a huge number of small commits are easier to find bugs in than a small number of huge commits.

Re: Idiot Proof Git

#235

Post by kazinator »

GuB-42 wrote: post #215
alexb_ wrote: post #48

What's the deal with squashing commits anyways? I'm genuinely asking, because I've only worked with "squash everything before you put it up for review" but have never really figured out why past "it's what we've always done".

There are essentially two approaches: - History is sacred and can't be changed. It typically goes with a merge-based workflow. The good thing is that nothing is lost, what you see is what really happened and you won't make a mess with inappropriate push --force. The downside is that it looks messy since you are going to see every typo and you will have some non functional code in your history. People using that workf…

Projects should rewrite their public history from time to time, for instance to get rid of commits that never should have happened, or move changes between commits, fix commit messages and such.

The history should be treated as the perfect object to develop. We should continuously revise how this program should have been developed to its current state, by what sequence of changes.

Re: Idiot Proof Git

#236

Post by prettyStandard »

OkayPhysicist wrote: post #194
opsy_ wrote: post #146

Earlier quoted context omitted.

Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR. Not to say that doesn't make for a good learning moment.

At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.

Haha. what's the git reflog talk? To be clear I know what reflog is, but what's "the talk"?

Re: Idiot Proof Git

#237

Post by __blockcipher__ »

Zitrax wrote: post #104
vultour wrote: post #75

Earlier quoted context omitted.

Boggles my mind how so many people in this thread are against rebasing. Have they never needed to remove these commits? I do that pretty much daily, especially when troubleshooting something in a CI pipeline.

I prefer rebasing too, but merging doesn't mean that you have to merge in all noisy minor fixups, you can combine the strategies and rebase the feature branch into a set of sensible commits, then merge that branch. Preferably even with a CI that checks each commit before merge such that it will not cause issues later during eventual bisections. --fixup and --autosquash are handy for such workflows.

Using interactive rebase in that way is a great tool, but we're talking about people that are against rebasing in general, so it's not the most relevant point IMO.

i.e. the anti-rebase people are usually of the "never rebase" flavor. Because they're also the "history is sacred even though I never look at history because if I did I would get dizzy and throw up" crowd :P

Re: Idiot Proof Git

#238

Post by Sverigevader »

Nice page! Very well made and great explanations. However; I'm a big fan of aliases in git, but I don't think this is the way to go personally. Knowing the difference between rebase and merge is vital, and I think it's worth the time investment to learn git properly.

It took me 1 month of painstakingly learning the git CLI and I'm happy I spent the time. Before that I was using a GUI and was essentially afraid of git.

I'm no longer afraid. Instead I'm actively exploring ways to do things faster and/or smarter every day.

This happened when I switched jobs recently and came into contact with a fantastic developer and patient teacher. Doing it myself would have taken a bit longer and I wouldn't be able to see how much it would be worth it.

I'm enjoying a rebase workflow everyday. And I especially like the -i flag for interactive rebasing;

  git rebase -i
Same with -p for interactively adding code/files before commits

  git add -p
I read the first three chapters of the git-scm book[0] and it made a world of difference in understanding what's actually going on.

[0] https://git-scm.com/book/en/v2

Re: Idiot Proof Git

#239

Post by theonething »

aulin wrote: post #202
cube2222 wrote: post #169

Earlier quoted context omitted.

This is basically solved by squashing each PR on merge and having a good PR title + description.

why would you squash multiple informative commits with their commit messages and their informative context about your thought process into a single big squashed commit? git can merge branches and keep track of it, there is no need to squash unless you split trivial changes that belong together and want to group them before sharing them

> no need to squash unless you split trivial changes that belong together

If a PR represents a distinct product feature/bug fix/unit of work, one could argue that its commits belong together.

Squashing makes for a very clean history. True it reduces granularity, but in my opinion at least, it's a good level of granularity.

The exception to this would be a really big PR. That's a reason to avoid huge PRs.

Re: Idiot Proof Git

#240

Post by __blockcipher__ »

andrewvc wrote: post #31

Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…

> Since moving to this workflow I’ve had zero issues losing data due to a confusing git situation.

Nobody who understands git will ever lose data, because once committed you can never lose it (it's in the reflog). Indeed, even just adding a file means you will never lose it, although it's not as convenient as having an actual commit.

So yeah, you kind of revealed the anti-rebase case quite tellingly there. It's for people that understand git so poorly that they regularly shoot themselves in the foot and lose work or make other similar mistakes.

> Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice.

PRs and good git commit history are not mutually exclusive. But there are many drawbacks of trying to make PRs themselves your source of truth. A big one being that it's not actually stored in git, so if you ever migrate from github to gitlab or some other system, that context is gone.

> Configure GitHub or whatever you use to squash merge only and you’ll be good.

See, now this becomes even more absurd. What's your fear of rebasing if you're going to do the equivalent of a `git rebase -i` upon every merge anyway?

This is a very confusing and nonsensical ideology.

For those who want to improve their grasp of git, I highly recommend https://git-scm.com/book/en/v2. That book changed the game for me, because I finally understood how to visualize git history in terms of the DAG, and furthermore learned about how git actually works under the hood (blobs and the like) which made me confident I would never lose anything I've ever added/committed ever again.

Post reply on HN