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

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

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 201 posts

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

#141

Post by camnora »

I tend to keep my PRs small enough to where several can be submitted within a day. This being said, I tend to keep my changes un-staged.

When I'm ready to commit:

1. `git diff` to get an overall picture of what changes were made. Which parts of this diff can be packaged into an isolated commit?

2. `git add -p` This is where I selectively stage bits.

3. `git diff --cached` to verify that the staged items are all in place

4. `git commit` with a detailed message.

5. Repeat steps 1-4 until all changes have been committed.

6. `git fetch origin main && git rebase origin/main`

7. Finally, `git push`

When PR feedback is left by peers, some teammates prefer you to not rewrite commits and force push. This makes re-review easier for them (especially if you use the Github features around PR review).

I opt for rewriting commits if it's okay with team members. This way you don't have "fix typo" commits getting merged into the main branch.

Edit: formatting

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

#142

Post by cosmosgenius »

ohmyzsh adds two git alias which I use very often `gwip` and `gunwip`. I push `gwip` commit for work which I am not clear on if to do a clean commit. Once I have settled on a unit of work ( like code + tests + docs ) I use `git add -p` to selectively create clean commits. For "fix misspellings and whitespace" kind of stuff use `git commit --amend --no-edit`.

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

#144

Post by cpcallen »

OJFord wrote: post #29
notapenny wrote: post #17

Earlier quoted context omitted.

It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.

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.

> And CI is building 'merge branch master', on the master branch, great.

How does one set this up in GitHub actions?

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

#145

Post by Consultant32452 »

andrewzah wrote: post #102
jawns wrote: post #9

Here's how I address this problem. When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits. This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes. Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i). This allows me to organize my commits. I can squash commits, amend commits, mov…

This is the ideal workflow for me since I think merge commits clutter up the log, but it falls apart if people aren't consistent in following it. *glances and $corp git repo and sees 'updates' 'fix' 'updates'. Sigh.

I've always been fond of the "WIP" commits.

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

#146

Post by nyanpasu64 »

jawns wrote: post #9

Here's how I address this problem. When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits. This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes. Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i). This allows me to organize my commits. I can squash commits, amend commits, mov…

I do the same thing generally. In fact I generally find multiple mistakes or changes to be made, reading over my own code before merging, requiring figuring out which commit to merge my changes into (git absorb helps in the easy cases) and even more rebasing, or giving up and adding an extra commit at the end.

I see some people whose projects (Furnace Tracker, PipeWire, previously Famitudio) seem to make progress very quickly without getting noticeably slowed down by technical debt, despite sloppy programming and unorganized commit logs (push-to-head). Meanwhile I move slowly, dread reviewing hundreds of lines of my own code, and produce technical debt (regrets) anyway, not as many surface-level lintable errors but plenty of entrenched mistakes. I wish I could move faster, but instead struggle to make progress.

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

#147

Post by nyanpasu64 »

OJFord wrote: post #29
notapenny wrote: post #17

Earlier quoted context omitted.

It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.

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.

FWIW I set pull.ff to only, since I don't want merge commits or rebases happening without explicitly calling pull --rebase or --merge.

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

#149

Post by gabereiser »

I got conditioned to commit early and commit often for much of the same reasons, hardware failures while dealing with code that touched hardware. GPU’s mainly. So I would commit and push to have CI do checks while I pushed more code changes so that I could reduce the cycle.

A few years ago, Acme Security Corp decided to use my commit frequency as an excuse to say “I didn’t know how to code…” and let me go. So really it’s all over the spectrum and the correct answer is, whatever your team is doing.

If they are holding back commits for uber PR’s, well, so should you. Are they in a commit frenzy and everyone PR’s all day long? So should you.

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

#150

Post by whoomp12342 »

commit early, commit often is really great for beginners. I dont do that. I commit when it makes sense to. Since my commits will get rebase squashed on merge into master, I dont put a ton of effort into doing it perfect.

Reasons I commit 1) it feels right, this was a good logical step 2) ima bout to do something that might break everything like a refactor 3) everything works so it makes sense to before I do something else

Post reply on HN