git reset - a close friend

Gerald Spreer
geraldspreer
Published in
1 min readNov 25, 2017

In a typical git workflow, we all use git pull to update our local branches. But I have found that there are some scenarios where that is just not enough.

Especially with workflows that involve development or staging branches. Because staging or development branches tend to be reverted, rebased and reset all the time, any local copy of such a staging branch will be out of date very quickly.

Let's assume, you have developed a certain feature and would want to merge it into the staging branch. What you need at this point is a fresh snapshot of the origin/staging as it resides on the remote.

A simple git pull would integrate all changes from the remote into your local branch.

However, this is not really what you want. Actually, you do not care about what state your local staging branch is in, or which features branches have already been merged into it. You just want the latest version of the staging branch from origin/staging. That’s when git reset --hard origin/staging comes in handy.

Using git reset you will make sure that your local copy is exactly in sync with the remote.

After that you can merge your feature, run your specs and when all is green use git push to update the staging branch on the remote.

Using git reset in cases like this will save you a lot of trouble. That is why it has become one of my favorite git features.

More about git reset in the git documentation.

--

--

geraldspreer
geraldspreer

Published in geraldspreer

Articles about software development, code quality, test driven development and related matters.

Gerald Spreer
Gerald Spreer

Written by Gerald Spreer

I have been developing software for more than thirty years and I have worked with a variety of technologies. Today, I mostly use Ruby on Rails and Angular.

No responses yet