Git — a simple introduction

You can use Git on your project to keep track of any set of files that you like. When multiple developers or coders are working on the same piece of software, it’s common to utilize this tool to keep track of their progress. Its primary goals are speed, data integrity, and support for non-linear workflows (thousands of parallel branches running on different systems). Git was invented in 2005 by Linus Torvalds with the help of other Linux kernel engineers. Since 2005, the principal maintainer has been Junio Hamano. Like other distributed version control systems and unlike most client-server systems, every Git directory on every device is a full-fledged repository with entire history and full version tracking capabilities, independent of network connectivity or a central server. Open-source software Git is licensed under the GPL-2.0 license, making it completely free to use.

Many Linux kernel engineers handed up access to BitKeeper, the proprietary SCM system they had been using to maintain the project since 2002, in April 2005, when Git was first started to develop. SourcePuller creator Andrew Tridgell’s copyright holder Larry McVoy had withdrawn the free usage of BitKeeper after asserting that Tridgell had reverse-engineered the BitKeeper protocols. Mercurial, another version-control system, was also inspired by this episode. Because no free plans suited Linus Torvalds’s requirements, he had to pay for a service like Bitkeeper. It took Torvalds 30 seconds to apply a patch and update all accompanying information in a source control management system. He highlighted that this wouldn’t scale to the needs of Linux kernel development, where synchronizing with fellow maintainers could require 250 similar operations simultaneously. He set a time limit of three seconds for patching and added three more objectives to his design criterion.

• As an illustration of things not to do, consider the Concurrent Versions System (CVS). If in doubt, do the opposite.
• Assist with a distributed process reminiscent of BitKeeper.
• Put in place strong precautions against corruption, whether it’s unintentional or purposeful.

Because these conditions rendered obsolete every version-control system in use at the time, Torvalds set out to create his own shortly after the 2.6.12-rc2 Linux kernel development release.

Git’s development began on April 3, 2005. Torvalds announced the project on April 6 and began self-hosting the next day. On April 18, the first merger of several branches happened. Torvalds met his performance targets; on April 29, the immature Git benchmarked recording changes to the Linux kernel tree at a pace of 6.7 patches per second. Git was in charge of the kernel 2.6.12 release on June 16.

On July 26, 2005, Torvalds handed over maintenance to Junio Hamano, a key contributor to the project. Hamano was in charge of the project’s 1.0 release on December 21, 2005, and he remained its primary maintainer.

Using a text editor like vs code, navigate to a directory on your local machine, and then run git init from the command line to get started with Git for your project. You’ve just set up a git repository, also known as a repo in the programming world. It keeps track of all changes to these files in a private git directory. To keep track of the most current state of a set of files while you work on a project, you may use snapshots or commits. Thanks to a unique identifier for each commit, it is possible to go back in time to a previous version of our files.

Take note of the glowing source control indicator. As a result, all of our files remain untracked. You may stage these files in the repository by running git add on the console. As soon as you’ve finished making changes to these files, execute git commit to capture the current state of your repository. Congratulations on taking the first step into mastering git.

The modified files vanished from the head of this repository’s main branch. And you’re now working in a clean directory. The head is used to indicate the most recent commit. If we make any modifications, we should commit them to the repository. The head advances. However, a reference to our earlier commits remains. As a result, we may always return to it. However, the nature of software development is non-linear. You may have numerous teams working concurrently on various features for the same codebase.

It does this by branching. Create one by executing git branch and then moving into it with git checkout. You may now work on your feature securely on this branch without impacting the main branch’s code or files. The commitments you make here take place in an alternate reality with a different past. However, you’ll probably want to combine this history with the history and main branch at some time. Run git checkout to return to the main branch when you’re ready. Then, on your other location, run Git merge. The tip of your feature branch has been elevated to the level of the main branch’s head. You have now successfully combined code in two distinct locations. Unless, of course, you encountered a merge conflict.