Git for Dummies

A crash course on git

“It is the long history of humankind…those who learned to collaborate and improvise most effectively have prevailed.”

— Charles Darwin

(tl;dr: use git for group projects. scroll to the next section)

Group projects can be tricky. It’s hard enough to balance group dynamics and to make sure that everyone’s doing their fair share of work. But when someone’s work gets accidentally overridden and hours of work gets lost through a faulty file transfer — things can get messy. At some point, using AirDrop to transfer similarly-named documents just doesn’t cut it anymore.

Google Docs solved this problem for the majority of group projects, and likewise, version control systems like Git did the same for collaborative coding projects. To avoid the chaos, a friend and I decided to use Github to keep track of our work. The result? No fights or hurt feelings over whose AirDrop messed up the files. Success!

There are many reasons why Git is an amazing tool, but there are a few commands we found ourselves using most frequently. To get you started, here they are:

Creating your repository

Once you’ve created your git repository (on Github, Bitbucket, etc.), head over to your command line. Navigate to the folder where you want to store your repository, and type in the following commands.

git init

This initializes your local repository.

git clone <link>

This clones your remote repository to your local.

If you were to clone my snake repository, it would look like this:

git clone https://github.com/taylorwan/snake.git

If you don’t have a remote repository yet, you’ll need to point your repository to an origin later on (See: git pull origin <branch>).

Adding and updating files

Now, go ahead and make a file (or many files) in your repository. You can do this in a traditional way or via the command line (see example at the bottom of this section). Use whatever tool is familiar to you. I usually do this in the editor I plan to use in building out my project.

git add <file>

Adds the file you just made.

Let’s say we just made a file called test.txt. Let’s go ahead and add it.

git add test.txt

Alternatively, you can use “-A” to stage all changes in your current directory:

git add -A

git commit -am “<message>”

Commits the changes you just made to your local repository.

Commits are like checkpoints you set for yourself. I like to keep each commit as small and to the point as possible. In the long run, this keeps the code base organized, and will help preserve the sanity of everyone on your team. Commits can also prove helpful later on, if you need to undo a sizeable chunk of work.

Let’s commit a set of changes with the message “first commit”.

git commit -am “first commit”

git pull origin <branch>

Pulls any changes your team members may have made to the remote repository (AKA their changes have been “pushed” — see next section) while you were also making changes. This isn’t absolutely necessary, but I find it to be good practice in order to keep up with master.

Let’s go ahead and pull master.

git pull origin master

At this point, if git gets angry and roars a bunch of nonsense at you, you’re probably missing an origin. This might be because we didn’t clone a repository when we were starting out. Try adding it!

git remote add origin https://github.com/taylorwan/snake.git

git push origin <branch>

This “pushes” the changes you made to a specified branch to the remote repository. Once we’ve done this, your team members can “pull” and see your changes.

git push origin master

At this point, if git gets angry and roars a bunch of nonsense at you, make sure you are a contributor (or the owner) on the project in order to contribute directly. The other option is to fork the project to your own account, and submit pull requests when you want your buddies to pull your changes. It’s a neat process for contributing to open source projects, but it’s not necessary for a group of friends.

If you are a contributor or owner, and git is still angry, refer to my last comment above (See: git pull origin <branch>).

In a more concise list, here’s what we just did:

touch test.txt       # creates test.txt
git add test.txt
git commit -am “first commit”
git pull origin master
git push origin master

Three Handy Commands

These are handy for displaying information and undoing changes.

git status

Prints your current status, including files that have changed since your last commit and files that are not currently tracked by your repository.

git branch

Displays the branch you are currently on.

git reset --hard origin/master

Undos all local changes. This makes your local repository identical to your remote repository. Proceed with caution.

See full documentation here.

Alternatively, if you want to undo a commit that is already on your remote branch, here’s how.

Creating a new branch

Branches are used to develop new features, without affecting the master branch. For example, if I wanted to play around with a different layout for my project, I’d create a new branch, new-layout.

git checkout -b <new branch>

Create a new branch based off the current one, and switch to that branch.

In our case, it would look like:

git checkout -b new-layout

Now you are on the new branch, and are free to push without having to worry (too much) about changes occurring on the master branch. Personally, I like to pull master once in a while so that when we eventually merge, there aren’t too many conflicts.

Switching to another branch

Now that we have two branches, how do we navigate between the two? We do something called “checkout”. We can “check out” a branch like we would with a book from a library.

git checkout <branch>

Navigate to specified branch

If we wanted to switch from new-layout (or any other branch) to master, it would look like this:

git checkout master

What about branches that my buddy created? Well, we can get those too! Just make sure that your friend pushes his/her branch before you try to pull them.

git fetch
git checkout <branch>

Merging two branches

Eventually, once you are done developing your feature, you should merge your branch back to master. Let’s pretend we’re on branch new-layout, and have just finished up our changes. The way that I like to do this is as follows:

git fetch
git commit -am “finishing touches on new layout”
git pull origin master
git status               # explanation below
git checkout master
git pull new-layout      # the name of our feature branch
git push origin master

We commit all the changes we make, and then “pull” any changes that have been made to master to our current branch. This way, if there are any conflicts after we pull, we see the files that have been affected when we print the status (git status). Assuming you’ve been pulling master once in a while (which you should be doing!), there shouldn’t be many conflicts.

Finally, we move to branch master, pull in the changes from new-layout, and push master so our code is available for the world (or whoever) to see.

To do this with any other two branches, follow the same format. Replace new-layout with the branch to be merged and master with the branch that is being merged into.

Deleting a branch

Once you’ve pulled your feature to the master branch, we can delete the branch where the feature was developed.

First, let’s make sure we’re on the master branch (or some branch other than the one we’re trying to delete).

git checkout master

Now, we need to delete that branch in both our local and remote repositories.

git branch -D <branch>

Deletes a specified branch locally.

Let’s go ahead and delete new-layout from our local.

git branch -D new-layout

git push origin --delete <branch>
git push origin :<branch>

Deletes a specified branch from the remote repository.

Woah, what?! Yup, there’s two ways of deleting a branch from our remote repositories. Which one is better? That’s hard to say. For the time being, both work, and it’s up to you to determine which one you prefer.

As for me, I find the latter to be easier to remember, so that’s the one I typically use. Let’s go ahead and delete new-layout from our remote repository.

git push origin :new-layout

If we were to do it the other way, it would look something like this:

git push origin --delete new-layout

And we’re done!

That should be all you need for your first project in git. Thanks for reading! If you found this helpful, please recommend or share this article with others, I’d really appreciate it (:

But…this! And that!

Questions? Comments? Suggestions? Send me a note @taylorwants.

Resources

• Official Git Guide
• Git Cheat Sheet (From git — the simple guide)
• Index vs. local vs. remote, etc.