Working with git can be a bit of a pain, so here’s how I go about my day-to-day interaction with it. This is neither complete nor a perfect solution, but it minimises the pain for me!
All your work is merged. You’re up to date with
dev. The sun is shining ☀. It’s a beautiful day.
You’re starting on a new feature so you create a new branch from
dev for the new changes.
# create & checkout a new branch git checkout -b YN/new-feature
You start work and at the end of the day you want to mark a point in time. You stick everything in a
WIP commit so you don’t lose it.
# add everything git add -A # commit staged changes with message "WIP" git commit -m "WIP"
You go home.
Next day you want to get back to where you were, so you reset your WIP commit
# reset to HEAD (i.e. your WIP commit) -1 (i.e. the commit before your WIP commit) git reset HEAD~1
You can check status to make sure everything is where you expect
# check your WIP commit content is now unstaged git status # check your WIP commit has been removed by reviewing the last 3 commit titles git log --online -3
You work for a bit, then reach the end of a independent block of work. You mark this momentous occasion with a commit with an imperative message and a meaningful description.
- The Title is meaningful outside the scope of your current work
- The Title is imperative
- The Description adds detail to the change, but does not describe what changed: the code does that. It describes why you made the change and why you made it in this way
- You leave a blank line between title & description
- You link it to a story with
Fixes #1234if appropriate
# stage specific files git add FirstFile.cs git add SecondFile.json # commit git commit -m "Add JSON logging configuration for the NewService >> >> The human-readable logging does not sit well with Kibana - every exception >> message results in many lines of junk >> >> Using the Serilog JSON formatter to get something usable. >> >> Fixes #1234"
You do some more work to finish off the story so you add another commit.
# stage specific files git add Dockerfile git add docker-compose.yml # commit! git commit -m "Update NewService docker configuration for JSON logging >> >> Under docker we want to enable JSON logging for NewService"
That looks like the story is about done so you push to the server and submit your PR
git push -u origin HEAD
You pause to briefly celebrate a job well done.
The next story happens to be related to this one, and relies on the changes you just made, so you can’t branch from
You create a new branch from
# on YN/feature-name... git checkout -b YN/feature-name-part-2
You start on part 2 and have already made commits to
YN/feature-name-part-2 when disaster strikes: someone spots a typo in your earlier PR!
You want to fix this but you don’t want a commit with the title “Fixes typo” living forever in dev. Time for a rebase
First, you make your change on the original branch (stashing any local changes) and commit it with whatever commit message pops into your head. It won’t be around for long
# back to the feature branch git checkout YN/feature-name # fix that typo git add FileWithTypo.cs # create a temporary commit git commit -m "Whatever"
Next, you start an interactive rebase against your target branch (probably
dev) to merge your “typo” commit into whichever commit is most appropriate
git rebase -i dev
Once your git history (checked with
git log --oneline -10) is looking glorious again you are ready to update the server.
You do this with a force push, but you only do this becase you’re sure noone else has branched from your branch.
# tread carefully... git push --force
This will overwrite the old commits on the server repository with the new rebased version. Your PR is once again ready for review.
Now you need to go fix your
YN/feature-name-part-2 branch with another rebase.
# back to the feature branch git checkout YN/feature-name-part-2 # rebase against the updated YN/feature-name git rebase YN/feature-name
Finally, once you’ve finished part 2, you’re ready to submit another PR. By now,
YN/feature-name has been merged to
dev so you rebase against
dev before submitting the PR
# on YN/feature-name-part-2 git rebase dev
You submit your PR, breathe a sigh of relief, and move on with your life.