Git 101: What you need to get started
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:
- track changes in your code and go back and forth between them if it were necessary
- do that while working with other people
Now that you know what Git is, we’re going to get you set up.
Installing Git in your computer
If you installed Git successfully, the terminal should print out a message showing your current version.
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:
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 a way Git has to see new files and changes made to 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>
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 committed 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 on 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, just like that, 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 codebase. That space is a branch.
When you’re done implementing that feature, you’ll want to add it back into your main codebase, 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 whether 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 on 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 terminal and access your project folder:
Now, add all changes:
git add .
git commit -m "changed X"
And make a push, which will make the changes show up in the remote repository.
If you were working with more people on this project and one of 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:
- Keep one of these and refer to it when you don’t remember a particular command.
- If you’re a student, check out GitHub Education’s Student Developer Pack, which contains a ton of awesome stuff. You can get it here.
- Try to build a website and host it using GitHub Pages.
- Take part in Hacktoberfest, learn more about Open Source, and make your first pull request.
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! ❤️