Make as many commits as needed to get whatever it is I'm working on "working". Then by default all the commits get merged during Merge Request and we get one commit to master.
Ask HN: What is your Git commit/push flow?
161–170 of 201 posts
Re: Ask HN: What is your Git commit/push flow?
#162Here 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.
It depends on the project. An open source library should probably have a sane history, a closed-source application, in a lot of cases it doesn't matter so much and often useful to see the whole workflow.
Why would it matter whether the repo was for an open source library or a closed-source application? That seems like an arbitrary distinction.
Re: Ask HN: What is your Git commit/push flow?
#163git pull default branch. Create local branch. Make change. Commit. Test. Remove quotes. Commit. Test. Add quotes back. Commit. Test. Google quotes. Remove quotes. Commit. Test passes. Rebase to default branch and squash. Push branch and MR. Ignore peer review policy and approve MR. Repeat!
Re: Ask HN: What is your Git commit/push flow?
#164Here'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?
I use Sourcetree [0] for this (on Mac but Win version available)
I've tried most Git clients on Mac over the years and kept gravitating back to Sourcetree.
I only tend to use it for this particular workflow (picking out very granular changes on a line-by-line basis). Otherwise, 90% of my git stuff is via IDE integrations or command line.
Re: Ask HN: What is your Git commit/push flow?
#165Earlier quoted context omitted.
It depends on the project. An open source library should probably have a sane history, a closed-source application, in a lot of cases it doesn't matter so much and often useful to see the whole workflow.
Why would it matter whether the repo was for an open source library or a closed-source application? That seems like an arbitrary distinction.
To me, it doesn’t seem arbitrary at all. Depending on the team size, a closed-source application likely has a small number of other developers that have a vested interest (or access, for that matter). Whereas an open-source project could potentially have orders of magnitude higher number of readers. A much larger audience would warrant higher priority over a readable/clean commit history.
Re: Ask HN: What is your Git commit/push flow?
#166Here 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 reorganizing them to make an alternate history that is prettier somehow.
sure, every once and a while it because useful/necessary to bisect, and a 'clean' history might help with that.
but seriously - why do we fetishize this? this is a medium where the amount of writing vastly outweighs the amount of reading.
when people are looking for a bug do they seriously find value in seeing how the code evolved? or do they just figure out why it doesn't work? is there an implicit assumption that the code all worked at some point and the task is to find out when/how it was broken?
just really confused
Re: Ask HN: What is your Git commit/push flow?
#167It works, I stage (git add), I refactor, it breaks, I checkout (preserves staged work), refactor again, commit push.
Also a fan of numerous small commits - makes good documentation and elimates wasted time untangling hours of thought.
And when I'm reviewing the last thing I want is for someone to waste time doing me the favor of burying their journey into some "perfect" mega-commit
Re: Ask HN: What is your Git commit/push flow?
#168It's really simple - commit early, commit often, push to your own branches/forks/repos where nobody looks but you. When you're done with your changes, squash them into something actually presentable and logically split into self-contained commits (interactive rebase is a wonderful tool), and then push out as a proper merge request.
Re: Ask HN: What is your Git commit/push flow?
#169The 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.
Re: Ask HN: What is your Git commit/push flow?
#170I tend to keep my PRs small enough to where several can be submitted within a day. This being said, I tend to keep my changes un-staged. When I'm ready to commit: 1. `git diff` to get an overall picture of what changes were made. Which parts of this diff can be packaged into an isolated commit? 2. `git add -p` This is where I selectively stage bits. 3. `git diff --cached` to verify that the staged items are all in pl…
`[commit] verbose = true` in .gitconfig makes `git diff --cached` step unnecessary, as you then get the diff displayed in commit message editor (I'm baffled why this isn't the default)