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

171–180 of 201 posts

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

#171

Post by seba_dos1 »

conradludgate wrote: post #129
beders wrote: post #108

Earlier quoted context omitted.

Yes. Much easier to roll back things, cherry pick things and blame people ;) Don't you dare merge a PR with 30 commits.

+1 to this. I like the mantra that every commit is deployable

"Every commit is deployable" isn't at odds with merging multi-commit MRs, provided that the submitter actually did their job well. I find squash-merging to be an ugly workaround, not a proper solution. Good non-trivial merge requests should usually consist of multiple commits that improve readability, revertability, cherry-pickability and blamability ;)

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

#172

Post by ge96 »

I commit chunks of work, so I can view that functionality/diffs in one segment. Can squash it later. I do try to save "often" in case something happens. I'll just push something up like "progress save".

I've seen some people commit like 40 changes in a PR lol. Happens just squash it.

Can also use another branch

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

#173

Post by mgkimsal »

wodenokoto wrote: post #89
deckard1 wrote: post #79

The flow you use will typically depend on the company you are working for. Using regular git (no Github/Gitlab) will often have a different workflow than Github. My team (and myself) prefer this workflow: - One commit per PR. This allows for easy reverts and cherry-pick. - One developer per branch. You can do a few devs per branch, but rebases need to be coordinated and carefully handled, because: - No merge commits.…

> - One developer per branch. I had never even considered that some teams might have multiple developers active on the same branch.

hrm.... I do this occasionally with some other folks on a project. often it's fe/be concerns - one person needs something added in a payload, for example. Working in their same branch to add that for their environment/branch was much faster than trying to coordinate a series of other changes/branches. It's not something I/we do a lot, but the few times we've done it in the last couple of months people have really liked it, and seemed to feel like we were making faster progress somehow.

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

#174

Post by Noumenon72 »

mgkimsal wrote: post #173
wodenokoto wrote: post #89

Earlier quoted context omitted.

> - One developer per branch. I had never even considered that some teams might have multiple developers active on the same branch.

hrm.... I do this occasionally with some other folks on a project. often it's fe/be concerns - one person needs something added in a payload, for example. Working in their same branch to add that for their environment/branch was much faster than trying to coordinate a series of other changes/branches. It's not something I/we do a lot, but the few times we've done it in the last couple of months people have really lik…

Yeah, it's really cool when you're on calls supporting each other and the branch is moving forward twice as fast.

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

#175

Post by bmn__ »

formerly_proven wrote: post #122
simlevesque wrote: post #98

Earlier quoted context omitted.

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

It's a separate package in some distros since it's written in Perl and uses Tk. gitk is often in the same package.

Both git-gui and gitk are in Tcl, not Perl.

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

#176

Post by musicmatze »

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 github. Commit history has to be crafted like code, by the developer who wrote that code and in a way that other developers can see the steps that were taken to craft that code. Squashing PR commits just removes all of that, resulting in a SVN-style repo with "checkin 2020-01-01" like commits. Yes, there might be more in the commit message, but its value is lost because it is not for a small, possibly atomic change.

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

#177

Post by musicmatze »

deckard1 wrote: post #79

The flow you use will typically depend on the company you are working for. Using regular git (no Github/Gitlab) will often have a different workflow than Github. My team (and myself) prefer this workflow: - One commit per PR. This allows for easy reverts and cherry-pick. - One developer per branch. You can do a few devs per branch, but rebases need to be coordinated and carefully handled, because: - No merge commits.…

> - No merge commits. Only rebase onto latest main. Which means force-pushing PR branches and, thus, rewriting history (other devs working on same branch need to be aware that history has changed).

How does that even scale? I would imagine that in a team of 10, you would be rebasing 90% of your day and only 10% doing actual work?

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

#178

Post by musicmatze »

It really struck me to read how many people have a "I don't give a f..."-style workflow with git, especially in the hackernews audience which I always considered to be more on a technical side.

With "I don't give a f..."-style I mean basically the idea that just committing away with some "wip"-style messages and then squash them all together before merging, or squash-merging them. This _kills_ all traceability and all future options to find out what was happening and _why_ (the whole reason git exists)!

In constrast, my workflow:

- Branch off of master

- Develop things, commit cleanly (which sometimes means 10s of lines of commit message for less than 10 lines of change!)

- Before everything goes into review, I revisit each commit. If there has to be formatting done, I create fixups for the individual commits and `--autosquash` them into the PR commits. Sometimes I even do something like `git rebase master -x "cargo fmt && git commit --amend --no-edit -a"` to automatically format each patch in the PR before submitting (or if I just missed to do it).

- Submit PR

- For each review comment, I create a fixup commit. As soon as I addressed all of the comments, I push the commits to the PR

- Repeat the step above until everyone is satisfied

- `git rebase master -i --autosquash` or, if master changed, sometimes even `git rebase $(git merge-base master HEAD) -i --autosquash`

- Wait for the PR to be merged

When a PR is ready, it could be one patch only, but also easily be 50 patches. Depends on the scope and size of the project and the PR of course.

This is my workflow for contribtions, both private and professional ones, but also for my private repositories (whereas "review" here is my own but also simply CI).

When working on projects on github in my free time, I even stopped submitting patches (after discussion of course) if projects use squash-merge, because if I put much thought and careful crafting into my commits and they just squash them anyways, I feel that they don't actually care and so there's no point in contributing for me.

(Edit: Formatting)

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

#179

Post by ponsfrilus »

seba_dos1 wrote: post #169
dimtion wrote: post #25

The most important git feature I discovered was `git add -p`, this allows both to select which patchs to stage, but also to do a review of what you are going to stage. Combined with `git commit -v`, this allows you to have plenty of occasions to review your changes before creating your pull request. Shameless plug, but here are other efficiency tips I wrote about, for working in a high demanding environment: https://…

For tasks that you have mentioned, there's also built-in `git gui` for those who prefer to click.

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

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

#180

Post by ponsfrilus »

ponsfrilus wrote: post #179
seba_dos1 wrote: post #169

Earlier quoted context omitted.

For tasks that you have mentioned, there's also built-in `git gui` for those who prefer to click.

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.
Post reply on HN