And if you have PR comments/commits you do this everytime? Just squash
A Better Git Flow
21–30 of 115 posts
Re: A Better Git Flow
#22The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts. But you can very easily do this just by rebasing instead of resetting and re-commit…
Right, I don't think rebasing is that daunting if you take a few hours to practice. It's time well spent. Sometimes you can even create empty commits (--allow-empty) up-front (if you already know about all the things that have to be changed) and fill them via fixup/rebase --autosquash
After learning about fixup and squash commits, I started typing `git rebase -i --autosquash` so frequently that I made an alias for it. It has totally changed the way that I work. You get to have the best of both worlds; commit early, commit often but then also having nice and tidy PR's and histories.
Re: A Better Git Flow
#23This to me seems more like a logical separation than anything technical. I use GitHub and always squash commits before merging a PR. This keeps the commit log clean and also has the side effect that you have the PR number in the merge commit. Having said that I also suggest keeping PRs small. If you are going to reformat a code base, make that a separate commit. Updating a library, separate commit. Adding a library y…
Squashing commits is something lazy people do! :P
Re: A Better Git Flow
#24Earlier quoted context omitted.
Right, I don't think rebasing is that daunting if you take a few hours to practice. It's time well spent. Sometimes you can even create empty commits (--allow-empty) up-front (if you already know about all the things that have to be changed) and fill them via fixup/rebase --autosquash
After learning about fixup and squash commits, I started typing `git rebase -i --autosquash` so frequently that I made an alias for it. It has totally changed the way that I work. You get to have the best of both worlds; commit early, commit often but then also having nice and tidy PR's and histories.
My aliases:
alias.c commit
alias.cf commit --fixup
alias.cm commit --message
alias.co checkout
alias.f fetch -v -p
alias.par pull --rebase --autostash
alias.ri rebase --interactive --autosquash --autostash
alias.rim rebase --interactive --autosquash --autostash master
alias.s status
alias.l !git --no-pager log --oneline -n10
alias.pf push --force-with-lease
alias.bs !git --no-pager diff --stat master..HEAD
alias.p push
alias.alias !git --no-pager config --get-regexp alias
Re: A Better Git Flow
#25My two cents: I just always squash commits when merging to master/main. That way the main branch has clean commit messages and it's easy to revert later. I think cherry-picking commits after the fact can also be very time-consuming, especially if you do a lot of refactoring or "clean as you go" as I like to call it. However, I could see it being worth it for open-source.
> easy to revert later
Depends on what you want to revert? git revert accepts more than one commit!
Re: A Better Git Flow
#26Yes git rebase -i is better as others pointed out.
Example from the start ... revert.
Don't revert stuff, fix stuff forward (make new commits with new changes) you won't introduce bugs in silly way.
Re: A Better Git Flow
#27The use of `git reset` is a little silly and is playing with fire for no absolutely no benefit. If you want to follow the pattern described here, create a new branch and do `git checkout the_feature_branch -- $filename` and pull the changes from the branch you did the work in into the new branch, making commits as described in the article. You can even do `git diff --numstat $feature_branch $new_branch` to see what h…
> and is playing with fire for no absolutely no benefit
How so? The previous commits are still recoverable from the reflog.
Re: A Better Git Flow
#28What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.
Bingo! This strategy has worked well for my org (75+ engineers) for years. If an engineer makes non-related bug fixes in the same branch we require them to revert the change and make a new branch. We also have each GitHub repo configured so the "Squash and Merge" option is the ONLY option available when merging a PR.
I don't care one lick what someone's branch history looks like. If they want to commit every day, or every hour, or after every keystroke - I don't care. All I know is that once the PR is merged, it's all going to be squashed into a logical unit so the `main` commit history will look just fine.
Re: A Better Git Flow
#29The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts. But you can very easily do this just by rebasing instead of resetting and re-commit…
The one thing I wish were easier would be breaking a single commit into two commits.
Edit: to be clear, I know it's possible by using git reset... but I'd much rather have something like git add -i that interactively shifts changes from the commit itself and moves them into working directory-only changes.
Re: A Better Git Flow
#30The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts. But you can very easily do this just by rebasing instead of resetting and re-commit…
The one thing I wish were easier would be breaking a single commit into two commits. Edit: to be clear, I know it's possible by using git reset... but I'd much rather have something like git add -i that interactively shifts changes from the commit itself and moves them into working directory-only changes.
1. `git rebase -i` to the commit before the one you want to split
2. mark the commit you want to split as an `edit`
3. remove the file(s) you want to edit from the index so that it's part of your working tree
4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.