Git for Beginners

This is the first ever blog post of our new software engineering interns—Daniel, Simon, and Till. We'd love to hear your feedback!

Git is an open source version control system, used to store and manage code, maintain different versions of the program, share and collaborate with others and restore lost or broken code. While it offers a wide range of functionalities and options, only a few basic commands are necessary for the most common types of operations and becoming productive quickly.

Hint: You can find the official documentation at git-scm.com/docs.

The Prerequisites

Before you can start using Git, you need to install it on your computer. You can find the installation instructions for your operating system at git-scm.com/downloads. In general, a good starting point would be to have:

• Git installed
• A command line tool for executing git commands, such as Git Bash
• Basic knowledge about using the command line to navigate your file system

Before we begin creating our first repository, we need to configure our git user profile. This will later be displayed in commits, to track which user made a specific change. In our command line we run the following commands (substitute your own e-mail and name):

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Then, we can check if the configuration was successful by running:

git config --list

This should display the user name and e-mail address we just set.

Terminology

Before we start, let’s clarify some terminology:

• Repository: A repository is a directory that contains all the files and folders of your project, as well as the history of all changes made to them.
• Commit: A commit is a snapshot of the repository at a specific point in time. It contains all the changes made to the files and folders since the last commit.
• Branch: A branch is a separate line of development in a repository. It allows you to work on different features or bug fixes without affecting the main codebase.
• Remote: A remote is a version of your repository that is hosted on a server, such as GitHub or GitLab. It allows you to collaborate with others and share your code.
• Clone: Cloning a repository means creating a local copy of a remote repository on your computer. This allows you to work on the code locally and push changes back to the remote.
• Push: Pushing is the process of uploading your local changes to a remote repository. This allows others to see and collaborate on your changes.
• Pull: Pulling is the process of downloading changes from a remote repository to your local copy. This allows you to stay up-to-date with the latest changes made by others.
• Merge: Merging is the process of combining changes from one branch into another. This allows you to integrate new features or bug fixes into the main codebase.
• Conflict: A conflict occurs when two branches have made changes to the same line of code. Git will prompt you to resolve the conflict before merging.
• Working Directory: The working directory is the local copy of your repository where you make changes to files. It contains all the files and folders of your project.
• Fork: A fork is a copy of a repository that allows you to make changes without affecting the original repository. It is often used in open source projects to contribute changes.
• Pull Request: A pull request is a request to merge changes from one branch or fork into another. It allows others to review and discuss the changes before they are merged.
• Cherry-pick: Cherry-picking is the process of applying a specific commit from one branch to another. It allows you to selectively apply changes without merging entire branches.
• Checkout: Checking out a branch or commit means switching to that branch or commit in your working directory. It allows you to work on different features or bug fixes.

Creating a Repository: git init

The init command turns the current directory into a new Git repository. Let's first navigate to a folder that we want to turn into a repository and run the command:

git init

The chosen directory should now contain a single folder, '.git', which contains everything Git needs to track changes to this directory and manage branches (the folder is hidden and may not be displayed in your OS by default). For now this is only a local repository, since it has not yet been connected to any remote Git storage such as GitHub, GitLab or similar.

Cloning a Repository: git clone

Instead of initializing our own fresh repository, we can also use the clone command to download a copy of an existing repository. In a new empty directory, run for example:

git clone https://github.com/golang/go.git

This will create a local copy of the Golang repository with all of its branches. The URL can be found on the main page of the repository, and can be copied by clicking on the green "Code" button. Cloning can also be done using SSH, if you have set up SSH keys for your GitHub account. In this case, the URL would look different.

Preparing a Commit: git add

Let's navigate back to our first directory and create a new file:

touch test.txt
echo "Hello World!" > test.txt

If we now run the command git status to see the current state of our repository, we will see that the file is untracked. This means that Git is not yet aware of it, and it will not yet be included in the next commit:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        test.txt

We have not yet told git which files should be included in its tracking. To start tracking our newly created text file, we can run:

git add test.txt

– or we are feeling lazy and simply want to add everything in the directory at once, we could use git add . to recursively add everything new or changed in the directory and its subdirectories:

If we now run git status again, we will see that the file is now staged for commit:

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test.txt

The file has been staged, i.e. queued up for inclusion in a new version/revision of our repository, but not yet committed.

Committing Changes: git commit

We use the commit command to take all our staged changes and create a new commit, essentially a snapshot of the current state of our project that we can build on and possibly revert to at a later point. Let's do this in our repository now:

git commit

If no options are given, git will open the configured default editor for writing a commit message. Here we could add a title and description below the commented lines like so:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
#	new file:   test.txt
#
Added test.txt to the repo

This is the description, explaining the commit in more detail.
Anyone else reading this should be able to tell
what the commit contains and why it was made.

By convention, the first line should be the title, a single sentence explaining what the commit is about. The following text, separated by a blank line, can be used to further describe and explain the commit. Let's save the file and then close it. Git should recognize this and create the commit.

Note: If we want to change the default editor to, for example VS Code, we can do so by running git config --global core.editor "code --wait". Other editors can be set in a similar way, e.g. git config --global core.editor "nano" for nano or git config --global core.editor "vim" for vim.

The Remote Repository: git remote

At this point, our repository still exists only on our local machine. For purposes of backup and collaboration, we may want to maintain our repository on some kind of online platform. For this example we will use GitHub, but any alternatives such as GitLab or Bitbucket will work as well, as long as you have a working link and access to an online repository.

Let's assume we have set up a fresh repository at https://github.com/gentlent/test_project.git. We can now run the remote command, connecting our local repo to the remote one:

git remote add origin https://github.com/gentlent/test_project.git

We then use git remote -v to verify. It should show `origin` followed by our URL.

Pushing Changes: git push

We are now ready to push our previously created commit to the new remote repository and synchronize with it. Let's run a git push with some flags—origin being the default name for our remote, and main our own branch name:

git push -u origin main

Note: The default branch name used to be master in the past. Many platforms are nowadays defaulting to main instead. If the above command causes an error, check your branch name with git status.

Using the -u option flag causes git to associate the local branch with the remote repository. Any future push command will automatically push from main to origin/main without us needing to specify the targets. Checking our remote repository on GitHub, we can now see our text file has been uploaded.

Pulling Changes: git pull

If we have made changes to our remote repository, we can pull them into our local repository using the git pull command. This will download any changes made to the remote repository and merge them into our local copy. For example, if we have made changes to the test.txt file on GitHub, we can run:

  git pull

This will download the changes and merge them into our local copy of the repository. If there are any conflicts, Git will prompt us to resolve them before completing the pull. If we do this now, we will get the message Already up to date, because Git has fetched, determined that there were no new changes and skipped merging anything.

---

The above covers a bare minimum of functionality to start interacting with the git ecosystem. There are many more useful commands, particularly in regards to managing different branches, which are not explained here. You can find a more complete list of commands and their descriptions in the official documentation at git-scm.com/docs or by trialing them out in your command line. If you ever have a question about a command, you can run git help <command> to get a short description of what it does and how to use it.