My Git Workflow

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.

Let's start:

1. Cloning / Creating a Git repo

$ git clone [email protected]:vraa/blog.git
$ cd blog

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

$ git checkout -b vraa-master-feature origin/master

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

$ git pull --rebase

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 rebase option 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 rebase rewrites commit history, you will end up with a nightmarish merge conflicts.

4. Stashing my local changes

$ git stash
$ git pull
$ git stash pop

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

$ git rebase -i 8e35004e04f352b20eda0eb0a4d46574d8fba216
// re order and combine multiple commits into single one

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

$ git push origin

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.

undefined