There’s plenty of great reasons to use a version control system, such as git, for your local changes. In my last post, I wrote about how I use git along with other sync tools for writing code on my various endpoint devices. In this post, I’ll review some of the practices that I advise for keeping your local git repositories clean and happy!

Start by Pulling Changes

Something that I’ve developed muscle memory for is pulling in changes from any remote repositories I have linked to my local repositories. This is frequently a GitHub repository. In some situations, you’ll even see that the current branch will show up as an angry red color with a down arrow. Using a git status command reveals that there are commits on origin (the remote repository) that have yet to be pulled down.

One handy shortcut here is using the git pull --all command. In addition to fetching changes from origin for the current branch, it will also fetch changes for any other branches that have missing commits that can also be fast-forwarded (pulled in without conflict). I suggest pulling in changes each time you begin working on new changes to help avoid having to resolve conflicts later.

Branch All The Things

It’s a great idea to create a feature branch for any work in progress. I use feature branches to create a sandbox for new ideas. Below, I’m writing some updates to the Get-RubrikVM function on the Rubrik PowerShell module. In order to safeguard those changes from the rest of the repository, I created the getvm-firefly branch as a feature branch to create updates to two different files.  This allows me to tinker around with the code while still having the ability to switch to other ideas and other feature branches.

In order to continue working on the feature, I need to:

1. Checkout the feature branch with git checkout getvm-firefly. This will switch over to the git context to the getvm-firefly branch.
2. Restore changes that I have stashed. The stash is like a private safe for changes. I use the stash command for situations where I’m not quite ready to commit changes into the feature branch but also need to switch to another branch. The git stash pop command asks git to load my stashed changes so I can continue working.
3. And finally, the git add --all command will begin tracking my changes for the next commit.

If a new branch is required from this point, I commonly like to create and also checkout the new branch in one command: git checkout -b <branch_name> will do this nicely.

Commit Frequently

I prefer to make a number of commits throughout the day. For me, the main basis for “when should I commit” comes down to logical decision points. If I’m writing some code and then have to make an architectural decision, I’ll often go ahead and commit changes so that I can easily roll them back, if desired. Knowing that numerous local commits can be compressed by using the rebase and squash commands, it’s advantageous to commit frequently at the local level.

Be aware that rebasing commits that have already been pushed to a remote repository is not a great idea. If others are working off those commits, you may cause some nasty merge conflicts.