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

111–120 of 201 posts

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

#111

Post by whycombagator »

rendall wrote: post #94

I say, you have it right and your coworkers are less so. Encourage your coworkers to be secure in their work. Show your struggles, false starts, mistakes, typo fixes. Embrace the messy history! My last few teams' workflows and projects were such that commit history wasn't really a big deal. I'm skeptical that it matters if the dev-to-production process is smooth. These tips are habits we have: Keep commit message fir…

> Pretty much always do what a dev suggests in review, even if you disagree.

I disagree.

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

#113

Post by distortedsignal »

matticusrex wrote: post #46
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…

The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I think some GUI tools enable this, anyone know about it?

I use the interactive flag on git add for this. It lets you add parts of a file, commit, and then do it all again. I want to say it's git add -i, but I'm not 100% on that. My fingers just do the right thing when I want it to happen.

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

#115

Post by spookyuser »

git commit -m "Initial commit"

git commit -m "Add some stuff"

git commit -m "progress"

git commit -m "Add library"

git commit -m "Drop library"

git commit -m "Let's try this library"

git commit -m "Slider is working"

git commit -m "Fixing transparency issue"

git commit -m "Fixed"

git commit -m "I hate you"

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

#116

Post by WorldMaker »

My opinion is that the time for clean commits is the merge commits created by PRs. Git uses a two dimensional commit data structure and most git commands today take a --first-parent argument that gives you a smart, clean view of just the merge commits. It's only a bit of config work to make those your default aliases, and I just wish more UI tools defaulted to something more like it.

I don't necessarily care how "messy" the commits inside a PR are at that point if my default view is at the merge commit/PR level.

Teaching your coworkers how to use --first-parent may be beneficial to everyone and less stress than worrying about the peer pressure to conform to smaller "cleaner" commits.

That said, making cleaner commits is sometimes a useful skillset to learn for yourself. Sure, it can make code reviews easier, but it's advanced skills that take practice and most PR tools aren't particularly good at reviewing a commit at a time anyway so most PR reviews are entire PR at a time. I use tools like git add -p and git rebase --interactive as I feel necessary to clean up a commit narrative, but I also have a strong understanding of when not to force push and have years of "training" in these commands. I don't expect and don't want to expect junior devs to use them. I'm happy with the --first-parent approach to the DAG. I'm also always happy to teach junior devs how to use git add -p and git rebase --interactive, but when it is for them, when it is they who want to improve their skills.

A semi-related thing here is that the other way to remove a lot of "fix misspellings and whitespace" commits is to automate them away. Standardized formatters like prettier remove most of the manual effort of whitespace management. They can be setup to format on save in editors like VS Code. They can be added to pre-commit hooks. Similarly, many misspelling problems (certainly not all) get automated away with type systems and linters.

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

#117

Post by kjeetgill »

matticusrex wrote: post #46
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…

The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I think some GUI tools enable this, anyone know about it?

If you're a vim guy, I use `git difftool` setup with `vimdiff` for this. Let's say you have your changes in a branch CHANGES on top of public branch PUBLIC.

1. I `git checkout PUBLIC -b CLEANUP` to a new branch.

2. Do a `git difftool CHANGES`, which opens each changed file in vimdiff one at a time.

3. For each file, I use :diffput/:diffget or just edit in changes I want.

4. Commit these changes on the CLEANUP branch.

5. Use `git difftool CHANGES` again to see the remaining diff.

6. Repeat until the diff comes back empty!

My unstructured changes tend to contain a handful of small typo fixes, white spacing, localized refactors, and 1 or 2 larger refactors and a behavioral change. Once they're all broken out, It's usually easy enough to use `git rebase -i` and reorder the smaller changes first, put out PRs for just those first, etc.

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

#118

Post by wildpeaks »

When multiple people work in the repo, I like Squash Merge in Github best because you can still do small commits in your feature branch, and when you merge, it generates a message from all commits messages (so there is still a trace of the process, but you can get rid of noise like "fixed a typo" with the benefit of hindsight) and history looks clean because it's merged as a single commit, no rebase footgun to worry about.

https://docs.github.com/en/pull-requests/collaborating-with-...

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

#119

Post by bsimpson »

I have three branches: macbook, imac, and develop.

develop is the mainline branch that other people could pull from.

macbook and imac are each backups of their respective machines. I use git merge --ff-only to rebase commits from one to the other when I change machines. If I need to change machines midway through a commit, I'll push a WIP commit to imac, fastforward macbook to match, and then git reset HEAD^ to keep the WIP files (but undo the commit) on macbook. I finish on macbook, make the commit, and push it to origin's macbook and develop.

Like the others here, I make liberal use of git rebase -i to reorder commits, etc. If imac and macbook ever diverge (e.g. I forgot to push a commit before changing machines), I also use interactive rebase to resolve it.

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

#120

Post by rraval »

meowface wrote: post #74

>I also push often because I'm forever aware disks can fail. I'm not leaving a day's worth of work on my local drive and hoping it's there the next morning. I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing. I don't think git should be considered a substitute for a proper continuous backup system.

> I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing.

Motivated by a slightly different use case (seamless syncing across multiple machines), I built a custom tool that solves this concern within `git`: https://github.com/rraval/git-nomad

You can toss `git nomad sync` into a systemd timer (or cronjob if you prefer) and forget about it.

Post reply on HN