Git 101: What you need to get started

- 8 mins

Software developers usually work on teams. And, as you probably already know, a big part of their job is actually writing code. However, writing code while working on a team can prove to be tricky: how can you and 30 colleagues coordinate to code at the same time? How about keeping track of changes? What if someone accidentally deletes code? Just imagine the logistic nightmare this would entail without a proper way to organize the project…

Well, say hello to Git.

If you google Git, the first thing that pops up is that Git is a distributed version-control system. What this actually means is that Git is a tool that will allow you to:

Now that you know what Git is, we’re going to get you set up.

Installing Git in your computer

Head over to the official website and download a version of Git for your Operating System. Now open up a terminal (if you’re on Windows you might want to use this) and type

git --version

If you installed Git successfully, the terminal should print out a message showing your current version.

First Steps

Now let’s create a repo. A repo, or repository is just a folder in your computer containing the files you want Git to keep track of. You can initialize a repository on a folder already existing, or create a new folder and initialize one there.

Let’s create a folder and initialize a repo there. Again, from your terminal:

mkdir exampleFolder
cd exampleFolder

And once we’ve accessed it, let’s initialize our repo there:

git init

Now, let’s introduce ourselves to Git and allow the system to establish our identity:

git config --global user.name “your name” 
git config --global user.email [email protected]

Our First Commit

Imagine you have a time machine. Unlike conventional time machines, in yours you can only travel to places you have a snapshot of. For example, London in 1994 or Rome in 2005.

In our project, Git will be the time machine, and each of those snapshots is called a commit. A commit is the way Git has to see new files and changes made to existing ones in your repo from the last time you made a commit. Each commit is a snapshot of the current state of your project, and Git allows you to go back and forth between them.

To illustrate this, create a text file, write your name in it and place it in the folder you previously created and initialized your repository on. Now let’s add the changes you just made and commit them:

git add .
git commit -m "added text file with my name"

Notice that when you made the commit, you added a message. This is the commit message, and it should be descriptive. It’s good practice and you’ll probably thank yourself later.

The three Git stages

When we previously typed git add . the . represents all changes in files. But, when we tell git to add them, where exactly are we adding them? what does add actually mean?

It means that git will add all changes to the staging area, which is a place for all tracked files that haven’t beeen committed yet. Before executing the add command, the changes were untracked and after running it, the changes will be committed. This means the files now become part of the set of files Git keeps track of if they were new or will be updated with new changes if they already existed.

Once a commit has been made it’s identified by means of a commit hash, which is like a commit’s ID. We will use a commit’s hash to refer to that particular commit if we need to do so in the future. This way, if we ever want to go back to it to check something out, we just have to run

git checkout <hash>

Git stages in your local repo

Remote Repositories

This is pretty cool. But what about the “working with other people” part we mentioned before?

As you’ve seen, you can have a repository with the files for your project on your computer, that is, a local repository. Each contributor to the project will have one of those. What brings it all together is the presence of a remote repository: a repo hosted on someone else’s computer that all of you can access, contribute to, and get the latest code your peers commited from.

In practice, this is done through a service like Github. Go ahead and create an account there, and when you do, don’t forget to update your local Git username using the command we saw earlier so that it now matches your Github username.

Now, let’s check out what Github is all about. Go here and take a look at the current most popular repositories. If you go into their repos, you will notice this at the top of every one of them:

The main concepts in there you must understand are:

Forks: if you fork a project, you will create in your Github account a new repository with the exact same contents as the one you forked. You will probably want to do this to contribute to the original project or take the development of it in a different direction on your own.

Clones: when you fork a repo, you can only access it from your Github account. If you want to play with it, you will need an additional local copy in your computer. In order to get that copy, you have to “clone” the project locally.

If you click the green button, Github will provide you with the link you need to clone the project. Let’s clone it into your Desktop. Open up your terminal and run

cd Desktop
git clone [your link]

In this case:

cd Desktop
git clone https://github.com/TheAlgorithms/Python.git

And, as simple as that was, you just performed your first clone!

Branches: In a project, at some point you will usually want to implement shiny new features, and this is where branching comes in. The implementation of a feature usually implies the presence of unstable code while the feature is being built, which is why you want to do that in a safe space, separate from your main code base. That spance is a branch.

When you’re done implementing that feature, you’ll want to add it back into your main code base, which is called the master branch. This process is called merging.

Pull Requests: If you’ve made changes to a project and want the original repo to include your changes, you must open a pull request, which is a way for the creators of the original project to review your changes and choose wether to accept them or not. You can create one from the New Pull Request button at the bottom of the picture, and learn more about them here.

How to communicate with remote repositories

Putting it all together, let’s suppose you performed a fork of some repo, cloned the project in your desktop and modified some files. Now you want to send those changes back into your remote Github repository. In order to do that, open up a teminal and access your project folder:

cd Desktop/yourProjectFolder

Now, add all changes:

git add .

Commit them:

git commit -m "changed X"

And make a push, which will make the changes show up in the remote repository.

git push

If your were working with more people on this project and oneof your colleagues pushed changes to the remote repo, to add them back to your local repo you just have make a pull, which is like a push, but the other way around:

git pull

Further Steps

UPDATE: As of December 7, 2018 my friend Alvaro and I were able to give a workshop expanding the contents of this post to 50 UPV students, turning it into probably the largest workshop ever organized on Campus. Thanks a lot! ❤️

rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora