Warning!
Some of these tips relate to rebasing. Remember you should never rebase master
or any other branches used by other people (e.g. develop
). If you think you need to rebase master
, you are probably wrong and there are other ways you can achieve what you want. If you rebase master
or another branch used by other people and mess up, your tech-lead will smack you with the git handbook.
If you make a commit with the commit-message squash! ...
or fixup! ...
, where ...
is the beginning of a previous commit message, you can use the --autosquash
option when doing an interactive rebase to automatically mark those commits for squashing. You can even auto-generate these commit messages if you use --squash
or --fixup
when committing!
Example:
$ git commit -m"Add something cool"
(Notice and fix some typo)
$ git commit --fixup=HEAD
$ git rebase -i --autosquash master
When working with a feature branch where you end up squashing many commits together before you create a pull-request/merge, your final commit will end up with the time-stamp of the first commit. This can be a bit misleading if you've been working on the feature for some time. You can override the date for the commit using git --amend --date=<date>
, but it's usually easier to just use --reset-author
which resets both author and date.
$ git commit --amend --reset-author