How to not f- up your local files with Git part 1

Branches and workflow

6 min readMay 28, 2017

Git is an essential tool for every developer, it keeps your code history in check and helps understanding what was done yesterday without freaking out.

Working with a team requires a bit more than “git add” and “git commit” so let’s start exploring the beautiful world of Git.

Getting the basics is not that hard, and once you get into it, it becomes even easier.

Scope of this article

When working with a team, using Git should not take half your coding time so let’s get down some basic rules of Git and Github etiquette so you can spend your time coding instead of cloning the repo yet another time.

Part 1 will focus on how you should manage your workflow with Git to avoid the most common problems.

Tools

You don’t require fancy tools or commands to use Git effectively, for this article and the ones to follow I’m just going to use Git itself and my code editor of choice (with Git integration).

Git client this is all the Git we need, just the default client.

Visual Studio Code or any other editor with Git integration, it will make your life so much easier.

Basics

First of all let’s start with the basics of Github etiquette (we can adapt and build on these, they are not set in stone but a good starting point).

master branch you will never touch it, this is production and should be updated rarely when everything is tested and works.

development branch this is our development branch, you do not code here, you send pull requests here to be checked by other members of your team and merged. If you pair a lot and the dev team is ok with it you can skip the checked part and merge the pull request yourself but still, don’t push you code here.

So where should I code if I can’t do anything! Hold your guns cowboy, let’s get into that next.

What you should do when you want to work on something

$ git clone git@github.com:Kornil/simple-react-app.git

This is the beginning, you do it once and never again.

From here on we will work on branches. By default you will be on the master branch. GET OUT OF THERE.

$ git checkout development

This is better isn’t it? You are now in the development branch, this is the branch you should always refer to, she’s the love of your life and you will treat her with the respect she deserves.

How?

$ git checkout -b myNewBranch

This will create a new local branch called myNewBranch and switch to it, it is based on the development branch in this case since we were there.

Running “git branch” you will see that you are actually inside this new branch. This is only on your machine, say “Hi!” to your new working branch.

Naming branches

Naming branches is an important aspect of coding with other devs and even for your future self, let’s look at how we can approach this.

myNewBranch doesn’t explain anything and it doesn’t solve our problems, we need a naming convention:

"bug/fixed-all-caps""feature/giant-duck-modal""refactor/add-prop-types""style/everything-is-black"

Type/short-description

Types

We’ll define 4 basic types of branches: bug, feature, refactor and style: respectively for bugfixes, new features, code refactoring and design/css stuff, after the type comes the name, it should specify on top of the branch type.

$ git checkout -b style/pink-buttons

This tells you and your friends everything you are going to code in this new branch.

F-! I forgot to create a new branch before starting to mess around and I’m still in development!

Don’t worry Leo, we can solve this. There are 2 ways we can use to recover from this disaster:

First, if you have not committed anything:

$ git stash

Saves all your changes (not commited nor staged) somewhere and removes them from your branch.

Now your development branch is clean so just run

$ git checkout -b feature/rubber-duck-cta
$ git stash pop

You will create a new local branch and paste here all your changes. Remember the stash is like copy pasting, tremendously useful yet at the same time definitive if you “git stash” once more you can say goodbye to your first stash. RIP.

Second way, If you have already committed your changes:

$ git push origin development:fix/your-smart-fix

Save your code into the newly materialized fix/your-smart-fix branch of your Github project (assuming you were working on the development branch).

Now delete the development branch and get it back again as pure as it should be.

$ git checkout master
$ git branch -D development
$ git fetch
$ git checkout development // optional, just to see that it's clean
$ git checkout fix/your-smart-fix

Let’s go over this quickly:

First, switch to master branch (your safe branch), after that we delete the development branch, fetch every branch from Github (don’t worry you will not see them with “git branch”) and switch to development again. Now you can run “git status” to check that development is clean and from that you can go back to your working branch, easy enough right?

Using Visual Studio to look smart~ish

Visual Studio is more than an editor, it’s like a banana for a monkey, you should not live without it. Let’s see what it can do for us.

Are you bored of using “git add .”? Do you want to commit only 3 files cause all the rest is a mess and you know you’ll get punched if you try to poison the Github repository with that filth? Here comes VSCode!

I went into a coding rage and modified too many files without committing even once, but I don’t want my fellow devs to suffer with me, I just want to split my code into multiple commits so it will be easier to read.

But first of all, what are those letters on the right?

(M) ← the file was modified after the last commit.

(D) ← the file was deleted after the last commit.

(U) ← this is a brand new file.

Does this help? A bit, but still, let’s get to work! Hovering on the file I want to add shows 2 more icons, let’s see what they do.

First one is an arrow, it reverts all your changes to the last commit(my favourite button!).

Second one is a plus symbol, clicking it is like running “git add .gitignore” it adds our files for the next commit, we can use this handy function to add only the files we want for this commit and keep the rest there.

After clicking on the plus icon we see this.

Now there are 2 distinct rows, the usual one called changes and a new one for the file we added called staged changes. Staged means file that will be committed with the next “git commit” but as you can see we have a new icon, a minus sign! This can be really handy too as it unstage our changes putting the file back to changes where we can decide if we’re just playing stage/unstage or if we want to restore the previous commit.

Conclusion or TLDR

Make new branches, refer to development as the base of your branches, commit frequently, use clear messages, make pull requests against development, ask you team to check your code and then merge to development.

You can find part 2 of this series here and part 3 here.