Git as an onion

Git is an open-source version control system that allows developers to track and manage their codebase. It allows several developers to be able to work on one particular project simultaneously without interfering with each other's work. We'll be looking at Git as an onion in which we unfold each layer one by one until we get to the core which is understanding what Git really is.

Benefits of Git

1. Git helps in tracking changes, making it possible to reverse back to the previous stage in case something goes wrong.
2. Git allows for multiple people to be able to work on one single project at once.
3. Git acts as storage, allowing people to share their work. Git heavily relies on the branching system.

Branching
One of the layers of our onion is Branching.
Branching traditionally means diverging from the main development line. It is copying a copy of what already exists.
A branch can also be called a pointer to a commit. The default branch is always the main branch in which other branches are then created from. Branches are mainly created for features, bugs, fixes, experiments, and so on.

Branching Strategy
Branching Strategy is basically defining a set of rules to define how to work with branch. It is creating a structured workflow.

Types of Workflow

• Centralized Workflow
  In a centralized workflow, work is done usually in the main branch, and it is the most common branch among developers working on personal projects. This is actually not often advised as it is hard to keep track of changes.

• Gitflow Workflow
  Gitflow Workflow, unlike centralize workflow, this involves a number of branches. There is usually the main branch, which is the stable branch and then the development branch where all the changes happen. We also have a feature branch, which is created solely for development of a particular feature, a release branch for a release, hotfix branch to fix codes already in production, and so on.

• Forking Workflow
  A fork is a copy of a repo a developer has worked on. A developer can make a copy of a repo(fork a repo)and then make their own changes and then push to their account without affecting the original repo. This workflow is usually used in open source projects.

• GitHub Workflow
  GitHub Workflow compare to other workflows is lightweight and favoured by GitHub. This workflow is also created around branches and revolves around pull requests. The GitHub Workflow is the workflow in which we will be discussing more in depth in this article.

GitHub workflow heavily operates on a pull request system. Once changes are made in a development branch, the changes are then pushed to the main branch and then this is done by creating a pull request. What the pull request does is it announces a push to a branch, allowing other collaborators to discuss, reveal changes, or even add more commits to the pull request.

Pull Requests
A pull request is another layer of the onion. A pull request improves code quality, as it allows a review system which ensures only quality codes are pushed to production. It also allows transparency to know what changes are made and then who made them. It also allows control which makes sure that only what we want to be pushed to production are pushed. And lastly, pull request also encourages collaborations as it allows developers to review each other's codes, approve and leave comments if there is need to.

A pull request is created using the Git push command
After a pull request has been approved, it is merged into the destination branch.

Merging
After a Pull request has been reviewed and found satisfactory by the reviewer, it is then Merge into the new branch, fully allowing changes made in the feature branch to be visible also in the destination branch.

Type of merge

• Merge commit
  The default type of merge on GitHub is the merge commit. With this, a new branch is created that brings changes made in the feature branch. This contains histories of both branches.

• Squash and merge
  Changes made in the feature branch are squashed into a single commit before merging into the destination branch.

• Rebase and merge
  Using this approach, the commits from the feature branch are placed on the destination branch, and then a merge is executed. The history of the destination branch is rewritten with the new commits.

Merging vs Rebasing
Git Rebase solves the same problem as Git merge. They were both designed to integrate changes from one branch to another. This is however just done in different ways. Git Merge combines histories and creates a merge commit, while Rebase moves your commit on top of another branch, completely rewriting the history. Git Merge preserves exact commit history, while Git Rebase creates a linear and cleaner history.

When to Merge?

• When collaborating with other developers on shared branch
• To preserve historical paths development took, what branches were combined and so on

When to Rebase?

• When working on a solo project
• To avoid unnecessary merge conflicts

Merge conflicts
A Merge Conflict occurs when changes are made on the same line of code by different developers. A Merge Conflict can also happen if the file with the changes made in has been deleted. A Merge Conflict has to be resolved before a Merge can happen.

Pull requests go through several states. The first one is the open state which indicates the PR is active and under construction ready to be merged. The second stage is the approved stage after which one or more reviewers have gone through the code and are satisfied with the states. This indicates that the PR is ready to be merged. Change Requested states. This indicates that a reviewer requested that changes be made in a particular file before the PR can be merged. Closed PR. A PR that is closed has been merged.

Git Cherry Picking
Git cherry Picking is an advance merging method. Gits Cherry Picking copies specific commits to another branch. It moves specific commits from one branch and then just that commit is moved into another branch. It creates duplicate commits in each branches, which can also cause confusion.

It is an advanced Gits feature and shouldn't replace a commit.Cherry‑pick does not move the commit. It creates a copy of the commit, but with a new parent in the branch that you're cherry‑picking into. The original commit stays the same.

When to cherrypick?

• bug fix that applies to multiple versions of a product

• Merge changes from a branch into another without merging the entire branch.

Git Blame
Git Blame is one of the many layers of the onion. It shows the last changes made in the file, when it was made and who made them

When to use Gif Blame

• When debugging, it can be used to trace who walked on the path.
• To preserve history.
• For accountability.

Understanding Git is like peeling an onion layer by layer Before you get to the core, which is understanding how Git works, we have to peel through each layers, one after the other. Pool request, branching, etc. There are several other layers that are also not discussed in this article.