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

81–90 of 201 posts

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

#81

Post by globular-toast »

meowface wrote: post #74

>I also push often because I'm forever aware disks can fail. I'm not leaving a day's worth of work on my local drive and hoping it's there the next morning. I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing. I don't think git should be considered a substitute for a proper continuous backup system.

Agreed but pushing at least at the end of the day should be required just in case somebody needs to pick up your work for some reason.

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

#83

Post by bjourne »

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.

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

#84

Post by globular-toast »

izietto wrote: post #59

My flow is: 1.a. a lot of dirty commits/wip commits 1.b. a few of clean commits, when I spot changes that I know they are already a commit by itself Before opening the PR: 2. `git log -p`: I inspect the commits I've done and I decide what should go together, what should be edited and what can stay as it is 3. `git rebase -i`: I apply the changes I've decided during 2 4. repeat 2 and 3 until I'm happy with the results…

One thing that can make rebasing much easier is making use of --fixup and --squash. Often you know at the time that a commit is either fixing a previous commit or that you would want to squash it with a previous commit. This can save a lot of time later as you can simply issue a --autosquash to rebase. If you do it right it means others can rebase your branch too.

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

#85

Post by OJFord »

lambic wrote: post #76
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.

Are there any downsides to doing this? Why isn't it on by default?

I suppose just the usual 'rebase vs. merge' - i.e. if there are conflicts to resolve they will be dealt with commit-by-commit in the usual way when rebasing, whereas without the option set they will be dealt with all at once 'merge-style'. I happen to think that's a feature, but I know some don't like it.

I think there's less argument in favour of merge than usual with pulls though - since it's much less like a semantic merge to begin with for git-merging to preserve a history of.

I'm certainly not aware of any objective downside/gotcha/'oh but it doesn't work when...', no.

The docs only add that you might further want to set it to `interactive` or `merges` rather than `true`, for the effect of rebasing with those options: https://git-scm.com/docs/git-config#Documentation/git-config...

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

#86

Post by meowface »

jedberg wrote: post #80
meowface wrote: post #74

>I also push often because I'm forever aware disks can fail. I'm not leaving a day's worth of work on my local drive and hoping it's there the next morning. I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing. I don't think git should be considered a substitute for a proper continuous backup system.

Same. I used to make a commit every time I got up so as not to lose work, but that just littered the history. Then I switched to keeping it in Dropbox or using Syncthing for work stuff, so now I only have to commit when I get to a stopping point or to share with others.

Yep. Dropbox is also a great safety net for when I mess something up in between commits. I've had a few times where I've deleted or changed some code that I couldn't restore just via undos. Normally I'd pretty much be screwed, but Dropbox retains a diff every time a file is saved, so it's basically impossible for me to lose anything.

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

#87

Post by bentcorner »

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?

sublime merge handles this really nicely. You can do this in VS code too but the UI is a little more fiddly (right-click->"Stage Selected Range").

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

#88

Post by globular-toast »

Rebase is the key.

There are two types of commit: checkpoints and versions.

Checkpoints are just you randomly deciding to "save" your progress. They don't necessarily correspond to completely working versions. The commit messages can be completely inappropriate for sharing but only make sense to you.

Versions are fully working copies of the program that could be checked out, run, released etc. These are what you present to your team and what gets merged in the end.

Sometimes you can write a new version straight away but other times you'll generate checkpoints first. Then you use rebase to get to versions. Use rebase as a way to make it look you are a superhuman writing perfect commits first time.

Getting good at rebasing takes some practice and pretty good understanding of git's data model. Learn this. And learn how to use --fixup, --squash and --autosquash to make your life easier.

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

#89

Post by wodenokoto »

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.

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

#90

Post by smcameron »

I use stgit[1] which makes it easy to polish patches (commits), re-order patches, format and email patches, etc. It also makes it very easy to keep a lot of balls in the air at once, working on lots of commits all at the same time while keeping them reasonably separated from one another. I've had maybe 50 to 100 patches going at once from time to time (but usually more like 5 to 10). Then there are guys like Andrew Morton who's known to juggle 1000s of patches at a time using ancient home grown scripts that are the primordial ancestor of quilt[2] and stgit.

[1] https://stacked-git.github.io/ [2] https://en.wikipedia.org/wiki/Quilt_(software)

Edit: forgot to mention, once I'm happy with a given patch/commit, or series of patches/commits, I then cherry-pick or merge them from my patches branch over to the "real" branch, and then push them.

Post reply on HN