I'd like to offer a deeper tip here. It is good practice to keep commits to functional units of work. A story might, and should, contain multiple commits.
Then your final commit of the story can contain a git message footer that links back to the story number.
Then you can also separate units of functional code apart from refractors and doc chores.
This will make code review and reviewing the git history a lot cleaner!
Great post! Commit messages are important on large projects with multiple team members.
Thank you! And that is a great point - a lot of times I commit every time I have finished a solid (hopefully working) portion of the card. Basically if I'm going to step away for a break and would regret losing what I built, I commit. If what I commit isn't working, I make sure to specify what doesn't work and why.
I would urge against commiting incomplete code. It really is a matter of opinion and process but for my team of 12 working on a large project keeping our git history clean is really helpful.
Some more tips to consider:
If you need to port code to another machine to continue working you can create a patch file:
git diff > patchfile git apply patchfile
Or, if you do commit a temporary commit you could also squash the commits together using interactive rebase
I'd like to offer a deeper tip here. It is good practice to keep commits to functional units of work. A story might, and should, contain multiple commits.
Then your final commit of the story can contain a git message footer that links back to the story number.
Then you can also separate units of functional code apart from refractors and doc chores.
This will make code review and reviewing the git history a lot cleaner!
Great post! Commit messages are important on large projects with multiple team members.
Thank you! And that is a great point - a lot of times I commit every time I have finished a solid (hopefully working) portion of the card. Basically if I'm going to step away for a break and would regret losing what I built, I commit. If what I commit isn't working, I make sure to specify what doesn't work and why.
I would urge against commiting incomplete code. It really is a matter of opinion and process but for my team of 12 working on a large project keeping our git history clean is really helpful.
Some more tips to consider:
If you need to port code to another machine to continue working you can create a patch file:
git diff > patchfilegit apply patchfileOr, if you do commit a temporary commit you could also squash the commits together using interactive rebase
git rebase -i HEAD~2First, thanks for sharing @rachelsoderberg ;)
Just came down here to write the same, I consider commits as the good old video game checkpoints.
Every time you hit a "safe place" where you would like to go back in case of something goes wrong, add a commit with a very descriptive message.
Your "future myself" (and code reviewers) will thank you a lot.
Further reading: pauline-vos.nl/atomic-commits/
Love the analogy, I think of it the same way 😀