We all use Git, it’s an amazing version control system that keeps our programs safe from our mistakes.
We can create branches and explore new programing ideas. And if they don’t work, we just get back to the working stage!
In this post you’ll find a small Git tutorial, just to get started using it!
Introduction to Git
Git is a powerful tool for programmers. Basically, it is a version control system that allows you to:
- create new branches of code to explore new ideas
- if you are satisfied with the results of these ideas you can upload them into the master (or main) version
- if you are not satisfied, you can simply recover the old version of the master branch
- it allows multiple programers to be working and developing the code
- and much more useful things!
You can get Git from the official website, and read a free online book here.
Create a Repository
First, we need to specify where we want to save the information about the different versions of our program. This is called initialize the repository.
Go inside the top folder of your project and initialize the repository there with:
$ git init .
where the dot . specifies that the location of the git repository is the current directory. You can change this dot with another directory path to save it there.
After you run this command, you’ll see a .git folder inside the current directory. There’s where the information about the different versions will be saved.
The Staging area
Next we need to specify which files and folders we want to track. In other words, which files and folders need to be in version control. In general, we are talking about files that change over time, like code files, that at some point we might want to reverse to an older version.
However, the usual way to manage this step is to define what we don’t want in version control in a file called .gitignore.
An example of content in this .gitignore file (which is located at the same level as the repository folder .git) is
static
*.pyc
key.txt
These lines specify that the folder static and its contents, all the files with the .pyc extension and the key.txt file will not be added into the version control system. For example, when starting a project is very important to remove any production key from the version control system. This way, not all the people that have access to the code will have access to the key.
Once we have specified the files in the current folder that we don’t want to track, we can get the rest of files into the repository with:
$ git add .
Now we have all the files in the current folder, except the ones in the .gitignore file, in the staging area.
The staging area is a middle step area before committing the files into the repository. We can check the files in this area using
$ git status
It’s a good practice to always check the files in the staging area before committing them into the repository. This way, if you have added a file that you don’t want to track, you can still unstage it (remove it).
For example, if the output of the previous command was
new file: code.py
new file: static/figure1.jpg
new file: static/figure2.jpg
new file: icon.ico
And you realize that you only want to commit (track for version control) the code.py file, you can unstage the folder static and the file icon.ico with:
$ git rm -r –cached static
$ git rm –cached icon.ico
Next, you should update your .gitignore file so that next time, these files are not added into the staging area. This file should now have:
static
*.pyc
key.txt
static
icon.ico
If you type again:
$ git status
You should see that it only contains the code.py file, as we wanted it.
Commit your Files
Once we are happy with the files in the staging area, we are ready to commit them into the repository:
$ git commit -m “Brief description of your commit”
where the -m flag let’s you specify a small description of your commit. If you don’t use this flag, this command will automatically open a text editor so that you can write the description there.
The default editor is the VI editor. Some people don’t know how to exit this editor, so I’ll give you a few basic commands: esc :q! to exit without saving, i to change the editor into editing mode (to write some text), esc :wq to exit saving the changes made).
You can also specify another text editor if you want to. For example to specify emacs instead of VI use:
$ git config –global core.editor emacs
Committing again
After you’ve made some changes into your files, you may want to commit them again. The steps to follow are:
- Update the .gitignore file if there are new files you don’t want to track
- Run git add . to add the files into the staging area. If you have changed only one folder, you can specify to only add that folder with git add myfolder.
- Check the files with git status and remove the files you don’t want to commit.
- You can also see the differences in your files since the previous commit with I git diff –staged.
- Commit your files with git commit -m “Brief description of changes”.
However, sometimes you just want to commit the files that are already in the repository (you don’t have any new file to add). In that case, you can use the shortcut git commit -a, where the -a flag means to automatically add any changes to tracked files.
This last command together with the -m flag to write your commit description becomes:
$ git commit -am “Brief description of changes”
Before running the last command, you might want to check the changes in your files with:
$ git commit diff
Note the difference between this command and the one used before with the –staged flag. This is because we are committing directly the tracked files into the repository, skipping the staging area. On the other hand, when we have the files in the staging area, we only want to see the changes we are about to commit, i.e. the changes on the staged files.
#Git Tutorial: Create a Repository, Commit, Git Branches and #Bitbucket. Don’t miss it! 😉 http://t.co/gdDhvV723T pic.twitter.com/rJbrajANI5
— Marina Mele (@Marina_Mele) July 25, 2014
Commit history
You can see all your commits with
$ git log
which displays them in the format:
commit large_commit_id
Author: Marina <marina.mele@gmail.com>
Date: Sun Jul 20 17:31:02 2014 +0200
Brief description of your commit
You can see all the display options with
$ git log –help
You’ll see there are a Lot of options! For example, to show each commit in a single line:
$ git log –oneline
small_id Brief description of your commit
Or to show the logs since one specific date, for example since the first of july:
$ git log –since=”Jul 01 2014″
Git Configuration
We have seen a little bit of the git configuration when specifying the default text editor, remember?
$ git config –global core.editor emacs
You can see all the configuration properties with:
$ git config –list
If you want to specify or change your name and email you can use:
$ git config –global user.name “Your Name”
$ git config –global user.email “your@email.com”
Git Branches
In the same repository, you can create different branches to make the code evolve independently in each of them. The default branch is usually called master.
You can check the local branches with
$ git branch
remote branches with
$ git branch -r
and both local and remote branches with
$ git branch -a
Moreover, you can check the properties of the remotes you have defined with:
$ git remote -v
which will output the alias used to identify that remote, and its URL. For example, if you are using Heroku to push your code into production, the previous command will give you something like:
Branches are one of the main functionalities of Git, and I encourage you to learn more about them in the official documentation.
However, in this post I would like to focus in creating a remote branch to store your code into a cloud repository, such as Bitbucket.
Git with Bitbucket
We will use Bitbucket to push our local repository (translation: save a copy of our repository in Bitbucket). This way, other programmers working with the code will be able to make a pull of the last commit (translation: they can download the last version of the code and work from there).
First, you will need a Bitbucket account, which you can create in their website.
Next, we need to create an empty repository in Bitbucket. We will need the URL of that repository, which you can find in the Overview –> Command line –> I have an existing project. You’ll also see the instructions to follow to push your local repository into Bitbucket (don’t worry, we will cover them here too).
First we need to add Bitbucket as a remote repository. Go to the folder of your local repository, the one that contains the .git folder, and type:
$ git remote add origin https://user@bitbucket.org/user/repository.git
where you should change the url with your repository url. This will create the alias origin to refer to your Bitbucket repository (using origin as an alias for a remote repository is a common convention).
Let’s check our remote branches:
$ git remote -v
Next, let’s push our existing repository into this new Bitbucket repository with:
$ git push -u origin –all
where the –all flag makes all the refs under refs/heads to be pushed, and the -u flag stands for –set-upstream (add a tracking reference). You will have to enter your password.
Let’s check the current branches of our repository, both local and remote:
$ git branch -a
* master
remotes/origin/master
the * indicates the working branch.
Moreover, after pushing the code into Bitbucket, if you type:
$ git status
you should see a line like
Your branch is up-to-date with ‘origin/master’
indicating that your local/master branch has the same state as the origin/master branch at Bitbucket.
Committing again into Bitbucket
Okey, now let’s imagine you made some changes in your code, and you want to commit them again in your local repository and update the Bitbucket repository as well.
First, let’s commit the changes into your local repository:
$ git add .
$ git commit -m “Changes done”
Next, if you run
$ git status
nothing to commit, working directory clean
Indicating that your local master branch has one more commit than the origin/master on Bitbucket.
Let’s fix that by pushing our code into Bitbucket:
$ git push origin master
If you run again git status you should see that both branches are up-to-date again 🙂
This was just a little introduction to Git, it’s much more powerful that what you’ve seen here, so keep learning! 😉
Please, share it if you found it useful and help me get to more people! 😉
And if you have doubts, comment and I’ll try to answer them!
Marina Mele has experience in artificial intelligence implementation and has led tech teams for over a decade. On her personal blog (marinamele.com), she writes about personal growth, family values, AI, and other topics she’s passionate about. Marina also publishes a weekly AI newsletter featuring the latest advancements and innovations in the field (marinamele.substack.com)