5 Git workflow best practices you've got to use [2021]

| 5 min. (923 words)

Have you been using the same Git commands for years, without a second thought on how your Git workflow can be improved?

Or are you a new developer who could use some handy Git tips and tricks?

This week, we’ll take a look at five Git tips you can seamlessly incorporate into your workflow to make it easier to get your code into prod.

1. Rebase Git workflow

When you’ve finished a feature on a local branch and it’s time to commit your changes to the master branch, you might prefer merging over rebasing.

I used to be in a team responsible for merging sprint features into the master branch. This was a nightmare. Always.

Another dev taught me an excellent Git workflow that combines rebasing and merging when it’s time to commit changes to the master branch, and it has honestly made such a difference to my workflow.

With the rebasing and merging combo outlined below, merge issues are kept to a minimum because your local history will match master before the final merge into master. No headaches! (Or just mini ones!)

Rebasing also means working in a linear approach where local changes are added at the end of the branch. It makes it so much easier to read the log and find out exactly what’s happening.

Here’s the rebasing workflow:

2. git add -p

When you’re working on a local feature branch, do you sometimes want to pick out code changes you want to commit, but leave other changes uncommitted? With the git add -p  command, that’s exactly what you can do.

Before I learned about this command, I inefficiently discarded changes I didn’t want to commit using git checkout — src/etc  and then committed all changes git commit -A . What a waste of time.

Now, I use this command when I have certain variables only applicable to my local environment that I don’t want to commit or when I have a piece of code I’m still working on but want to test a completed piece of functionality in another environment.

This command is the single most useful command I’ve learned in the last year (thanks, Callum!).

3. Keeping your branches tidy

Rename branch

Coming up with pithy branch names is definitely up there with naming variables. Sometimes, I’m working on a feature branch and come back the next day trying to understand why I picked such a generic branch name that probably already exists in the remote repository.

The command to rename branches locally is something I use at least once a month and is super quick and useful.

Rename a branch while currently not in the branch to be renamed:

git branch -m oldName newName

Rename the current branch:

git branch -m newName


Delete old local branches

Check all your old local branches right now: git branch 

If you’re like me, you might have over 10 stale branches that have either been merged into master already or are just sitting around taking up space.

Time to delete this baggage. But only if you’re absolutely sure you don’t need them anymore.

git branch -d branchName

Git aliases

Another way to improve your workflow is to use Git aliases. These allow you to remove any ambiguity from your commands, making them read better, and making it so you don’t have to worry about remembering the exact structure of the underlying command.

4. Git reset-hard

Do you sometimes just mess up on a local branch and want to abort all changes? Me too.

The git reset –hard  command wipes all your staged and uncommitted changes so you can start again.

Be careful! As with most Git commands, you have to know exactly what you’re doing. This is a great resource to understand the inner workings of this command.

5. Escape greater than symbols:

If you’re using PowerShell for Git (such as posh-git) you might encounter the ever annoying double greater than symbols >> that are impossible to escape unless you know the command.

The answer: C 

There are always easy ways we can improve our Git workflow. A few commands can make all the difference between saving time and getting frustrated over merge conflicts that could have been avoided.

6. Ensure your team is all on the same page

How you use Git as a team can not be understated and can be the make or break of your application and your sanity. Coming to an agreement on best practices, workflows, and naming conventions can save a lot of time, effort, and headaches if done upfront.

For example, there are many different workflows and naming conventions available for Git, and I have no doubt that various members of your team will have different opinions on which is going to be best suited. Regardless of which your team lands on, it is crucial that the rules of the workflow are clearly explained, and everyone understands what they should and should not do. People don’t know what they don’t know - so even if you think something might be obvious, document your best practices and distribute it to your team anyway.

You may also enjoy

A GitHub tutorial GitHub help docs How to integrate Raygun Crash Reporting with GitHub