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

101–110 of 435 posts

Re: Idiot Proof Git

#101

Post by eloff »

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…

I really like squash merges because then you know tests passed at every commit. Makes bisect easier, and thus more likely to be used. And no headaches when you can't rebase or you screw up a rebase, which will happen.

Re: Idiot Proof Git

#102

Post by jamisonbryant »

ccity88 wrote: post #90
stblack wrote: post #38

I might be mistaken but this post is basically describing git-friendly which I've used for years, is 100% flawless, and you'd need to pry from my cold, dead hands. https://github.com/git-friendly/git-friendly

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…

> Learn both. Use the easier one.

This is a great point that I will be sharing with my team. Sometimes (most of the time) I use the git cli, and sometimes I use the built-in Git pane in VS Code.

I have not used GitHub Desktop in quite a while. In your opinion does it make the commit graph easy-to-read? Because I have not found a tool _yet_ that makes that diagram easily parseable by the human eye. It just looks like a mountain of spaghetti commits linked together with a myriad of colored lines.

(I realize that part of the cause of my confusion is crappy discipline around commit history, but what can you do on a team of a certain size where you're not the lead? Just have to suck it up.)

Re: Idiot Proof Git

#103

Post by seba_dos1 »

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…

This is like throwing away 90% of usefulness that git provides you. That's what you get if you don't wish to spend some time learning one of the most important tools in your career.

Re: Idiot Proof Git

#104

Post by Zitrax »

vultour wrote: post #75
fs111 wrote: post #51

Earlier quoted context omitted.

fix typo yet another typo test fix aaah, why is this test failing? merge foobar/narf revert foo foo Is just not a good history to preserve

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.

Re: Idiot Proof Git

#105

Post by throw827474737 »

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…

Not shared much opinion by something like half of all git users likely... as any absolute opinion. Also can only counter the insults by responding: you are a fanatic by using git for backup and work tracking, which in contrast to you, I wouldn't condemn you for ;) everyone/team can use a tool for what fits best and is their use case.

So far I had never lost data ever with git, just confusing git situations from people who never rebased, but still shoot into their own foots with duplicate commits added by helplessly merging around multiple branches too much, all with much too many "fix typo" commits and then unresolvable conflicts :D

(Oh, and btw, when people end up there and I'm asked to get them back to sanity, it usually involved rebasing or cherry-picking them out of their messes).

Re: Idiot Proof Git

#107

Post by G3rn0ti »

Someone1234 wrote: post #99
krossitalk wrote: post #92

Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.

Git like Regular Expressions I've "just learned" half a dozen times already but then forget everything and have to "just learn Git" top-to-bottom again and again. It really is a shame, Git has a great under-the-hood design (excluding poor binary file support), and such a terrible interface/UX that seemingly can never be outright replaced, so we're stuck with a good tool surrounded by needless confusion forever.

The way to get „git“ is to think about version management as a concept i.e. starting top down. It’s the implementation details of git that many developers get confused about. But they don’t matter.

It’s similar to recursions: You don’t try to understand a recursive function by mentally evaluating it — instead you reflect on its desired return value and how to construct it in the base case.

Re: Idiot Proof Git

#108

Post by MetaWhirledPeas »

I understand generally what Git is doing, but when you start throwing in very specific words like "rebase" my eyes start to glaze over. Not because they aren't important concepts, but because I can't stop the nagging feeling that it shouldn't be this complicated (it probably should though).

But it isn't complicated! When you use a decent UI tool. I know pretty much exactly how VSCode's UI behaves with Git, along with the Git History plugin. And now I have a perfectly usable workflow and never have to use the command line, and almost never have any merge conflicts.

Maybe this is common knowledge to all of you, but it seems to me a lot of people have Git headaches, so maybe they don't know this?

1. Pull latest from remote main branch (select the branch, hit the sync button; permissions structure prevents any accidental pushes)

2. Create new branch based on pulled branch. If I have stashed work, apply it now.

3. Do work

4. Use the + icon to stage individual changes and give them their own local commit

5. Push my local branch to remote (hit that sync button again)

6. In my remote repo UI push the button to create a Pull Request (I assume all shared repos have a PR button somewhere?)

7. Go back to doing local work, but don't commit yet, and continue "not committing" for now

8. After the PR has been merged into main, stash everything including untracked (pick it from the VSCode menu)

9. Go back to step 1, repeat

Steps 7 and 8 are how you avoid creating your own merge conflicts. If you keep committing while a PR is in flight, then later on Git will see your earlier changes to a file, and your later changes to the same file, and will see them as a conflict. So just do yourself a favor and never commit to a branch while anything in its history is part of an in-flight PR. Obviously you'll have to deal with merge conflicts with other people but at least you aren't creating your own headache.

Git History saves me when I goof up and commit locally when I shouldn't. I just pull up the history and click the soft reset button prior to my commit and presto, I'm back where I want to be (files uncommitted, back in pending changes list).

Maybe one day I'll learn the Git command line, but right now why bother?

Re: Idiot Proof Git

#109

Post by seba_dos1 »

Someone1234 wrote: post #99
krossitalk wrote: post #92

Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.

Git like Regular Expressions I've "just learned" half a dozen times already but then forget everything and have to "just learn Git" top-to-bottom again and again. It really is a shame, Git has a great under-the-hood design (excluding poor binary file support), and such a terrible interface/UX that seemingly can never be outright replaced, so we're stuck with a good tool surrounded by needless confusion forever.

My experience is that once you understand the (high level) data structure you're manipulating by using git, you have already made 80% of the way there. I barely know basics of git's interface and have to use tools like `git gui` for anything more complex in my everyday workflow, yet I can manage just fine even when presented with complicated problems, since once I know from the data structure perspective what I want to do, finding a way to do that in git's interface by searching manpages and/or the Web is hardly ever a big issue.

Re: Idiot Proof Git

#110

Post by wackget »

eru wrote: post #59
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".

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?
Post reply on HN