Advanced Git & GitHub for DevOps Engineers: Branching, Reverting, Rebasing, and Merging | Day 10 of 90 Days of DevOps🚀💡

In this blog post, you’ll learn some of the essential skills and techniques for using Git and GitHub as a DevOps engineer. You’ll learn how to:

• Create and manage branches for different features and bug fixes
• Revert and reset your changes to a previous state
• Rebase and merge your branches to keep your history clean and avoid conflicts
• Use emojis to add some fun and personality to your posts

Let’s get started!

🌿 Git Branching 🌿

Branching is one of the most powerful features of Git. It allows you to create multiple versions of your codebase and work on them independently. You can use branches to develop new features, fix bugs, experiment with ideas, or do anything else you want.

To create a branch in Git, you can use the git branch command followed by the name of the branch. For example, to create a branch called dev, you can run:

git branch dev

This will create a new branch that points to the same commit as your current branch. To switch to the new branch, you can use the git checkout command followed by the name of the branch. For example, to switch to the dev branch, you can run:

git checkout dev

Alternatively, you can use the -b option to create and switch to a new branch in one command. For example, to create and switch to a branch called feature1, you can run:

git checkout -b feature1

To see all the branches in your repository, you can use the git branch command without any arguments. This will show you a list of branches with an asterisk (*) next to the current branch. For example:

$ git branch
* dev
  feature1
  master

To delete a branch in Git, you can use the -d option followed by the name of the branch. For example, to delete the feature1 branch, you can run:

git branch -d feature1

However, this will only work if the branch has been merged into another branch. If the branch has unmerged changes, you will get an error message like this:

error: The branch 'feature1' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature1'.

To force delete a branch with unmerged changes, you can use the -D option instead of -d. But be careful, as this will permanently delete any changes that are not in any other branch.

🔄 Git Revert and Reset 🔄

Sometimes, you may want to undo some of the changes you made in your repository. For example, you may have introduced a bug or made a mistake that you want to fix. There are two main ways to do this in Git: revert and reset.

Revert is a safe way to undo a commit without affecting the history of your repository. It creates a new commit that applies the opposite changes of the commit you want to revert. For example, if you added a line of code in a commit, reverting that commit will remove that line of code in a new commit.

To revert a commit in Git, you can use the git revert command followed by the ID of the commit. For example, to revert the last commit, you can run:

git revert HEAD

This will create a new commit with a message like “Revert ‘Added feature2 in development branch’”. You can also specify a custom message with the -m option.

Reset is a more dangerous way to undo changes in your repository. It moves your current branch pointer to a different commit and discards any changes that are not in that commit. For example, if you reset your branch to an earlier commit, any commits that came after that will be lost.

To reset your branch in Git, you can use the git reset command followed by the ID of the commit. For example, to reset your branch to the second last commit, you can run:

git reset HEAD~1

This will move your branch pointer to one commit before HEAD (the current commit). However, this will not affect your working directory or staging area. To also discard any changes in those areas, you can use the --hard option.

git reset --hard HEAD~1

This will reset your branch, your working directory, and your staging area to the second last commit. But be careful, as this will permanently delete any changes that are not in any other branch or backup.

🔀 Git Rebase and Merge 🔀

Rebase and merge are two ways to combine changes from different branches in Git. They both have their advantages and disadvantages, depending on the situation and preference.

Rebase is a way to rewrite the history of your branch by applying your changes on top of another branch. For example, if you have a dev branch that is behind the master branch, you can rebase your dev branch onto the master branch. This will make it look like you started working on the dev branch after the latest commit on the master branch.

To rebase your branch in Git, you can use the git rebase command followed by the name of the branch you want to rebase onto. For example, to rebase your dev branch onto the master branch, you can run:

git checkout dev
git rebase master

This will move your dev branch pointer to the same commit as the master branch pointer, and then apply your changes on top of that. This will create a linear history that is easier to follow and avoids merge conflicts.

However, rebase also has some drawbacks. It changes the history of your branch, which can cause problems if you have already pushed your branch to a remote repository or shared it with other developers. It can also lose some context and information about when and why you made certain changes.

Merge is a way to combine changes from different branches by creating a new commit that has both branches as its parents. For example, if you have a dev branch that has some new features and a master branch that has some bug fixes, you can merge your dev branch into the master branch. This will create a new commit that has both branches as its parents and contains all the changes from both branches.

To merge your branch in Git, you can use the git merge command followed by the name of the branch you want to merge into. For example, to merge your dev branch into the master branch, you can run:

git checkout master
git merge dev

This will create a new commit with a message like “Merge branch ‘dev’ into ‘master’. You can also specify a custom message with the -m option.

However, merge also has some drawbacks. It creates a non-linear history that can be harder to follow and debug. It can also cause merge conflicts if there are conflicting changes in both branches.

🚀As part of Day 10 tasks we will cover the following things

1. Switch to dev branch by this command git checkout -b dev
2. Add a text file called version01.txt inside the Devops/Git/ with “This is the first feature of our application” written inside.
3. version01.txt should reflect at the local repo first followed by the Remote repo for review.
4. Your commit message should be “Added new feature”.
   git commit -m "Added new feature”
5. We will use git push in order to reflect the local changes to the remote repository.

1. Add a new commit in dev branch after adding the below-mentioned content in Devops/Git/version01.txt: While writing the file make sure you write these lines
2. 1st line>> This is the bug fix in the development branch
3. Commit this with message “Added feature2 in development branch”
4. 2nd line>> This is gadbad code
5. Commit this with the message “Added feature3 in the development branch”
6. 3rd line>> This feature will gadbad everything from now.
7. Commit with the message “Added feature4 in the development branch”
8. Restore the file to a previous version where the content should be “This is the bug fix in the development branch”. We can use git revertor git reset

git log will show something like this

Conclusion

In this blog post, you learned some of the advanced skills and techniques for using Git and GitHub as a DevOps engineer.

You learned how to:

• Create and manage branches for different features and bug fixes
• Revert and reset your changes to a previous state
• Rebase and merge your branches to keep your history clean and avoid conflicts

I hope you enjoyed this blog post and learned something new. If you have any questions or feedback, feel free to leave a comment below or contact me on LinkedIn or GitHub. I would love to hear from you!

Thank you for reading and happy coding!

References

https://www.abtasty.com/blog/git-branching-strategies/

https://www.youtube.com/watch?v=NzjK9beT_CY

https://www.youtube.com/watch?v=7xhkEQS3dXw

https://www.simplilearn.com/git-rebase-vs-merge-article