What Is Git?
Author: Domeny.ForSale editorial team Published Updated
In brief: Git is a distributed version control system: a tool for recording the history of changes to files. It lets you compare versions, restore earlier content and combine several people’s work. It runs locally on your computer; neither GitHub nor an internet connection is needed for basic work.
What is Git used for?
Without version control, it is easy to end up with files named project-final, project-final2 and project-revised. Git replaces these manual copies with an organised history. Each deliberately saved stage can be described, inspected and compared with another.
Git is particularly useful for source code, configuration, documentation and articles saved as plain text, for example in Markdown. It can also store photos or office documents, but it usually cannot display their changes as clearly as differences between lines of text. Large, frequently modified binary files require additional planning for how they will be stored.
For example: you modify a contact form, and notifications stop working after the change. If earlier stages of your work were saved in Git, you can check exactly what changed and reverse the faulty modification. You do not have to recreate the previous version from memory.
Repository, commit and branch — the basic concepts
A repository is a database of the project’s history, together with the information Git needs to manage versions. In a typical local project, this data is stored in the hidden .git directory, alongside the working files you edit.
A commit is a saved state of tracked files, linked to the preceding history. It has an identifier, author information and a description. A good description, such as “Fix email address validation”, explains the purpose of the change better than “Fixes”. Git does not create commits automatically every time you save a file in your editor.
The staging area, also called the index, lets you select changes for the next commit. This means you can edit several files but save a bug fix and a documentation update separately. That makes the history easier to understand later.
A branch is a separate line of work within a repository. You can use it to develop a new feature without immediately changing the main version of the project. Merging combines changes from different branches.
The term distributed means that a normal clone of a repository gives you a local copy of its history, rather than just access to files on a server. Clones with limited history also exist. In a standard workflow, browsing saved changes and creating commits does not require contact with a central server.
Git and GitHub — what is the difference?
Git is a version control tool. GitHub is a service that, among other things, hosts Git repositories and provides collaboration features such as reviewing changes and reporting bugs. GitLab and Bitbucket serve similar roles; you can also maintain a repository on your own server.
A remote repository is another copy of a repository available at a specific address. The push command sends local commits to it, while fetch retrieves information and history from the remote copy without integrating them into the current branch. The pull command retrieves changes and then integrates them — the method of integration depends on the settings and options used.
Creating a commit therefore does not, by itself, publish your work on the internet. Likewise, sending changes to a hosting service does not necessarily make them public: visibility is determined by the repository’s permissions.
Getting started: saving your first changes
Install Git using the instructions for your operating system in the project’s official documentation. You can check the installation in a terminal with git --version. You can also use a graphical interface or your editor’s Git support, but the basic process remains the same.
In a new test directory, run:
git init
git config user.name "John Smith"
git config user.email "john (at) example.com"
These author settings apply to the current repository and are not used to log in. Choose the address carefully: author information is part of commits and may be visible to others when you share the history.
Create a README.md file in your editor, enter a short project description and save it. Then run:
git status
git add README.md
git diff --staged
git commit -m "Add project description"
git log --oneline
git status shows the state of the files. git add stages the specified content for saving, and git diff --staged lets you check it before committing. The last two commands save a stage of your work and display an abbreviated history.
Collaboration and Git’s limitations
When people collaborate, Git can automatically combine many independent changes. However, if two people change the same section in incompatible ways, a merge conflict may occur. You then need to determine the correct content manually, mark the resolved files with git add and complete the operation. Git does not judge which version is substantively correct.
Passwords, access keys and other secrets should not be added to a repository. The .gitignore file specifies which untracked files Git should ignore, but it does not remove data already saved in the history. An exposed key must be revoked or replaced; removing it only from the latest version is not enough.
Git is also no substitute for a full backup: it does not automatically protect uncommitted changes or files outside the repository. To get started, practise making two commits in a test directory and compare them with git diff HEAD~1 HEAD. You will see exactly how Git displays differences between saved stages.
See also: What Is AGI?
Read also
