Ask HN: What is your Git commit/push flow? • Hacker News Board

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

#181

Post by 74ls00 » Fri, Mar 18, 2022, 7:42 AM UTC

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…

Yes, going back and understanding why something broke/has changed is incredibly valuable. Often it's not because of one singular decision but a collection of decisions over time that resulted in some behavioural regression. Being able to easily hop through all the commits of the recent past is incredibly valuable for me to understand how we can prevent such errors in the future, not just patch over the current one and move on. Fixing things without considering how we got here I tend to find leads to messy code; extra checks and assertions that aren't necessary if one takes the time to update the underlying assumption or modules that end up too tightly coupled because an extra bit of logic is added to fix that one bug.

Obviously it's possible to go too far; not every commit needs an attached essay. Many of my commits are just "fixed typo" or "added unit test for X", but then sometimes I'll write a short paragraphs or two explaining my rationale, referencing the commits that came before

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

#182

Post by rurban » Fri, Mar 18, 2022, 7:47 AM UTC

depends on the review and PR policies. most are very strict, so I tune my branch to the expected commits.

with magit of course. GNU even expects proper Changelog entries per commit.

and I always keep on track with rebase, pull --rebase and rerere. everybody hates nonlinear merge trees

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

#183

Post by rurban » Fri, Mar 18, 2022, 7:53 AM UTC

musicmatze wrote: post #177

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?

I automized constant rebasing. it's a couple of cronjobs for the mirrors and projects I'm maintaining over several years, and the cost is marginal. I get about one failed rebase email per month.

a big project of mine is about 2500 commits ahead. rebasing this beast is partially automated, but still I get about 2000 upstream changes through once a month. you need scripts to rebase and to rollback for a wrong choice.

it scales trivially.

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

#184

Post by ffwacom » Fri, Mar 18, 2022, 8:35 AM UTC

How I was taught:

A branch for each feature.

Each commit should be a logical segment of work, such that it tells a story of how the feature came to be from the different aspects of the system that needed to be modified.

The branch will NOT be a history of how it was actually programmed.

If master or another dependent branch changes, rebase the feature branch onto the dependent commits to keep merge conflicts under control as the branch is being developed.

The branch will be rebased with commits squished and fixed as many times as needed (often 100's in a long running feature), with the end effect being such that the branch and commit history will look like divine providence.

Took some hazing and months to learn but absolutely worth it IMO, and I can't go back now :)

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

#185

Post by AndrewDucker » Fri, Mar 18, 2022, 9:00 AM UTC

Work on it, committing whenever I have something working, or it's time to go home for the day.

Merge it as is.

Because nobody is ever ever going to go through my commits "reading a story". What they care about is the final stage of my code. I could squash it all, but those extra commits don't hurt anyone, and the space they take up is neglible, so why not leave history as, well, the actual history?

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

#186

Post by npteljes » Fri, Mar 18, 2022, 9:36 AM UTC

We use feature branches. We commit frequently to those, but squash it in the end when merging to main. We rebase to the latest main to keep the feature branches up to date. This way history is organized (not that anyone ever looked at it), but also integration is frequent.

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

#187

Post by mbar84 » Fri, Mar 18, 2022, 10:21 AM UTC

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://…

Sublime Merge offers a nice GUI for the workflow you're describing with `git add -p`

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

#188

Post by rendall » Fri, Mar 18, 2022, 11:45 AM UTC

whycombagator wrote: post #111

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.

Sure, if there's some kind of egregious error or objectively bad suggestion, push back, but generally give the other devs the benefit of the doubt. I'm assuming you're working with professionals.

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

#189

Post by Kifot » Fri, Mar 18, 2022, 11:47 AM UTC

ffwacom wrote: post #184

How I was taught: A branch for each feature. Each commit should be a logical segment of work, such that it tells a story of how the feature came to be from the different aspects of the system that needed to be modified. The branch will NOT be a history of how it was actually programmed. If master or another dependent branch changes, rebase the feature branch onto the dependent commits to keep merge conflicts under co…

> The branch will NOT be a history of how it was actually programmed.

I'm not sure how to reconcile it with the idea of having a branch for each feature. In my head, developing a feature on a branch creates a history of how the feature was programmed. Could you elaborate on that?

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

#190

Post by OJFord » Fri, Mar 18, 2022, 11:47 AM UTC

cpcallen wrote: post #144

OJFord wrote: post #29

Earlier quoted context omitted.

Everyone absolutely should configure that. (Git config pull.rebase true.) Such an annoying mess it leaves otherwise. And CI is building 'merge branch master', on the master branch, great.

> And CI is building 'merge branch master', on the master branch, great. How does one set this up in GitHub actions?

By default it shows the commit message doesn't it? At least I'm not aware I've done anything for e.g. https://github.com/OJFord/terraform-provider-wireguard/actio...

The annoyance I'm describing is that when the commit message is 'merge branch master' (and especially if, as the label next to it shows, it is the master branch) this is crap and useless, and hiding the 'real' commits behind it that the committer had locally while behind the remote. If they had `git pull --rebase`d (or `git pull` with the config option set) the commit message would be that of the latest 'real' one.