A Git Branching & Stashing guide

In this post we’ll cover how use Git “branching” and stashing.

Why use Branching?

When you’re working on a team branching is especially important. If you’re working on a project and someone else is working on the same project and you want to push your changes up to the remote repository, you’ve now introduced problems and conflicts when the other person wants to push up their changes.

Or say you need to take a break from this feature and work on something else because a client has bigger priorities. Or this feature has broken a couple things, and you’re having a hard time getting things to work just right.

Doing your active development “off to the side” is a good practice. It’s also a good practice to have a working version of your project at all times. That is the master branch. The safe space. The ready-to-deploy at all times code base.

When you’re coding and breaking things you’re doing it off to the side in a separate branch. Then when everything is working you “merge” those changes into the master.

How to git branch

First get setup with a regular git repository and create a few files for your master branch. I assume you know how to do that. If not check out our other git tutorials.

With my setup I have a couple commits on master and one file called master.txt

And like a good programmer, I will make all of my development changes in a different branch! To create a new branch and check it out, go to your terminal and initialize your repository and type in:

$ git checkout -b branch_name

Now make some changes… Add files. add some new text to those files, whatever you want. Then commit those changes to the branch you’re on. I just added a new file called dev_branch.txt and committed it to the dev branch. Make sure you commit your changes before switching back to master. We’ll cover that later.

and the steps I took in the terminal..

$ git add .
$ git commit -m "first dev branch commit"

Okay. You can see that we’re on the dev branch and changes have been committed. We added a file. So.. now if we go back to the master branch you’ll see that none of the changes we made in the dev branch are there. The file is gone. That’s because all your changes are still back over in the dev branch.

Let’s go back to master and see.

$ git checkout master
our dev_branch.txt file is still over in dev

Also in my text editor…

Cool. So.. if you want to delete that branch and just say bye bye to all your changes in dev branch you can delete that branch with this command:

$ git branch -d branch_name

But I want to keep the branch. In fact, I want to “merge” that code from the dev branch into my master branch. Let’s do that now. When you’re in the master branch and haven’t made any changes to master yet… Go ahead and merge with:

$ git merge dev

That’s it! Now you can switch back to the dev branch and start making more feature changes. Look in your text editor and you should see the changes in your dev branch are now live on your master! If you wanted to go back to the dev branch you’d just run $ git checkout branch-you-want

See it’s pretty simple right? If you wanted to push all your branches up to a remote repository like Github, then you’d use the following command: $ git push REMOTE –all where REMOTE is the name of the remote. I almost always use “origin” so the command for me would look like this.

$ git push origin --all

Git Stash

Git stashing is when you need to switch branches or do something else, but you’re not ready to make a commit, so you “stash” all your code away for later use. Let’s give it a try.

Create a commit for a reference point and have a clean working tree, where everything is “fresh”. Now make a couple changes. Add a file. change some existing files. When you run git status you should see the typical message that “there are changes to be committed” and “changes not staged for commit”.

If you wanted to “stash” these changes away, all you have to do is run $ git stash and your changes will be stored away. Note: $ git stash will NOT store un-tracked files. You must add them with $ git add file_name first. Let’s give it a try.

$ git stash
$ git status #just to see how the repo looks now.

Now if we check our repository the changes we made are gone and “stashed” away for later.

Now let’s go ahead and create a different file and commit it. This will represent us making changes in another section of the code. (Like if a client was to be like hey I need you to this over here right now!) Note: If you edit a file that the stash also has edited you will have a conflict, which we haven’t covered conflicts yet. So we’ll stick with adding new files for now.

Create a file. Commit it to the repository… then check to see your clean status:

Cool so we added a file while we had other stuff stashed away. Neat! Now let’s go grab the project we were working on earlier. To “unstash” the stuff you were working on, run $ git stash pop

Now if I look in my text editor I can see all the files and edits that were stashed away but are back in action.

You can have multiple stashes at a time. To keep them organized, you may want to save a stash with a message using the command like so:

$ git stash save "message to save stash with"

So let’s say I have a couple stashes stored away, and I want to get back to one of them. You can do that by first listing out the available stashes:

$ git stash list

Then choose the stash you’d like to get back to, and run the command with that stash like this. In my example, I’ll grab the “testing stash messages” stash.

$ git stash pop stash@{2}

By default $ git stash will not store untracked files. To stash untracked files use the -u flag

$ git stash -u #this stashes away untracked files too.

That’s pretty much all you need to know to stash away changes and use branches in git. To learn about all the use cases of Stash be sure to check out the documentation. Next up we’ll cover git conflicts. Be sure to check out our other Git tutorials.

Leave a Comment

Your email address will not be published. Required fields are marked *

want more details?

Fill in your details and we'll be in touch

%d bloggers like this: