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

71–80 of 201 posts

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

#71

Post by throwawayboise »

All I use in git is clone, pull, commit, push. I do not use feature branches. The only branches I use are for releases that need to be maintained separately from master.

I absolutely do not care if there are "fix typo" or WIP commits in the history. The amount of effort it takes to get a "clean" commit history has negative payback in my experience.

It should be said I am a lone developer for the most part, sometimes working with one or two other people. So Git in fact is overkill for that scenario. Subversion would do just as well and in fact I prefer it or mercurial.

In a large project such as Git is meant for, my usage probably doesn't apply.

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

#72

Post by 8note »

I generally know what I want commits for before I start writing.

While writing I make my first commit once I've got one file changed, then ammend it as I go.

If I write a whole ton of code/don't plan well in advance, I can end up with a few changes on the go at the same time. I'll tend to reset all the commits at the end and interactively add lines to commits

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

#73

Post by mikewhy »

btschaegg wrote: post #60
matticusrex wrote: post #46

Earlier quoted context omitted.

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?

Have a look at `tig`. It's even included in Git for Windows now and does this reasonably well. Only the keybindings are a bit weird if you're not accustomed to Vim bindings: - Open tig - Change into the staging view with `s` - Select your file using the arrow or `j` and `k` keys - Press Return to show the diff - Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files) - Stage parts with `1`…

I used tig for a bit because it was the nicest way I could find to do line-level staging in a terminal. But was really impressed with gitui https://github.com/extrawurst/gitui so I've switched to that

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

#74

Post by meowface »

>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.

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

#76

Post by lambic »

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.

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

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

#77

Post by jedberg »

I keep my personal dev folder in Dropbox so I don't have to worry about lost work since it always syncs to the cloud. My work dev folder uses syncthing to a remote server for the same purpose.

I make my own branch and then do checkins when I get to good stopping points. Then I do git squash merges to staging or the group branch when I have nice small updates. Keeps the public history clean and also lets me revert back to the previous stopping point, while not being worried about lost work.

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

#78

Post by user3939382 »

I have everything aliased and use few commands:

gb feature/Foo // make a branch called foo from the current (usually develop) and switch to it

// make edits

gac I did a thing // add all files and commit with this message

mduc // Merge current remote develop into this branch

git push

mkpr // Create a draft PR from this branch on github and open my browser to it

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

#79

Post by deckard1 »

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. 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).

If you're constantly rebasing onto main, then all of your working commits sit on top of the latest code in main. Which means you do not have to deal with tricky merge conflicts, where your commits may weave in and out of the main branch at various points in time because you were doing "git merge" at random points. In addition, if you squash your commits before doing a rebase this will also make merge conflicts rather trivial, because you're only dealing with one set of merge conflicts on one commit.

That's the big picture, team workflow. For my personal workflow, I rely on "git add -p" and stashes. The only time I do a commit and push up code is: a) when I have a large change and want to make sure I don't lose it or b) others have already reviewed my PR and I want to keep the new changes separate to make their life easier when reviewing a 2nd time. I use "git reset --soft HEAD~" to squash instead of "git rebase -i" because I find it easier and quicker.

I must emphasize this point: learn "git add -p". It's extremely useful in the case where you have some changes like debugging code or random unrelated changes that you do not want to commit. It's a filtering mechanism.

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

#80

Post by jedberg »

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