About 7 years ago I wrote about my Git Workflow. I just happened to read that article now and realised “Hey, that’s not how I use Git anymore!?”. Of course, when I wrote that post, I was just getting started with Git. But now, the post is so outdated that only the “90s kids remember it anymore”! 🤣
Anyway, Long story short: I decided write again about my Git workflow.
1. Cloning / Creating a Git repo
The first step is to get a local Git repo going. If I am starting a new project myself, I just needed to do
git init on my project directory. But at work, it is usually cloning my team’s existing repo.
2. Making changes and branching
Before I start working on my local repo, I always create a separate branch for my work. Branches are cheap in Git. So, I create as many branches as I need.
I follow this naming convention:
[my-short-name]-[parent-branch-name]-[bug/feature-id]. This convention helps me in quickly identifying / distinguishing my branch or my pull request from the sea of pull requests.
3. Pulling in changes
Often, even before my changes are committed / pushed, the remote repository is always getting updated with other changes. So, it is vital to bring in those changes as soon as possible, to avoid creating merge conflicts later.
Note: if my local changes are not yet pushed, then I tend to use
rebaseoption instead of a merge. This helps me to keep my branch history clean. But, use it with caution if you have pushed your branch to a remote repo, as
rebaserewrites commit history, you will end up with a nightmarish merge conflicts.
4. Stashing my local changes
Sometimes, when I try to pull remote changes and it overwrite my local changes, git won’t let me to pull. If I am in middle of the work and not yet ready to commit the changes, I stash my local changes, so that I can safely pull in the remote changes.
After applying the stashed files, if there are any merge conflicts, then I will have to deal with it.
5. Reordering and squashing my commits
During development, I usually commit as many times as possible. This helps me to go back in history if something breaks. But this also introduces lots of mid work / partial commits. I usually clean my working history by squashing multiple commits into a single commit.
Be aware that this rewrites history. So, never do this if you have already pushed your changes to remote and other people have got your changes.
6. Pushing my changes
And finally it’s time to deliver my changes and break the build.. wait.. no… just deliver the changes. Once my changes are delivered and merged, I usually remove the branch locally and remotely. This helps to keep the branch count at check.