Day 10 : Advance Git & GitHub for DevOps Engineers.

Day 10 : Advance Git & GitHub for DevOps Engineers.

·

6 min read

Git Branching

Git branching is a way to split a project into smaller, separate parts so that multiple people can work on it simultaneously without interfering with each other's progress. It allows developers to try out new ideas, fix bugs, or add features without affecting the main codebase. Think of it like different branches of a tree; each branch grows independently, but they all stem from the same trunk. In the case of an industry, let's say we have three branches: Master, Support, and Dev.

  1. Master: This is the main branch where stable, tested, and production-ready code lives. It's like the trunk of the tree, representing the final product that customers use. Only well-tested and reviewed changes get merged into the Master branch.

  2. Support: This branch is for maintaining older versions of the software. Imagine this branch as a strong limb that supports the growth of the tree. When a customer reports a bug or needs assistance with an existing feature, developers create a new branch from the Support branch, make necessary fixes or updates, and then merge those changes back into the Support branch. Once the changes are verified and tested, they get merged into the Master branch.

  3. Dev: Short for "development," this branch is where new ideas, features, and improvements are developed. It's like a branch that's still growing and experimenting with new directions. Developers work on their assigned tasks, creating new branches from Dev, making changes, and then merging them back into Dev once they're complete. Once the changes are thoroughly tested and reviewed, they get merged into the Master branch.

By separating the development process into these three branches, teams can efficiently collaborate, test, and deliver high-quality products without disrupting the main codebase.

Git Revert and Reset

Git reset and git revert are two commands in Git that are used to undo changes to a project code and history, but in different ways. Here is a brief explanation of each command:

  • Git Reset: This command is used to move the tip of a branch to a different commit, which can be used to remove commits from the current branch. Practically, it can be thought of as a "rollback" that points the local environment back to a previous commit. However, it does alter the existing commit history, so it should be used with caution.

  • Git Revert: This command is used to undo changes that have been committed to the repository by creating a new commit that undoes the changes made by the specific commit. It adds a new commit at the end of the chain to "cancel" changes, rather than moving the branch pointer back in the chain. It is useful when only a specific commit needs to be undone and can be used even when the changes have been made public.

To better understand the differences between these two commands, we can use a diagram. Consider the following series of commits in Git:

A -> B -> C -> D -> E

Suppose we want to undo the changes made in commit C. Here is what would happen with each command:

  • Git Reset: If we use git reset to move the branch pointer back to commit B, the commit history would look like this:
A -> B -> C

Commit D and E would be removed from the branch, and any changes made in those commits would be lost. This is why git reset should be used with caution, especially when the changes have been made public

  • Git Revert: If we use git revert to undo the changes made in commit C, a new commit would be created that undoes the changes made in C. The commit history would look like this:
A -> B -> C -> D -> E -> F

Commit F would be a new commit that cancels out the changes made in C, but leaves the rest of the commit history intact. This is why git revert is a safer option when the changes have been made public.

In summary, git reset should be used when we want to remove commits from the current branch, while git revert should be used when we want to undo changes made in a specific commit without altering the commit history.

Git Rebase and Merge

Git Rebase and Git Merge are two commands in Git that are used to integrate changes from one branch into another. Here is an explanation of each command:

  • Git Rebase: The git rebase command integrates changes from one branch onto another by replaying all the commits from the source branch onto the target branch. It essentially moves the completed work from one branch to another, typically the master branch, by applying the same set of commits on top of the target branch. This process rewrites the commit history of the original branch and creates a new branch with the updated commits. It is useful for separating feature branches on the master branch and simplifying merge conflicts.

  • Git Merge: The git merge command combines the changes from one branch into another by creating a new commit that incorporates the changes from the source branch into the target branch. It adds a new commit to the target branch, preserving the history of both branches. This command is commonly used to merge different branches in Git and is suitable for situations where preserving the history of the source branch is important.

To better understand the difference between these two commands, consider the following scenario:

       Commit History
A -> B -> C -> D -> E (master branch)
         \
          F -> G -> H (feature branch)
  • Git Rebase: If we use git rebase to integrate the changes from the feature branch onto the master branch, the commit history would look like this:
       Commit History
A -> B -> C -> D -> E -> F' -> G' -> H' (master branch)

The commits from the feature branch (F, G, H) are replayed on top of the master branch, creating new commits (F', G', H') with updated changes. The original commits from the feature branch are replaced with the new commits

  • Git Merge: If we use git merge to integrate the changes from the feature branch onto the master branch, the commit history would look like this:
       Commit History
A -> B -> C -> D -> E -> M (master branch)
         \           /
          F -> G -> H (feature branch)

A new commit (M) is created that combines the changes from the feature branch into the master branch. The history of both branches is preserved, and the merge commit (M) represents the integration of the changes.

In summary, git rebase replays commits from one branch onto another, rewriting the commit history, while git merge creates a new commit that combines the changes from one branch into another, preserving the history of both branches. The choice between these commands depends on the specific requirements of the project and the desired outcome of the integration process.


Tasks

In this way I performed the given tasks of Day10 of the #90daysofdevops challenge using Gitbash and by using the knowledge mentioned in the above blog.
Thankyou for reading until here.Happy Coding!