A Simple Stupid Guide to GIT

An easy workflow to pull, merge, and update with the best of them

What is GIT?

GIT is a source code versioning management system (SCM). Its used by developers to share and organize code with one another.

While working in a team, big or small, you will find you need to dance around other developer’s work or current feature items within your applications.

GIT allows us to create working environments and track the changes we introduce into a project.

Centralized vs Decentralized

GIT can be overwhelming to new users, especially to those coming from a centralized version control system like SVN.

In centralized systems its pretty simple. Take a file down, add changes, push it back up.

Decentralized systems can be a bit confusing because there is this concept that we all have local copies, or versions, on our computers. We have to sync changes between the local version and the remote version that is in GitHub or Bitbucket.

While nobody is forcing you to use GIT, it is the most widely used control system in term of open source development and I encourage you to master it.

Like anything in life, it takes practice. Follow this simple guide and you’ll be branching, merging, and generating pull request with the best of them!

Branches

Branches give us the ability to make new working copies of our application. They allow us to make a test version for all the changes we want to introduce into our project.

This is great because you get an isolated environment from everyone else on the team. Its your playground to do as you wish.

To create a new branch use the checkout command with the -b flag

git checkout -b {Your New Branch Name}

Example

git checkout -b dev

The -b indicates we are creating a NEW branch. This creates a branch called “dev” and throws us into it. Your project will look exactly the same as it did in the master branch.

If at anytime you are unsure which branch you are on you can issue the following command

git status

Adding Changes

Once we introduce any changes GIT will be watching and tracking these. Issue a git status after making a change to the file and you will get some feedback indicating the differences.

We need to tell GIT that we want to add these changes and make them part of the project.

Add to staging

Our first step is to add the working changes to “staging”. Think of staging as a que you are loading files into.

Once we que up all of our changes we will save, or “commit” those changes locally.

git add -A

Commit staged changes to your LOCAL REPOSITORY

When we “commit” files, we are essentially saving them to our branch. Each time we commit changes we are asked to specify a message indicating what those changes would be.

This helps ourselves as well as other team members see what we did. The -m flag allows us to specify a short message. If we omitted this, then we would get thrown into an editor like VI to specify a longer message. This is useful when the changes are complex and we need to reference an issue number in something like GIT ,Bitbucket, or Jirah.

git commit -m "{Your Message Here}"

Syncing With Remote

Changes are added and committed locally. Now its time to beam it up scotty!

The following command will send, or “push” our changes into our remote branch and create the new dev branch.

git push origin {Your Branch Name Here}

Example

git push origin dev

Merging

Now we want to bring our changes from dev into master. There are couple ways to do this.

Pull Request

A pull request is created within the remote site like GitHub or Bitbucket 99% of the time. (GIT does have another way … but we won’t go down that road right now).

A pull request simply indicates to project owners that we want to bring changes in our branch into the project. Kind of like turning in your homework.

It offers review sessions between developers and a chance for some collaboration and improvements.

Once we create one we can hit the big ole “MERGE” button and bring those changes in.

This is usually a bad idea. We want to make sure all the code runs and we’ve tested it before blinding merging changes in. I typically always merge locally to test then push those changes.

Pull Request are still made, I just avoid hitting the “MERGE” button.

Manual Merge

There are a couple ways to merge changes but lets walk crawl before we walk. Again merging is referring to the processes of combing our new changes with the stable or production code in the master branch.

1. Use the git pull command to ensure your local branches (dev + master) are up to date. We want to make sure nobody came along and added new features or fixes to master while we were working on ours.

git pull

2. Move into the branch where we want to pull changes INTO. In this example we are moving changes from dev → master

git checkout master

Notice we didn’t need to specify the -b . This is because we are not creating a new branch, simply moving into one that already exists.

3. Issue the merge command to bring our changes in. We will specify the branch where the new changes are.

git merge dev

4. This is the make or break moment. Hopefully everything went smoothly and your looking at a clean project. Sometimes we can get conflicts between files that cause us to do some clean up.

Conflicts may arise because two developers were changing the same file within two different branches.

When GIT tries to merge them, it gets confused. It basically says “Hey someone else made a change here too … which one should I use?”

Its up to the developer driving the merge to decide which one is valid. Simply remove the lines that are not valid and clean up the marks GIT introduces into our file, then re-commit those new changes.

5. With a clean master branch, go ahead and push it back up to the remote

git push origin master

This syncs your change back up into the production code with your new feature added!

The Startup Lab