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

Additionally, git itself comes with a simple `git gui` command that allows you to do partial commits on a line by line basis. It also has a nice "amend last commit" mode.

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 first line to under 50 characters, use imperative mood, capitalized. If you need more than that to describe what's going on then the commit might be too big.

PRs must pass all continuous integration tests + 1 or 2 devs approval. Pretty much always do what a dev suggests in review, even if you disagree.

Optionally, squash merge PRs to master, to make reverting easier. I prefer that.

If a feature is very complicated, break it down into smaller tasks, merging each to master when completed.

Maybe use a feature branch for super complicated inextricably tasks, but doing that too often is a code smell.

In that situation, code history isn't really that important.

That said, if you're still keen, look up these commands:

  git commit --fixup {commit id}
  git reset --soft {something}
  git rebase -i --autosquash {commit id}

Those can straighten out your history right out.

For that use case, if you are sure you don't want the intervening history in the main source repository, is to keep your “scratch” commits to a local store. This could be a branch, or a separate repo.

For my work areas I have a timed rsync taking snapshots, and can kick it off manually if I want to make a snapshot for a specific time (just finished debugging a major function, for instance). If there have been no changes since it last run the snapshot is not kept (just a note added to a file to say one was considered at that time). Identical files are all hard-links to the same data so it is pretty space efficient unless you have some large assets that change regularly. This has the advantage that I don't even have to remember to commit to anything: the snapshot is automatically taken regularly. Rolling back is manual, but rarely needs to be done and can be done easily for small parts of the update if the rest needs to stay.

Every now and then, as this is just backing up temporary work status, clear down snapshots older than a given point in time. Using a source control repo and auto-committing to that would work as well as creating filesystem based snapshots like I do I should think, but all my other backups were rsync+snapshot based when I set this up so I just repurposed existing scripts for the job.

> 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.

Keep the snapshots on a different drive, or even a different machine (they are mostly in my case, though “just because it happened to get laid out that way” rather than by thoughtful design). Mine are even covered by daily off-site backups so if the place burns down overnight I still don't lose them (or at least absolutely no more than a day's worth). Just be careful with rsync, if you use this method, due to the many hard-links as the --hard-links option can be quite CPU and memory intensive, and if your backups are usually append-only you'll need to occasionally wipe old snapshots that are long since irrelevant.

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