The year is 2005, and Linux kernel developers are using BitKeeper, the software for the source control management system. As they are breaking and fixing the kernel, a storm is coming. BitKeeper author decides to make BitKeeper a proprietary software for Linux kernel developers. We won’t go into details of the developer’s public drama, but after a few harsh words and broken keyboards, Linus Torvalds, the creator of Linux, decides to build Git. If you want to define Git, there is no better explanation than the one provided on its website: “Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.”
Git is still a free version control software, and to get started, install it on your computer using the following guide. Once it’s installed, position yourself in an empty directory and run the following command:
The command will initialize the Git repository, and you will be ready to use a wide range of
To list all files and directories run:
You should see the
.git directory, which contains all necessary configuration files and versioning for the Git repository. So each file in the same directory as
.git is visible to the Git repository.
As computer wizards created Git, it is understandable that it requires a steep learning curve. But there are helpful resources for managing the climb up that curve. A useful command to start with is:
If you execute this command, you will see a list of all available commands you can use. Some of these commands you will use quite often, such as:
start a working area (see also: git help tutorial) clone Clone a repository into a new directory init Create an empty Git repository or reinitialize an existing one grow, mark and tweak your common history branch List, create, or delete branches commit Record changes to the repository
help argument can refresh your memory about the usage of each of these commands individually, for example:
git help merge
It will provide a detailed description of functionalities and arguments you can use while merging branches. If you are ready to start working with Git on a project, let’s try to implement basic file tracking. You must add the files to the staging area to begin tracking file changes. If you change multiple files but want to track just a specific file, you add it to staging. Let’s move to an example, create a file example.txt with some random text, and add it to the Git repository:
git add example.txt
After executing the above command, the file has been moved to staging and it’s being tracked by Git. Once the files with changes are in the Git staging, you can see the change in the whole Git repository by executing the following command:
You should see a similar output:
On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) example.txt
As you can see from the results above, this is the current status of your repository. Now it’is time to make a snapshot of the current repository state that you will use for eternity, or until the delete command do you part. The snapshot lets you return to a previous state in the project. To create a snapshot, you need to create a commit:
Now, enter a commit message, and the commit will get a hash number you can use to return to the snapshot. To see the changes you have made, execute:
commit 8055e024f1dc4781715de69594549ce294a8832a (HEAD -> master) Author: Ante Javor <[email protected]> Date: Wed Aug 31 09:18:12 2022 +0200 Initial add of example.txt!
As you can see from the results, the commit hash (8055e…), or snapshot has been saved.
If all this seems too strange and unfamiliar, try starting with Pro Git book - it’s also free.
As the name suggests, GitHub is a hub for Git repositories. Since efficient collaborative work on software projects is crucial, GitHub created a cloud-based collaborative platform for software engineers. If you look at GitHub from a technical standpoint, it is a cloud extension of your local Git repository. There are a bunch of projects you can contribute to. One of them is Memgraph ❤️. We use GitHub for our collaborative work on different software engineering projects.
To get the memgraph Git repository on your local machine, you can clone the repository by executing the following command:
git clone https://github.com/memgraph/memgraph.git
This will copy all the source code to your local machine, and you can start hacking. But since you are not the only person working on Memgraph, you cannot make changes directly to the repository. The first thing you need to create is a branch. A branch is a separate repository snapshot that does not influence something Git defines as a master branch. Once you initialize the repo, there is always a master branch. Memgraph will probably have multiple branches since many people are working on it. In order to see all the branches, you can execute:
The command will list branches developers are working on. Now, let’s assume you want to contribute to Memgraph. You would start with creating a new feature branch for yourself. To start with a new branch, execute the following command:
git branch cool-new-feature
You’ve only created the
cool-new-feature branch. To start development on the new branch, you need to check it out:
git checkout cool-new-feature
checkout action will move the HEAD pointer to the new branch. The HEAD pointer is just an indicator of the branch you are currently working on. After repositioning to the new branch, you are ready to start coding. But there is much more to learn and discuss regarding Git and GitHub: branches, merging, conflicts, GitHub CLI, etc. This is not the end of the journey - Buda will guide you through the rest of the GitHub features in Code with Buda video.
Code with Buda
If you are interested in more details on how to work with GitHub and contribute to Memgraph, there is no better way to learn something than to get your hands dirty by following our CTO Marko Budiselić, a.k.a Buda. In this video, you will learn how to do it on the Memgraph repository: