Installation & Basic Commands - GIT for beginners, Part 1
So, you've been a developer for a while now and want to take your efficiency to the next level, huh? Well, I got something for you: GIT Version Control. In this tutorial series, we'll go through it step by step and I'll get you started real quick. You'll soon realize that it's not that hard after all.
In this part, we'll focus on understanding why we need GIT, what it does and how to install/initialize it.
- basic command line skills
- advanced computer skills
First of all, Imma give you a quick history lesson on GIT :)
So first of all, for those of you who don't know:
Git is a term of insult with origins in English denoting an unpleasant, silly, incompetent, annoying, senile, elderly or childish person. As a mild oath it is roughly on a par with prat and marginally less pejorative than berk.
Basically, if someone calls you a git, you're actively being offended.
As you may suspect by the irony of the name, Linus Torvalds developed the idea of GIT.
This is how Linus is joking about the name:
I'm an egoistical bastard and I name all of my projects after myself. First Linux, now GIT.
I'm not kidding, he really said this.
Originally, GIT has been developed to improve the collaboration between the Linux Kernel developers. Although there are some alternatives to GIT (like Mercurial), GIT is the most popular version control system (VCS).
So what the f* is GIT doing and why do I need it?
As already mentioned, GIT is a version control system (VCS) that helps developers to keep track of their (file) changes. Among other functionality, it allows you to switch between different versions of your code and even compare them to each other. Especially when you're working on a bigger project, GIT is essential for your success, believe me.
Let's say you've been working on a super cool feature for your iOS Swift Application - drag & drop functionality for example. While working on the feature, you mess up the ENTIRE project - literally, everything is BRICKED now. [laughs in UIKit]
This is where GIT comes in handy. Just switch back to your last saved version ("commits", as the versions are called; more on that later on) and implement your feature again - if possible without bricking your entire project.
So far, so good!
This is not the only positive thing to GIT, however. If you're working together with other developers on your project, GIT helps you to keep your stuff together. Imagine 10 people working together on an iOS Swift Application - without GIT, there would be no (efficient) way to keep the different versions of the project in sync. What if developer A works on a local copy and renames a variable? How would the other 9 developers receive the changes? Via E-Mail? Ugh.
⚠️⚠️ How GIT works (skipping this part isn't recommended) ⚠️⚠️
As you know now, GIT keeps track of the (file) changes you make and creates versions of these files in a so-called repository (VCS, remember?)
However, not every change you produce is automatically saved in the repository. This comes as GIT has three areas - the working copy, staging area and repository.
The working copy is an exact copy of your repository. You can freely modify it without modifying the repository. In other words, this is what you're working on.
Once you've made all desired changes to your project, you might want to save these changes to your repository. In order to do so, you must "stage" your changes, i.e. put the changed files into the staging area.
Files in the staging area are prepared to be "committed" (saved) into the repository. You can either "stage" all of your changed files or each file individually. Note: Staging files doesn't modify the repository, i.e. does not create a new version of your project!
To do so, we have to "commit" the files from the staging area into the repository. Again, we can either commit all files at once or each file individually. Only with the commit, GIT creates a new version of our project inside our repository. This new version then stores all changes we just made.
This is a simple sketch of the basic workflow with GIT:
For the perfectionists among you: GIT doesn't track changes on file-level but on character-level. If you only change one line of code, GIT won't save the whole file together with the new version. Instead, it stores only the changed characters and "applies them on top of the previous version" - this makes it very efficient and fast! If you don't know what I'm talking about - no worries, this is nothing but pure theory you won't need to use GIT 😴
So, let's finally get started with the installation of GIT!
First of all, GIT isn't installed on your OS by default.
You can check if GIT is already installed by running the following command in the terminal / command line:
> git --version
If it's already installed, you should get a message similar to this one:
git version 2.21.0
So, how do we start GIT? Is there a nice little program with a beautiful GUI that we can use? [laughs in command line] No. By default, GIT is used via the command line / terminal.
Don't get me wrong, there are programs with nice and beautiful GUIs that do the GIT terminal calls in the background for you, but to be honest, most people use the command line or their IDE (more on that later on) as it's way faster than using these programs. If you want to use these programs nonetheless, here is a link to Sourcetree, a very widely-used GUI for GIT.
In order to use GIT for your project, you must initialize it first. Therefore, you have to switch into your project folder using the command line / terminal:
> cd /Users/yourusername/Downloads/example-project
Your path may be completely different as this is just an example of what the command could look like. If you don't have any clue what I'm doing here, I recommend that you check out some tutorials on how to use the command line.
Once we've successfully reached our project folder, we initialize GIT by running this simple command:
> git init
You should get a response similar to this one:
Initialized empty Git repository in /Users/yourusername/Downloads/example-dir/.git/
When you now open the folder in the explorer / finder, you will most likely see nothing. BUT: there is something. Running the above init-command creates a new hidden directory ".git".
If you want to see the hidden folder, you can do so by changing the settings of your finder / explorer.
On MacOS press:
Cmd + Shift + .
On Windows follow this tutorial
This should be enough double-checking for today, let's move on with the basic commands.
Now that GIT is up and running, it will track all the changes you make. Here are some basic commands that are important when working with GIT:
> git status
Using this command, GIT will display the state of all files that are currently in either the working directory or the staging area. More specifically, you'll see which file changes have been staged, which haven't and even which ones aren't tracked by GIT at all. However, it does not show you any information about your commited project history.
> git log
log does what
status doesn't. Running it will display the entire commit history of your repository as well as some details to each commit.
3. Add & Remove
In order to stage files, GIT gives us the
add command. We can either stage a single file by specifying its name
> git add <filename>
or all changed files at once using
> git add .
Obviously, you can always unstage a file with
> git rm --cached <filename>
You'll get used to the syntax real quick - these are two of the most used commands when working with GIT.
Once your files are in the staging area, committing them is just one command away:
> git commit -m “This is my supercool commit message. It should be very descriptive.”
⚠️NOTE: You may get an error message that GIT needs more information about you in order to be able to perform the attempted commit. Just introduce yourself to GIT by running these two commands
> git config user.email "firstname.lastname@example.org"
> git config user.name "Calvin Harris"
Nice! Now that GIT knows your email address and your name, rerun the commit command and you'll be all good :)
Congrats! With these commands at your disposal you're already able to use all of GITs basic features. Nice, isn't it?
Now that you know the most basic GIT commands, we can move on with some more advanced topics like branching and remote repositories. Although the branching tutorial isn't quite ready yet, check out the one on remote repositories here.
I would love to hear your feedback! Let me know what you liked or what could've been better with this tutorial - I always welcome constructive criticism! If you have any questions, just comment them and I'll try my best to help you out :)
In love with what you just read? Follow me for more content like this 👀
© GIFs from Giphy
© Storycover from Sam Raza's post on GIT workflow strategies