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

191–200 of 201 posts

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

#191

Post by mjmj »

wildpeaks wrote: post #118

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…

For our company squash merge simplifies cognitive load when a bad commit is deployed to production. There’s exactly one commit that caused the issue and one commit to be reverted. Also very easy in CI to deploy previous commit to revert back to steady state quickly before debugging whatever the issue is.

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

#192

Post by blindmute »

musicmatze wrote: post #176
wildpeaks wrote: post #118

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…

IMO this feature destroys the history the developer of the PR should have crafted carefully in the first place. With a squash merge you basically say "I don't give a f..." and remove all traceability from the PR, giving future developers potentially a big headache if they have to figure out why something was done. That's why I think squash merge should _never_ be used and is one of the very big anti-features of githu…

The squashed commit message should include comprehensive documentation of what happened in the commit. There's no reason "check-in 2020-01-01" should appear anywhere. In the extremely rare case of needing to see how the commit was written step by step, the PR is still there.

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

#193

Post by dusted »

We're using gerrit and so when I have enough that I consider it worth keeping, I commit it and push it as a new change, I don't put anyone on review. I continue working, and doing commit --amend and upload until I'm done. Then I put people on review on fix whatever they come up with, and do the last commit --amend and push the final change. When QA accepts it I either submit, or rebase (if that is trivial, I submit, otherwise, I repeat the review, then submit when it has +2).

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

#194

Post by 8b16380d »

convolvatron wrote: post #166
bjourne wrote: post #83

Here is my last five commit messages: "width*height is area", "fixing stuff i broke", "rm properties we dont need", "rm more useless attributes", "nicer figures". I do my best to keep the code base as clean as possible, but I couldn't care less about keeping the commit history pretty. Any time spent on prettifying git history is better spent on documenting the existing* code imo.

thank you for saying this. I'm always afraid to. revision control is a necessary safety net and facilitates discussion around changes (PRs). but people act as if the history is somehow _really really important_. I've seen someone post on HN, apparently seriously, that the history is more important than the source. I know a (potentially) really good developer that spends his time pulling in the recent patches and reor…

Yeah I love picking my way thru junk commits/comments. You may as well not use VCS.

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

#195

Post by seba_dos1 »

ponsfrilus wrote: post #180
ponsfrilus wrote: post #179

Earlier quoted context omitted.

Where is that? `git: 'gui' is not a git command. See 'git --help'.`

Got it, it is not built-in on all distros. Head to https://git-scm.com/docs/git-gui/ and https://github.com/prati0100/git-gui.git/ for more.

It is part of git, some distros just split it out to a separate package ("git-gui" on Debian) to avoid pulling GUI dependencies in unnecessarily.

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

#196

Post by convolvatron »

8b16380d wrote: post #194
convolvatron wrote: post #166

Earlier quoted context omitted.

thank you for saying this. I'm always afraid to. revision control is a necessary safety net and facilitates discussion around changes (PRs). but people act as if the history is somehow _really really important_. I've seen someone post on HN, apparently seriously, that the history is more important than the source. I know a (potentially) really good developer that spends his time pulling in the recent patches and reor…

Yeah I love picking my way thru junk commits/comments. You may as well not use VCS.

what were you hoping to accomplish in the first place?

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

#197

Post by atmosx »

Branch out

break down work to logically separated commits (one logical change at a time)

Fixups will eventually come when I change something that should be two commits down.

Make sure commit history makes sense to the reviewer

Explanatory commit messages: the why (this library did not fit the bill because ABC)

Open the PR

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

#199

Post by kazinator »

I often have several "topics" going on in the same branch, for which there are existing (unpublished) commits.

When I make some small change, it usually belongs to one of these topics. If it's the topmost commit, of course it can be combined into it with "git commit --amend --patch".

If the small change for one of the commits behind that one, then I make fixup commits with "git commit --fixup " or "git commit --fixup HEAD^^^" (as many carets as needed to refer to the commit I want).

If the little fix requires an addition to the commit message, then --squash instead of fixup.

These little fixup/squash commits can then be squashed into their target commits using "git rebase -i --autosquash".

That may be how some of your coworkers have clean histories.

In some environments, a change made up of numerous little commits like "fix typo" wouldn't pass peer review ; you're supposed to know ho to squash things together (but not too much so that topics get inappropriately combined).

Some shops have a policy that every commit has to build and possibly also pass the test cases. So you can't have an "oops, add missing semicolon" commit; its parent wouldn't build.

Commits should be like Stack Overflow answers: "is this useful to future visitors of this git history?"

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

#200

Post by nickm12 »

I've read a fair number of the top level comments and I don't see anyone who develops like me, so I'll throw my hat into the ring. I'll start by saying that I've always worked at companies where the norm is trunk-based development, where the norm is to develop small changes (The way I build these commits is to check out the main branch and start coding. As I write code/tests/documentation I start staging (git add) and committing (git commit) into a single commit. Subsequent commits are "git commit --amend". When I commit I usually update the commit message with any details about the stuff I'm adding.

Changes in the commit I'm pretty sure are going to be in the CR, staged changes I'm not sure about, and unstaged changes are "what I'm working on now". This way, "git diff" shows me what I'm working now (in case I'm interrupted) and "git show" shows me what I'm ready to push. If I want to sync with the trunk, I can do "git stash && git rebase && git stash pop", which mostly works well though sometimes there are merge conflicts that need resolving.

When I'm ready for review, I rebase my single commit, rerun any tests, do a git show and review the change top to bottom, then create the code review. Then I review the change again in the code review tool, where I quite frequently find silly things I missed like typos in documentation of print statements I forgot to remove. Then add reviewers.

The only downside to this I have is when I want to back out changes I've already committed. Git doesn't give you a great way to do this, but I've written an alias that can remove all changes to a file from the commit at the tip of the branch. I use this a couple of times a year.

Post reply on HN