15 Git Commands To Master Before Your Very First Project | by AnBento | Towards Data Science

You just started your first project as a web developer and wish to keep track of a multitude of changes in your working directory? You finally got selected for an interview as a junior data engineer and feel a bit rusty on the version control topic? Or you simply work in data science and want to learn more about Git and the command line to show your team that you can achieve the same result without using any GUI at all?
If you answered “Yes, here I am!” to at least one of the profiles above, then this tutorial can definitely help you to learn more about version control through the command line and it will do it quickly!
As many other Data Analysts and BI Developers, I got to know version control trough the GitHub GUI. At that time, my company was using Looker as a visualisation tool and it could be configured with a handy Git integration to manage file versions while in development mode.
Every step was so visually appealing and user-friendly while committing and deploying changes, that I did not learn about the true Git potential until a data engineer one day told me: “Version control? I am always using the same 4–5 commands in my terminal and job done! I rarely access the user interface”.
And then he just typed another git push origin master while I stared at his laptop in admiration. And that’s when I realised that the next step would have been for me to learn the command line and how to version control with Git.
In the rest of this tutorial, you will find the 15 commands that I use the most while working on my projects.
towardsdatascience.com
Git is a command line tool used for version control, you can access by simply typing git in the shell. The first step is to create a new directory and initialise a repository:
$ mkdir medium_git$ cd medium_git/
I have created a medium_git folder that I will use for the rest of this tutorial and that will include a list of all the commands discussed below. It can be found in my code_tutorials repository in GitHub.
1. git init → This command initialize a repository inside the medium_git folder meaning that now on, it will track multiple versions of the files in the folder. Initializing a Git repository will also create a dir called .git inside the repository folder. Files and folders with a period prefix (.) are typically private, and don’t show up by default when you list the files in a folder unless the ls -a command is used:
$ git initInitialized empty Git repository in /Users/antonellobenedetto/Documents/medium_git/.git/$ ls -a.  ..  .git 
Then let’s create a markdown file (.md) named git_commands, that only includes a brief description of what git init does and save it in the medium_git repository.
2. git add → In git, files can be in one of the following three states: modified, staged, committed. If you are ready to commit files you have modified, you can add them to the staging area with the git add [file name] command. Staged files are then marked for inclusion in the next commit without being committed yet:
$ cat git_commands.md1. git init <-- initializes a repository inside the folder$ git add git_commands.md
You could have achieved the same result with git add .(or using a wildcard git add *) . The only difference is that, in this way, all the files in the repository will be staged at the same time.
3. git config user.name/user.email → Before your first commit, it’s good practice to tell git who you are. This is particularly important when you are working in a team so that each member can identify who made a certain commit:
$ git config --global user.name ‘anbento’$ git config --global user.email ‘anbento@myemail.com’
If you wish to check your configuration settings, type git config -l.
4. git commit -m ‘ your message’ → A commit stores a snapshot of the files in the repository at a certain point in time. By building a history of these snapshots, you can rewind to an earlier point in time. The -m flag indicates that you’re adding a message and the text in quotes that comes after it is the commit message itself. It’s customary to make the commit message something informative, so if we do have to rewind or merge code, it’s obvious what changes have been made and when:
$ git commit -m ‘Adding git_commands.md file’[master (root-commit) 815d087] Adding git_commands.md file1 file changed, 3 insertions(+)create mode 100644 git_commands.md
5. git log → You can pull up a repository’s commit history using this command. Each commit is assigned with a 40 char long unique ID or hash. Commit hashes are permanent meaning that Git preserves them and includes them in transfers between the local and remote repos. Also notice how the name and email of the commit author are displayed under each commit history:
$ git logcommit 815d087f132288112b7e427617be0408e6db4974 (HEAD -> master)Author: anbento <anbento@myemail.com>Date: Sat Apr 4 08:19:16 2020 +0100Adding git_commands.md file
6. git remote add [remote name][remote url] → At some point, you may wish to push your changes to (for example) a repository on GitHub, so that you can access your full project history using other devices or just to collaborate with your team. In order to do that, you first have to create the repository itself and then run the command in the terminal:
$ git remote add origin https://github.com/anbento0490/code_tutorials.git$ git remote -vorigin https://github.com/anbento0490/code_tutorials.git (fetch)origin https://github.com/anbento0490/code_tutorials.git (push)
In this case, firstly I have created the code_tutorials repository on my GitHub account and then I added it as a remote under the origin alias. Bear in mind that “origin” is just a name assigned by convention, but you are free to name the remote differently if you wish. By specifying the -v option, you can retrieve the full remote url assigned to each alias. If you made a mistake and wish to remove the remote, simply run the git remote remove origin command.
7. git push [remote name] [branch name] → Once you have made changes to the local version of the repo, you can push them to the remote repo so that your project is safely stored in the cloud with its entire commits history. This means that even if your laptop crashes or gets stolen, your work won’t be lost and could be retrieved from your GitHub account. To accomplish that, you need to push the master branch to the remote “origin” repo:
$ git push origin masterCounting objects: 3, done.Delta compression using up to 4 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 282 bytes | 282.00 KiB/s, done.Total 3 (delta 0), reused 0 (delta 0)To https://github.com/anbento0490/code_tutorials.git* [new branch] master -> master
Once you do that, files that were originally only available in the local working directory will be uploaded in your remote repo as well as info about your commits:
8. git clone [repository url] [folder name]→ If you or one of your colleagues wished to download your project folder on another device, you could do that by cloning the remote repository locally. In my case, I moved back to the home directory and cloned the repository assigning the original name medium_git:
$ git clone https://github.com/anbento0490/code_tutorials.git medium_gitCloning into ‘medium_git’...remote: Enumerating objects: 3, done.remote: Counting objects: 100% (3/3), done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.
The command above, not only creates a directory named “medium_git” but it will also initialise a .git directory inside it, pull down all the data for that repository, and checks out a working copy of the latest version.
The very first time you try to clone a private repo from a remote repository, you will be asked to provide username and password (unless already using SSH Key to connect to GitHub). Credentials can be embedded directly in the url in this way:
git clone https://your_username:your_pw@github.com/anbento0490/repo_name.git
After you provide authentication once, Git caches your credentials in memory and hands them out on demand. If the git config credential.helper command return manager, the password is stored in the windows credential manager, if it returns store, password is stored in a .git-credentials file in the user folder and if it returns oskeychain it’s stored in keychain.
9. git pull [remote name] [branch name] → When the latest commit in the local repo is older than the latest commit in the remote repo, you can use git pull to update the working directory so that it has the same files as the latest commit. For this tutorial, to simulate what usually happens in a collaborative environment, I have edited the git_commands.md file directly in GitHub adding more commands to the list and committed the changes:
This action has created a new commit with a unique identifier. The commit and the changes are only visible in the remote repo, before the following command is run:
$ git pull origin masterremote: Enumerating objects: 5, done.remote: Counting objects: 100% (5/5), done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.From https://github.com/anbento0490/code_tutorials* branch master -> FETCH_HEAD815d087..b3088e3 master -> origin/masterUpdating 815d087..b3088e3Fast-forwardgit_commands.md | 10 +++++++++-1 file changed, 9 insertions(+), 1 deletion(-)
10. git diff [HEAD~1] [HEAD]→ If you now run git log after pulling from the remote repo, you will see two commits, with the one on the top, being the most recent. To see the difference between the 2 commits just type:
$ git diff HEAD~1 HEADdiff — git a/git_commands.md b/git_commands.mdindex ddd61c8..3cb7e12 100644— — a/git_commands.md+++ b/git_commands.md@@ -1,3 +1,11 @@+Git 15 Most Used Commands1. git init ← initializes a repository inside the folder+2. git add+3. git config user.name/user.email+4. git commit -m ‘ your message’+5. git log+6. git remote add [remote name][remote url]+7. git push [remote name] [branch name]+8. git clone [repository url] [folder name]+9. git pull [remote name] [branch name]
Instead of typing the first 3–4 chars of each hash, you can use the special variable called HEAD that always refers to the most recent commit in the current branch. You can also use shortcuts to get older commit hashes with HEAD~1 being the second newest commit in the local repo, HEAD~2 the third newest commit, and so on.
11. git fetch [remote name] [branch name] → Exactly like git pull , this command is used to download files and commits from a remote repository into your local repo. You can consider git fetch the more conservative version of the two commands as it will download the remote content but not update your local repo’s working state, leaving your current work intact. If you have pending changes in progress in local git fetch will avoid conflicts to arise and than is often used in a collaborative environment to see what everybody else has been working on without forcing you to actually merge the changes into your repository.
To show how useful git fetch is, I have added another command to the list in GitHub and committed the change, so that the remote repository has again more commits than the local one. The third commit ID starts with 40ae0be and you can verify that by running the following 3 commands:
$ git fetch origin masterremote: Enumerating objects: 5, done.remote: Counting objects: 100% (5/5), done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.From https://github.com/anbento0490/code_tutorialsb3088e3..40ae0be master -> origin/master$ git checkout origin/masterNote: checking out 'origin/master'.You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:git checkout -b <new-branch-name>HEAD is now at 40ae0be... Update git_commands.md$ git logcommit 40ae0bebb77b8df716439b94bb5005a65c0e6301 (HEAD, origin/master)Author: AnBento <35920666+anbento0490@users.noreply.github.com>Date:   Sun Apr 5 06:56:07 2020 +0100Update git_commands.mdcommit b3088e373b881a526844826a2dade7b1443eefbb (master)Author: AnBento <35920666+anbento0490@users.noreply.github.com>Date:   Sat Apr 4 18:39:48 2020 +0100Update git_commands.mdcommit 815d087f132288112b7e427617be0408e6db4974Author: anbento <anbento@myemail.com>Date:   Sat Apr 4 08:19:16 2020 +0100Adding git_commands.md file
Because fetching does not add any of the new commits to the local repo, you should use git checkout origin/master to switch from the local branch (master) to the remote branch (origin/master) and enter a so called ‘detached HEAD state’. This allows you to explore what has been committed to remote repo by your colleagues, running familiar commands like git log and git diff .
12. git reset [ — flag][#hash] → Let’s imagine that after fetching the new commits you were happy with the changes made by your team so that you run git pull to update your local directory, but at a later stage you noticed a problem and wanted to revert back to the penultimate commit or you simply wished to see what the project looked like at an earlier point in time. In both cases you could run:
$ git reset — hard HEAD~1HEAD is now at b3088e3 Update git_commands.md
With this command Git switches back to the commit with that particular hash . As mentioned, to make your workflow quicker, you could take advantage of the special variable HEAD. The — hard flag resets both the working directory and the Git history to a specific state. If you omitted the flag, or used the — soft flag instead, it would skip making changes to the working directory, and only reset the Git history.
13. git branch [branch name] / git branch -d [branch name] → Git branches allow users to create several different work areas within the same repo. In a professional environment, is very common to create a new branch whenever you wish to make several changes to a project or to fix a bug, and then merge that branch back into the master branch when we’re done. When you initialize a new local repo, Git automatically creates the master branch:
$ git branch* master
To create new branches run the following command:
$ git branch project1/add_commands$ git branch project1/branch_to_delete$ git branch* masterproject1/add_commandsproject1/branch_to_delete
In this way you will create two branches (project1/add_commands and project1/branch_to_delete) that will now be listed together with the master branch. The name of branch should be meaningful and make apparent the reason why it has been created in the first place (add a new feature, fix a bug , perform a chore) . To delete a branch use the git branch delete [branch name] command:
$ git branch -d branch project1/branch_to_deleteDeleted branch project1/branch_to_delete (was b3088e3).
14. git checkout [branch name] → To switch to the new branch run the following command:
$ git checkout project1/add_commandsSwitched to branch ‘project1/add_commands’
A common shortcut would have been to use the git checkout -b [branch name] command that creates a new branch and switch to it right away. Once you’ve created a branch and added a commit, you can push the branch to the remote repo. This allows other people to see your changes and collaborate with you on that separate work area:
$ git push origin project1/add_commandsCounting objects: 3, done.Delta compression using up to 4 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 444 bytes | 444.00 KiB/s, done.Total 3 (delta 1), reused 0 (delta 0)remote: Resolving deltas: 100% (1/1), completed with 1 local object.remote: Create a pull request for ‘project1/add_commands’ on GitHub by visiting:remote:https://github.com/anbento0490/code_tutorials/pull/new/project1/add_commandsremote: To https://github.com/anbento0490/code_tutorials.git* [new branch] project1/add_commands -> project1/add_commands
In my case, I have added the last 5 commands to the list and committed the changes through the project1/add_commands branch. Eventually, I pushed the commit to the remote repo so that now two branches are visible on the GitHub account, with project1/add_commands displaying one commit more than the master repo:
You can also use git branch -r to show all of the branches on the remote and confirm that yours is there. In contrast, git branch -a will show all of the branches available locally:
$ git branch -rorigin/masterorigin/project1/add_commands$ git branch -amaster* project1/add_commandsremotes/origin/masterremotes/origin/project1/add_commands
15. git merge [new_branch name] → Merging allows developers to to copy commits from one branch into another. This enables collaborative work as every team member can efficiently develop features for projects on their own branches without conflicts, then merge them into master so that end users will have access to them. To merge project1/add_commands into master, check out to to the master branch and then run the git merge command:
$ git checkout masterSwitched to branch ‘master’$ git merge project1/add_commandsUpdating b3088e3..cdb97d4Fast-forwardgit_commands.md | 8 +++++++-1 file changed, 7 insertions(+), 1 deletion(-)$ git branch -d project1/add_commandsDeleted branch project1/add_commands (was cdb97d4).
To avoid confusion, once the missing commits have been merged into the master branch, the newer local branch is often deleted.
To the ones that managed to get to the end of this tutorial I say: “Very well done!” I hope that what you learnt here, rewarded you for your patience. In this post I took you through the 15 Git commands to master before you start your first project in web development or data science, as version control is cool and will save you a lot of headaches! If you wish read even more, make sure to check this excellent Git tutorial provided by Bitbucket.