Ask HN: What is your Git commit/push flow? • Hacker News Board

Re: Ask HN: What is your Git commit/push flow?

#121

Post by formerly_proven » Thu, Mar 17, 2022, 6:49 PM UTC

lambic wrote: post #76

OJFord wrote: post #29

Earlier quoted context omitted.

Everyone absolutely should configure that. (Git config pull.rebase true.) Such an annoying mess it leaves otherwise. And CI is building 'merge branch master', on the master branch, great.

Are there any downsides to doing this? Why isn't it on by default?

> Why isn't it on by default?

Because git was written primarily for the Linux kernel and the defaults reflect that. The workflow of the Linux kernel is completely different from what most people outside of it do with git. "git pull" is used for opposite purposes in both worlds.

Re: Ask HN: What is your Git commit/push flow?

#122

Post by formerly_proven » Thu, Mar 17, 2022, 6:50 PM UTC

simlevesque wrote: post #98

matijsvzuijlen wrote: post #91

Earlier quoted context omitted.

Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.

> git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are gc grep init pull push

It's a separate package in some distros since it's written in Perl and uses Tk. gitk is often in the same package.

Re: Ask HN: What is your Git commit/push flow?

#123

Post by aurelianito » Thu, Mar 17, 2022, 6:51 PM UTC

Commit early. But do not commit garbage. Each commit should be a small but meaningful advance. All tests should pass. If working with compiled code, off course it should compile. No todos. No clunky var or method names. A branch per merge request.

If you do it like this it is great for everyone. Do not squash commits or rebase. Those are antipatterns. We are lying to ourselves when we do it. We cannot learn from history we rewrite.

Re: Ask HN: What is your Git commit/push flow?

#124

Post by heurisko » Thu, Mar 17, 2022, 6:53 PM UTC

lambic wrote: post #76

OJFord wrote: post #29

Earlier quoted context omitted.

Everyone absolutely should configure that. (Git config pull.rebase true.) Such an annoying mess it leaves otherwise. And CI is building 'merge branch master', on the master branch, great.

Are there any downsides to doing this? Why isn't it on by default?

I think it's the usually public vs private branch issue.

If you're merging a public branch with another public branch, then if you a rebase, rather than a merge commit, then you mess up the history for anyone has pulled that branch.

For private branches that isn't an issue.

Re: Ask HN: What is your Git commit/push flow?

#125

Post by setgree » Thu, Mar 17, 2022, 6:59 PM UTC

My main git case is idiosyncratic -- I use blogdown [0] to host my personal blog, which means I am first pushing the content to GitHub and then it gets built/deployed on Netlify.

I typically commit once at first as a pretty complete draft, and then every subsequent edit/revision is a commit and rebuild. This comes to 20-30 commits per post, and some are indeed like 'fixed a spelling error'.

For this case, the benefits of being a frequent commiter clearly outweigh the costs.

[0] https://bookdown.org/yihui/blogdown/

Re: Ask HN: What is your Git commit/push flow?

#126

Post by sbinnee » Thu, Mar 17, 2022, 7:02 PM UTC

chaitanya wrote: post #97

You can have the best of both worlds -- "commit early, commit often", and "nice clean commit histories" -- with git, and it is easier than most people think. - So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit". - Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this d…

I like --amend a lot too. Usually a new feature requires a few steps. I commit every step and make a list in git commit body. It's basically almost same as rebasing at the end, but amending seems more logical to me.

Re: Ask HN: What is your Git commit/push flow?

#127

Post by TillE » Thu, Mar 17, 2022, 7:05 PM UTC

twofornone wrote: post #22

>I also push often because I'm forever aware disks can fail. In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.

I've had a Macbook SSD fail (suddenly and completely) within the warranty period. Surprisingly I've only had one hard drive fail before I retired it, maybe when it was about 6 years old.

But those are just the catastrophic failures, I'm pretty sure I've also had hardware-related data corruption here and there as well.

Re: Ask HN: What is your Git commit/push flow?

#128

Post by Drdrdrq » Thu, Mar 17, 2022, 7:10 PM UTC

I try to make clean commits that do one thing only. If I have trouble writing a meaningful commit message, it means I have failed and should do a better job next time.

That said, I often make a messy "wip" commit that I push to my branch, just so that the work doesn't get lost. But I always undo such a commit and clean it up.

Also, I always use git add -p, so that I can break changes into multiple meaningful commits and review them one more time before pushing.

Re: Ask HN: What is your Git commit/push flow?

#129

Post by conradludgate » Thu, Mar 17, 2022, 7:19 PM UTC

beders wrote: post #108

immutology wrote: post #105

Squash-merge PRs. You can configure this in GitLab, GitHub, and Azure DevOps. Your private commits can be whatever you want and they get rolled up to a single PR commit when your working branch is merged to trunk.

Yes. Much easier to roll back things, cherry pick things and blame people ;) Don't you dare merge a PR with 30 commits.

+1 to this. I like the mantra that every commit is deployable

Re: Ask HN: What is your Git commit/push flow?

#130

Post by shoo » Thu, Mar 17, 2022, 7:21 PM UTC

always use `git add -p`. review each individual hunk before staging it into commit. dont blindly add everything.

once you've got it working, do a second pass on the commit history and compress it into one or more coherent logical commits, reordering or squashing changes as necessary. learn the interactive rebase interface. lots of operations of the form `git rebase -i HEAD^^^^^^`

where necessary, if you need to erase your old messy history from a feature branch and overwrite it with your tidied up commits, `git push --force-with-lease some-remote some-feature-branch`. in general, avoid using `--force`, and if you ever believe you need `--force`, prefer `--force-with-lease` . the latter avoids some failure modes related to race conditions where a coworker pushes some commits and your concurrent `--force` push that lands a few seconds later blows them all away.