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

61–70 of 201 posts

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

#61

Post by btschaegg »

Not entirely unlike yours, but I also very often use `git commit --fixup` and let the computer clean up large portions of my messes with `git rebase -i --autosquash` later.

That is, nowadays I usually do the same, but through Git Fork [1] (via its custom command system), and it works even better than the terminal interface for me -- which doesn't happen often. But for fixups the "find the target commit in the history and use a context menu entry to flag your commit flow" really works rather nicely.

Also, Fork's interactive rebasing dialog does `--autosquash` by default.

[1]: https://git-fork.com

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

#62

Post by elpakal »

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 this (kind of too), but instead of an interactive rebase I just do a `git reset --soft `, where target_branch is the local (and up-to-date) copy of my target branch. That gets me one clean commit that I can force push up to replace my branch @ remote.

(This works for me because auditing commit history is not important where I work, if it were I would organize commits better.)

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

#63

Post by mariusor »

btschaegg wrote: post #60
matticusrex wrote: post #46

Earlier quoted context omitted.

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?

Have a look at `tig`. It's even included in Git for Windows now and does this reasonably well. Only the keybindings are a bit weird if you're not accustomed to Vim bindings: - Open tig - Change into the staging view with `s` - Select your file using the arrow or `j` and `k` keys - Press Return to show the diff - Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files) - Stage parts with `1`…

"s" is status view, which you can also get at by running "tig status" directly.

"c" is staging view.

> - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\`

You can also revert a chunk or file by using "!". Sometimes this is very useful.

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

#64

Post by btschaegg »

mariusor wrote: post #63
btschaegg wrote: post #60

Earlier quoted context omitted.

Have a look at `tig`. It's even included in Git for Windows now and does this reasonably well. Only the keybindings are a bit weird if you're not accustomed to Vim bindings: - Open tig - Change into the staging view with `s` - Select your file using the arrow or `j` and `k` keys - Press Return to show the diff - Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files) - Stage parts with `1`…

"s" is status view, which you can also get at by running "tig status" directly. "c" is staging view. > - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\` You can also revert a chunk or file by using "!". Sometimes this is very useful.

Ah, thanks for the correction :)

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

#65

Post by yodsanklai »

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?

The way I deal with this is 1. try to make commits small enough so you are less likely to split them after the fact. 2. when I need to split a commit, I use VSCode UI and apply patch by patch. This is one of the rare case were I use a GUI for git. For most other things the command line is fine.

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

#66

Post by wry_discontent »

For smaller PRs/bugfixes, I'll often just have 1 commit, and that's all it took me to write.

For bigger things, I do stream-of-consciousness, rebasing somewhat often when I get to a place where I like things.

Unfortunately we're all about merging, so that mucks up my commits a bit.

I use Magit to handle all that for me, which is by far the nicest git interface I've ever used.

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

#68

Post by mattwad »

I squash all commits in a PR as a clean commit. I don't see any benefit to knowing when or what someone did other the past few weeks to get to the point we're updating the main branch, and i don't want them to waste time either. If your PR is so large you need to review it as individual commits, maybe your PRs are too big.

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

#69

Post by jedimastert »

The git history on my personal/dev-machine are an absolute mess that I try to optimize for `git bisect`, so preferably each commit should compile (and I usually commit whenever a new part of the requirements is introduced/a new test passes)

The way our code review system works is essentially each upload is a commit, so the review's history is like a compressed version of the local git history. I usually upload when I think the branch is "complete"/will pass all of the CI, and ~once per round of comments.

The main git history is squash-and-rebase, so one commit per code-review, with the CR description serving as the commit message (with automatic links to bugs and code reviews and the like).

I personally like the squash-and-merge strategy for the main branch, it makes the most sense (especially when the code review's history is still around after)

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

#70

Post by lmarcos »

I used to do exactly what you described a few years ago (when I was learning git for the first time). Not anymore. A few reasons:

- commit early/commit often. I usually push one commit when I think the feature is done. While others do a review of my code, I commit to improve the code/fix the issues found by others. The advantage here is that future readers looking at the history of file X line N can know what other files were introduced alongside file X (as a reader of big codebases, this is a nice side effect). I don't like hiding defects either from the git history (one could in theory squash all the commits of a given PR in order to keep the "history clean"... In my experience having a trace of bugs fixed at PR time, or other subtle details is also worth it and serves as documentation of what not to do).

In the cases I need to work through many days in a single feature, and only if the feature is so complicated/critical than I cannot reproduce it from scratch by myself again, then yes I push the progress upstream. This is usually not the case though: I stash progress. I tend to open small PR and usually I remember what I've done (so I could write the entire code again easily). Plus, hard drives fail, sure but they are also quite reliable. In 20 years of work I never experienced losing "non critical" work because of disk failure (for critical work, I for sure have a different workflow).

Post reply on HN