The Absolute Beginners Guide to Git

I was aware of the purported joys of git long before I experienced it. I avoided it because I was a solo developer and it was one more thing to learn. Once I started using it I quickly found I didn’t want to live without it, even as a solo developer.

I’m going to be using a fair number of metaphors in this post, because that’s what helped me understand what was going on in my git flow.

The Old Way of Doing Things

Years ago, if I was working on a project that I was going to change in a large way I’d copy the current version to a backup folder, and then work on a new copy. Once I was done I’d have to manually try to merge the two codebases back together.

Git does almost exactly this, but in a much more organized way, and only duplicating what it really needs to. It can easily make as many copies (it calls them branches) as you wish, and when you’re ready to merge them back together it takes care of the details. If there’s a real conflict it can’t magically fix it marks it and lets you choose which version you want to use.

Here’s an introduction to Git and Version Control:

{wistia}wf7wm1ms0j{/wistia}

Getting Git Installed

I’d like to recommend you create a free account at GitHub.com. Once you have an account you can create a repository, or repo for short. This allows you to keep one of your copies at github. It also allows people to look at your code, make their own copy, and write code to be merged back into your code.

Installing git on your local machine varies by operating system:

• Windows: Download from the git site, or you can use Chocolatey Package Manager.
• Mac: I would suggest installing with the Homebrew package manager.
• Linux: Use whatever package manager your distro prefers.

The GIT Interface

There are a variety of ways to access git in your workflow. I’ll describe some and let you choose which you like.

• Command Line: This is my favorite. I’m a command line user from way back, so it just fits. The git commands are pretty simple, and you’ll find yourself using the same 5 or so over and over.
• GUI: There are lots of GUIs for git, on every platform. The syntax is the same in them, you would simply need to find one that feels right to you. I would suggest using Sourcetree which is a very good GUI for git.
• In Your IDE: Most modern IDEs have built-in support for git these days. phpStorm and Sublime Text both support it well. These would allow you to interact with git right from within your IDE. However you decide to use it, the things that need to happen are the same.

For the purposes of this post we’re taking an existing project and putting it into git. I’m also going to use the command line for this since it’s the easiest.

The Process #1: Local Repository

Pull up a terminal and cd into the folder with your project. Then type

git init

and press enter. This initializes git in this folder. Behind the scenes it’s creating a folder called .git (note the . at the beginning of that word) that stores information about this shiny new git repo you’ve made.

At this point git still doesn’t know about your files. Our next step is to tell git they’re there by adding them to git’s staging area.

git add -A

Now git knows about all your files, but they’re not committed yet. For that we’ll use

git commit -m “My first commit!”

If you don’t pass the -m flag then git will take you to an editor (usually vim) to put in whatever comment you wish. Since I love vim I always do it that way, but the -m flag makes it easy to just do your comment all at once.

The Process #2: Remote Repository

Now you have a local git repo. If you want to share it with other people you’ll want a remote repo. If you go to your github repo you can choose to create a New Repository. You’ll give it a name like my-cool-repo and then it’ll give you some instructions very much like what I gave above.

Once it exists you can do something like this:

git remote add origin https://github.com/topher1kenobe/my-cool-repo.git

That tells your local git repo where the remote one is. Then the last step is to push your local files to the remote repo:

git push -u origin master

And now your files are on the master branch, which in our metaphor from above is the original copy.

The Process #3: Using Your Repository

Now that you have a git repo all set up we’ll go through the steps of using it. In the old way, we’d make a copy of the entire project. With git we’ll create a branch called my-new-branch, like this:

git branch my-new-branch

and now we have a space called my-new-branch. We’re not using it yet though, we’re still on the master branch. To start using this new branch we can do something like this:

git checkout my-new-branch

The two above commands can actually be done in one, like this:

git checkout -b my-new-branch

Now you can do all kinds of new work on this new branch. When you change a file, do another add and commit, like this:

git add filename
git commit -m "here are the changes I made"

You can then push these files to the remote repository, on the new branch, like this:

git push origin my-new-branch

The Process #4: Merging Back To Master

Once you’re done with your work, and you wish to combine your new work with your old work, you’ll want to merge it to the master branch. We’re still on the

git checkout master

Pro-tip: you can checkout the branch you last came from like this: git checkout –

Now that we’re back on the master branch we can merge in the other branch like this:

git merge my-new-branch

and now the two are the same, with the new work in both places. At this point you have two identical branches, and you could continue to build on my-new-branch, but I personally don’t recommend it. I like to keep branches specific to single issues, so once the issue or problem is resolved then I like to delete the branch, like this:

git branch -D my-new-branch

And now we’re back to having only master. At this point you’d want to push your new master back to the remote repo with this:

git push origin master

Practical Tips

I mentioned above that I like to keep branches specific to one issue or problem. I recommend you have some sort of issue or ticket tracker elsewhere in your workflow. JIRA and Pivotal Tracker are both excellent ticket trackers. Github has a built-in issue tracker as well.

Here are some examples. If you were using JIRA, and had a project called My Project, then your tickets will all get ID numbers like this: MP-134. In that case I would name my branch MP-134 as well, to associate the branches with tickets.

Github issues are similar. They’re simply numbered with a prefix of “issue” like this: issue-134. In that case my branch would be called issue-134. Github has some nice integration with that as well. When merging issue-134 to master, your comment can include text like this:

Closes #issue-134

and the status of that issue will automatically be marked as resolved. There are a number of shortcuts like this.

Summary

• Git allows you to easily make a copy of your workspace, work on it all you want, and then merge it back into the original.
• Not only that, multiple people can be working on multiple branches at the same time, and usually git merges it all together flawlessly. When it stumbles it has a nice way of resolving the conflicts.
• You can make a branch, work on it, and push the branch to the remote repo and ask your friend to pull down that branch to take a look at the problem you’re having.
• If you’re using a service like github or bitbucket, and your code is public, total strangers can clone your code, create a branch, and then send you a pull request, asking you to merge their code into master. In this way you can safely have dozen, hundreds, or thousands of other developers working on your project.
• Each person who works on the project has a complete copy of the project. This means that if the main remote repo disappears it can be restored by anyone on the project.

Lastly, the git web site has an excellent manual online, I highly recommend you check it out. Here are some suggestions for getting help with Git:

{wistia}bnce9grv7h{/wistia}