Day -10 : Advanced Git & GitHub for DevOps Engineers Part 1

Day -10 : Advanced Git & GitHub for DevOps Engineers Part 1

ยท

7 min read

๐ŸŒŸ Introduction ๐ŸŒŸ

Welcome to Day 10 of the exciting #90DaysOfDevOps challenge! Today we're delving into Git's interesting world and its potent features. Git is a tool that facilitates developer collaboration, allows them to track changes, and allows them to efficiently manage their code. We'll discuss the ideas of branching, reverting, resetting, and merging in this blog. These methods are crucial for fostering cooperation and guaranteeing the security of our code. So let's get ready to learn about branch creation, committing changes, and rolling back code. We'll also learn how to seamlessly integrate our work by merging and rebasing. So let's start this Git adventure together while you're strapped in! ๐Ÿš€๐Ÿ’ป๐ŸŒŸ

๐ŸŒฟ Git Branching and Its strategy

Imagine you and your team are working on a web application, and you have a Git repository set up to manage the codebase. The default branch is usually called "master" or "main," which represents the stable version of your application. ๐ŸŒฟ

Now, you want to add a new feature to the application, let's say a user login system. Instead of making these changes directly in the "master" branch, you create a new branch called "feature/login." ๐Ÿš€

git checkout -b feature/login

Now you have switched to the "feature/login" branch, and you can make all the necessary changes to implement the user login system without affecting the main codebase. ๐Ÿ’ป

While you are working on the "feature/login" branch, your teammate is also working on a different feature, such as adding search functionality. They create a branch called "feature/search" to work on this task.๐Ÿ”

git checkout -b feature/search

Both of you can work independently without interfering with each other's code changes. This way, the "master" branch remains stable, and you can continue to release updates without any disruption. ๐Ÿค

Once you have completed the login feature, you can merge the changes back into the "master" branch.

git checkout master
git merge feature/login

Now, the main branch has the new login feature, and you can deploy it to the production server. At the same time, your teammate has completed the search feature and merged it into the "master" branch as well.

Git branching strategies can also help in managing releases and bug fixes. For example, if you discover a critical bug in the "master" branch, you can create a hotfix branch to address the issue without affecting ongoing development. ๐Ÿ”ง

git checkout -b hotfix/bug-fix

Once the bug is fixed, you merge the hotfix branch back into the "master" branch and any other active branches.

git checkout master
git merge hotfix/bug-fix

๐Ÿ”„ Git Revert and Reset

Git Revert: ๐Ÿ”™ When you make a mistake in your code and want to undo a specific commit without erasing its history, you can use Git Revert. It creates a new commit that undoes the changes made in the specified commit. This means that the commit you want to revert will still exist in the history, but the changes it introduced will be removed in a new commit. It's like going back in time and undoing a mistake without altering the past. ๐Ÿ•ฐ๏ธ

Git Reset: ๐Ÿ”„ Git Reset, on the other hand, is a more powerful command that allows you to move the current branch to a specific commit. It has different modes like "soft," "mixed," and "hard." The "soft" mode keeps the changes from the commits you reset as staged changes, the "mixed" mode keeps them as unstaged changes and the "hard" mode discards them completely. In simple terms, Git Reset helps you to reset the branch to a previous state and removes the commits after that point. ๐ŸŒฑ

๐Ÿ”€ Git Merge and Rebase

Git Merge: ๐Ÿค Imagine you and your team are working on a group project. Each team member is responsible for a specific feature. Git Merge is like getting everyone's work together at the end of the day and combining it into a single document. It takes the changes from different branches and brings them into the main branch, creating a cohesive codebase. It's like teamwork, where everyone contributes their part, and the project becomes more complete and robust. ๐ŸŒŸ๐Ÿ‘จโ€๐Ÿ’ป๐Ÿ‘ฉโ€๐Ÿ’ป

Git Rebase: ๐Ÿš€ Think of Git Rebase as time travel! When you use Git Rebase, it's like going back in time to the point where you branched off and replaying your changes on top of the latest work. It's like updating your project to the most recent version and integrating your improvements smoothly. This keeps your commit history clean and organized, just like maintaining a clear timeline of project progress. But be cautious, as time travel can be tricky; you may encounter conflicts that need to be resolved. ๐Ÿ•ฐ๏ธ

๐Ÿ“‹ Task 1: Branching, Committing, and Restoring

๐ŸŒŸ In this task, we'll explore how to create a new branch ๐ŸŒฟ, make changes with various messages ๐Ÿ“, and restore a file to an earlier version โช. Just follow these simple steps:

  1. ๐Ÿš€ Create a new branch named "dev" from the main branch and verify the change using the command "git checkout dev".

      git checkout -b dev
    

  2. ๐Ÿ“ Create a new text file named version01.txt and fill it with the following content:

       "This is the first feature of our application."
    

  3. ๐Ÿ“‚ Use the "git add" command followed by the file names to prepare the tracking changes. Then commit this change with the message "Added new feature."

  4. ๐Ÿ“ค Push the dev branch to the remote repository using the command:

       git push origin dev
    

  5. ๐Ÿ”„ Make additional commits to the dev branch by updating the version01.txt file and commit this change with the message "Making the following changes: ...".

       This is the bug fix in the development branch
    

  6. ๐Ÿ”„ Perform this step two additional times, including the provided content, and commit each change with relevant messages.

       This is gadbad code
    
      This feature will gadbad everything from now.
    
  7. ๐Ÿ”™ Revert the version01.txt file to a previous state with the content "This is the bug fix in the development branch."

  8. ๐Ÿ“œ Using the "git log --oneline" command, find the <commit> information and identify the commit you want to reset to.

๐Ÿ“‹ Task 2: Branching, Merging, and Rebasing

In this task, we will explore the concepts of branches, merging, and rebasing. To get started, follow these steps:

  1. ๐Ÿš€ Let's merge the "dev" branch with the "main" branch. First, check the commits on the "dev" branch by using "git checkout dev" ๐Ÿ‘ฉโ€๐Ÿ’ป. Then, switch back to the "main" branch and check its commits as well ๐ŸŒฟ. Now, execute the "git merge dev" command to combine the commits and observe the results.

  2. Now, execute the "git merge dev" command to combine the commits and observe the results.

  3. ๐Ÿ”„ As a practice, perform a git rebase operation to see the difference it makes. Describe the differences you observe ๐Ÿ”„.

In this sequence of commands, the "dev" branch is checked out, and a new text file named "version01.txt" is created with specific content ๐Ÿ“. The changes to the file are staged and committed with an appropriate message ๐Ÿ’ฌ. After inspecting the commit history on the "dev" branch, the working branch is switched to "main," and a rebase is performed. The rebase incorporates the commits from "dev" onto "main," resulting in an updated commit history on the "main" branch. This process showcases the interplay between branches, merging changes, and how Git allows developers to manage code development seamlessly.

Notes: Git merge combines changes from one branch into another, creating a new merge commit. Git rebase moves the commits of one branch on top of another, creating a linear history. Merge preserves the original commit history, while rebase provides a cleaner, linear commit graph for easier project tracking.

๐ŸŽ‰ Conclusion ๐ŸŽ‰

Congratulations on completing Day 10 of the #90DaysOfDevOps challenge. Today, we delved into advanced Git techniques like branching, merging, and reverting, vital for effective collaboration and version control in software projects. Don't miss Day 11, where we'll continue our Git and GitHub journey for DevOps Engineers in the second part of this topic. Stay tuned! ๐Ÿš€๐Ÿ‘ฉโ€๐Ÿ’ป

Did you find this article valuable?

Support Sahil Kamble's blog by becoming a sponsor. Any amount is appreciated!

ย