GIT is a revision control system that takes snapshots of your codebase. These are known as commits.

Each Git repo on a computer is independent from others, so changes saved in one don’t affect the contents of another. Git tracks these changes in what is called an index.

Git also has a centralized server to which people “push” commits. The centralized server is known as a remote repository.

Branches

Branches in GIT repositories are independent lines of development that can be merged back into the main line of code at a later date. They help developers work on features or bug fixes separately, without having to worry about merging their changes into the upstream master repository.

Git tracks changes to files in a repository through a special file called the commit log. Each commit in the log includes a message that describes the change that was made and the date and time of its creation. Each branch also has a pointer to the same commit, which is known as its parent commit. This is how Git knows which branch you are currently on. For example, the branch f30ab has a parent commit of master.

A branch is a version of the repository, and each branch has its own history of changes. Git also keeps a list of the differences between each branch and the upstream master branch. The branching system in GIT was created by Linus Torvalds after the proprietary source-control management (SCM) company BitKeeper revoked its license for Linux kernel development.

You can create a new branch by running the command git checkout branch name>. However, you should make sure that you have the latest upstream master branch checked out before doing this. Otherwise, you may lose unsaved changes.

Pull Requests

A pull request allows developers to make changes to code for a project without impacting the main version that end users are using. For example, if a developer is working on an improvement to the existing system, they can work on this feature in their own repository fork, and once they have finished, they can then create a pull request to merge those updates with the official code base of the project. This allows for a full review of the developer’s code changes, and for any necessary edits to be made by the repository maintainer before those updates are merged into the official project code.

For example, if Mary wanted to collaborate on the development of a new feature for John’s Bitbucket repository, she would fork it. Once she has her own fork, she can then clone it and then begin to develop the feature on her own machine. Once the feature is complete, she can then file a pull request to get her changes merged into John’s official version of the project.

When working on a pull request, MPS opens an overview of the PR and shows a list of the files that have been changed. If any of the PR’s assignees have added comments or suggestions, these are displayed on the right-hand side of the dialog box, along with a count of how many reviewers have commented on the change.

Commits

Git stores each file revision as a separate object that it keeps track of. These objects are called blobs or tree objects, and they contain a point-in-time snapshot of the files. They are zlib compressed to minimize disk space usage. Git also uses packs, which combine blobs to save space by storing only their differences.

Git also stores references to commit objects, called heads. Each head has a name that is unique to the corresponding commit object. A caret () after a commit name retrieves the parent object that was used to create it. Git uses these references to keep track of history and for merging.

The git add and git commit commands are the primary ways to make changes in your Git repository. git add takes the tracked files in your working directory and moves them into the staging area, and then git commit makes a permanent record of this staged state in your repository along with a message to remember it.

When you want to share your changes with other people, you do a pull from the remote repository to bring it up to date. This is typically followed by a merge of the pull with your local branch. Once your local and remote branches are in sync, you can push to write your changes onto the remote project.

Reverts

Git reverts let you return your repository’s files to an earlier state without changing the commit history. It does this by creating new commits that reverse the changes made by the original commits. For example, reverting a commit that added lines to your code would create new commits that removed the lines. Similarly, reverting a commit that changed file extensions could create new commits that assigned the correct extension to your files.

For example, if you accidentally introduced a bug in one of your previous commits and then discovered it in your current working copy, you can use git revert to undo the changes and get back to a clean state without losing any work. This is much more efficient than using git reset, which changes the commit history and may delete some of the files in your code base.

In addition, reverts are a safer option than deleting your current working copy and starting over from scratch because they do not change the commit hash of any of the files you have already committed. However, you will need to re-create the commits that are reverted if they have been pushed to a shared repository. For this reason, it is recommended that you use revert only when necessary. You can also use revert when a merge commit has been pushed to the repository, but you want to remove its changes.