Introduction

Git is a version control system used for tracking changes in computer files. It is generally used for source code management in software development.

• Git is used to track changes in the source code
• The distributed version control tool is used for source code management
• It allows multiple developers to work together
• It supports non-linear development through its thousands of parallel branches.

1. The most basic building block of version control is a “repository”.

Think of a repository as a kind of database where your VCS stores all the versions and metadata that accumulate in the course of your project. In Git, the repository is just a simple hidden folder named “.git” in the root directory of your project. Knowing that this folder exists is more than enough. You don’t have to (and, moreover, should not) touch anything inside this magical folder.

2. Getting such a repository on your local machine can be done in two ways:

(a) If you have a project locally on your computer that is not yet under version control, you can initialize a new repository for this project.

(b) If you’re getting on board a project that’s already running, chances are there is a repository on a remote server (on the internet or on your local network). You’ll then probably be provided with a URL to this repository that you will then “clone” (download/copy) to your local computer.

3. As soon as you have a local repository, you can start working on your files: modify, delete, add, copy, rename, or move files in whatever application (your favorite editor, a file browser, …) you prefer. In this step, you don’t have to watch out for anything. Just make any changes necessary to move your project forward.

4. It’s only when you feel you’ve reached a noteworthy state that you have to consider version control again. Then it’s time to wrap up your changes in a commit.

A commit is a wrapper for a specific set of changes. The author of a commit has to comment on what he did in a short “commit message”. This helps other people (and himself) to understand later what his intention was when making these changes.

Every set of changes implicitly creates a new, different version of your project. Therefore, every commit also marks a specific version. It’s a snapshot of your complete project at that certain point in time (but saved in a much more efficient way than simply duplicating the whole project…). The commit knows exactly how all of your files and directories looked and can therefore be used, e.g., to restore the project to that certain state.

However, before you commit, you’ll want to get an overview of what you’ve changed so far. In Git, you’ll use the “status” command to get a list of all the changes you performed since the last commit: which files did you change? Did you create any new ones or delete some old ones?

5. Next, you tell Git which of your local changes you want to wrap up in the next commit. Only because a file was changed doesn’t mean it will be part of the next commit! Instead, you have to explicitly decide which changes you want to include. To do this, you add them to the so-called “Staging Area”.

6. Now, having added some changes to the Staging Area, it’s time to actually commit these changes. You’ll have to add a short and meaningful message that describes what you actually did. The commit will then be recorded in your local Git repository, marking a new version of your project.

7. From time to time, you’ll want to have a look at what happened in the project – especially if you’re working together with other people. The “log” command lists all the commits that were saved in chronological order. This allows you to see which changes were made in detail and helps you comprehend how the project evolved.

8. Also when collaborating with others, you’ll both want to share (some of) your changes with them and receive the changes they made. A remote repository on a server is used to make this exchange possible.