How I git

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 #1234 if 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 dev.

You create a new branch from YN/feature-name

# 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.