Git & GitHub: Theoretical concepts

What is Git?

Git is a distributed version control system (DVCS) that helps developers track and manage changes to a project’s files over time. Instead of simply storing data, Git captures snapshots of the entire project at various points (commits), making it possible to review history, collaborate with others, and revert to previous versions when needed.

What is GitHub?

GitHub is a web-based platform that hosts your Git repositories in the cloud. It allows developers to store their code online, collaborate with others, and manage projects using Git.
While Git tracks changes locally on your system, GitHub provides a remote location to push your repositories, making them accessible to others. In addition to repository hosting, GitHub also offers features such as pull requests, issue tracking, project boards, and automation with GitHub Actions.

Why do you need Git & GitHub?

You need Git because it allows you to track changes in your code, experiment safely with new ideas, and revert to previous versions when something goes wrong. For example, suppose you release a mobile app update with a new feature that causes issues. In that case, Git lets you revert your project to a previous commit and continue development in a different branch without losing work.

You need GitHub because it provides a cloud-based platform to share your Git repositories, collaborate with other developers, and work on projects together from anywhere. It also makes contributing to open-source projects easier, as thousands of repositories are publicly hosted on GitHub. Beyond hosting, GitHub offers additional tools like pull requests, issue tracking, project boards, and GitHub Actions to support team workflows.

History of Git and GitHub

Git was originally developed by Linus Torvalds in April 2005 as a distributed version control system for managing the development of the Linux kernel. Shortly after its release, Junio Hamano became and remains the project’s long-term maintainer.

GitHub was launched in April 2008, created by Tom Preston-Werner, Chris Wanstrath, and P. J. Hyett, using Ruby on Rails. Scott Chacon joined early and significantly contributed to its popularity. In June 2018, GitHub was acquired by Microsoft.

Working of Git

The Three States:

Git has three main states that your files can reside in: modified, staged, and committed:

• Modifiedmeans that you have changed the file but have not committed it to your database yet.
• Stagedmeans that you have marked a modified file in its current version to go into your next commit snapshot.
• Committed means that the data is safely stored in your local database.

This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.

1. The working tree is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
2. The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.
3. The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

The basic Git workflow goes something like this:

• You modify files in your working tree.
• You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.
• You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently in your Git directory.

If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified.

Tracked and Untracked files

Refer to the Git basics to know more about the topic.

Each file in your working directory can be in one of two states: trackedor untracked.

• Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.

• Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out, and you haven’t edited anything.

• As you edit files, Git sees them as modified, because you’ve changed them since your last commit. As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.