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

31–40 of 201 posts

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

#31

Post by bern4444 »

I do the same as you - commit early and often, push nearly on every or every few commits, but I try and write my commit messages nicely even (and especially) if the code behind them is not so clean.

I care less about the code quality during development, so long as the commits make sense and the end PR is clean. Commits that may have placeholder names, disorganized code could include:

"fix: failing test case" "feat: support new user flow" "cleanup: variable names and helper functions" "cleanup: organize files" etc

If the commit messages are clear as to why the change was committed, reviewing is a lot easier even with less than ideal code along the way. So long as the end state is cleaned up.

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

#33

Post by crnkofe »

The n1 rule I follow (and push everyone to follow) is: "Don't write shitty commit messages." It helps in general with everything related to Git.

Otherwise I decide ahead of time and focus on one area at a time that I know is a small chunk of functionality (like adding boilerplate for a small script, unit testing a piece of functionality, implementing an endpoint) and as long as I'm working on it I just use git add -A ; git commit --amend --no-edit . Once I move on to new self-contained batch of functionality I make a new commit and repeat the amending. It requires a bit of discipline to keep commits small enough but I like it since it's an easy process to follow.

Before I make a review request I usually do an interactive rebase and reword commit messages, sometimes reorder them and squash small stuff if it makes sense. After a review is in process I generally no longer rebase (to keep review transparent) and commit each fix separately.

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

#34

Post by CogitoCogito »

I usually squash my branches to single commits in the end and write a nice message then. There are times when I don’t do this. For example, yesterday I was moving existing code to a separate project and I first committed the original version and then made necessary changes in my next commit. This made it clear where things differed from the original.

Overall I think commits that land in main should be worthy of landing in main. Random crap you tried isn’t important. Larger self-contained changes are.

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

#35

Post by _se »

I think part of it depends on the tooling that you're using and what your review system supports. Assuming that these are all supported, I would generally:

1. Push very often, essentially every time I'm going to context switch or take a break

2. Iterate often, get things working, then clean them up, pushing at each step along the way

3. Interactive rebase to squash into meaningful stacked commits for review

4. Mark the change as ready for review by my team

I have found stacked commits to be the best way to both perform and author reviews by a wide margin. It's so much easier to review 4 200 line semantic changes than a single 800 line change. You'll get better feedback from others, and thinking about development in this way can also lead to better results on its own.

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

#36

Post by secondcoming »

twofornone wrote: post #22

>I also push often because I'm forever aware disks can fail. In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.

I have. You're not coding hard enough!

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

#37

Post by floodle »

I don't use commits as "atoms" of the work. Instead, I work at a PR level. I make PRs small and often, and try to make each one a small, self-contained piece of work, usually not more than a day or two.

Practically this means that I commit and push whenever I feel like it, but then always squash the PR. At that point I create a clean and informative commit message.

However, I leave a lot of context and information in GitHub rather than putting it in large commit messages. I rely heavily on GitHub's automatic linking of issues and pull requests for this.

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

#38

Post by El_RIDO »

twofornone wrote: post #22

>I also push often because I'm forever aware disks can fail. In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.

This is a good example of how scale can bias your view! :-D

Personally I share the same experience: In the 30 years I've been using personal computers at home and work, only 2 disks failed on me, one was an error on my part during an OS upgrade and the second was an external disk that physically fell off my bed while I had it plugged into my notebook. So both of these weren't really those random failures.

On the other hand, while working in an IT infra team of a 60 developer company with 4 racks full of servers for 3 years, we'd get to see about one failed SSD per 2 months and 2-3 failed disks or SSDs per year in servers.

During the 1 year I worked for the IT infra team at a smaller hospital of a medium sized city with a large VDI environment and two HP EVAs in a two datacenter configuration each, we'd get 3-4 disk failures per week. Those had over 140 disk per storage each and were approaching the end of their support life, being around 5 years old, so the failure ratio started to get higher.

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

#39

Post by mkesper »

OJFord wrote: post #29
notapenny wrote: post #17

Earlier quoted context omitted.

It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.

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.

Combine with git config --global rebase.autostash for your own protection.
Post reply on HN