Git branching strategies.

Every repository has a default branch; from it, multiple branches can be created. we can create a separate branch for the Dev team then we need their branch to work in then we can create a new branch called dev, this will help to protect the main codebase.

Later we can merge the branches using the merge command or rebase the branches using the rebase command.

Git revert/reset

Git revert.

We all have done this before but on different platforms, suppose you're editing data in an Excel file and you do something wrong and you want to go one step back or undo the changes you made, then ctrl+z will do it for us. Similarly in Git if we need to undo the changes we made we can do it with the git revert command.

suppose you have committed file1.txt, file2.txt, file3.txt, and file4.txt, and suddenly you realize that you did a bad commit for file3.txt(something was wrong in that file)

here if you want to revert the changes or commit of file3.txt, you can do it with the below command.

git revert <<commit id>>

Git reset.

below are the commits.

c1, c2, c3, c4, c5.

git reset <c2 commit id>

if we do reset at commit c2 then all the next commits i.e. c3 c4 c5 will be removed/deleted.

Merge vs Rebase

Merge

Git merge is a command that allows developers to merge Git branches while the logs of commits on branches remain intact.

The merge wording can be confusing because we have two methods of merging branches and one of those ways is called “merge,” even though both procedures do essentially the same thing.

Imagine this scenario: you've been working hard on your feature branch, making changes, fixing bugs, and adding new features. Now, it's time to bring all those changes together and merge them into the main branch for everyone to benefit from. That's where Git Merge comes into play!

Git Merge allows us to integrate changes from one branch into another, consolidating our work and ensuring that everyone is working with the latest and greatest version of the codebase. It's like assembling pieces of a puzzle to create a complete picture. 🧩

Here's a real-world scenario to illustrate the power of Git Merge:

Let's say you've been working on a feature branch called feature/user-authentication, and now it's time to merge your changes into the develop branch. Here's how you can do it:

1. Switch to the branch you want to merge into (e.g., develop) using git checkout develop.

2. Execute the merge command: git merge feature/user-authentication.

3. Resolve any merge conflicts if they arise. (Don't worry, it's all part of the process!)

4. Commit the merge changes, if necessary, and push them to the remote repository.

And just like that, your changes are seamlessly integrated into the main branch, and everyone can benefit from your hard work. It's collaboration at its finest! 🤝

Rebase

Git rebase is a command that lets users integrate changes from one branch to another, and the logs are modified once the action is complete. Git rebase was developed to overcome merging’s shortcomings, specifically regarding logs.

Imagine this scenario: you've been working on your feature branch for some time, making commits, and keeping your codebase clean and organized. Meanwhile, changes have been made to the main branch, and you want to incorporate those changes into your feature branch without creating a messy merge history. That's where Git Rebase comes into play!

Git Rebase allows you to reapply commits from one branch to another, essentially rewriting your branch's commit history. It's like rearranging the pieces of a puzzle to create a more coherent picture. 🧩

Here's a real-world scenario to illustrate how Git Rebase works:

Let's say you're working on a feature branch called feature/new-ui, and changes have been made to the main branch (main) since you started your work. You want to incorporate those changes into your feature branch before you finish your work. Here's how you can do it:

1. Switch to your feature branch: git checkout feature/new-ui.

2. Execute the rebase command: git rebase main.

3. Resolve any conflicts that may arise during the rebase process.

4. Once the rebase is complete, your feature branch will now include the latest changes from the main branch.

And just like that, your feature branch is up-to-date with the latest changes from the main branch, and you're ready to continue your work with a clean commit history. It's like giving your codebase a fresh coat of paint! 🎨

Git Rebase allows us to keep our commit history clean, streamline our development process, and ensure that our codebase remains cohesive and easy to understand.

cherry-pick/stashing

Cherry-pick

Imagine this scenario: you're working on a project with multiple feature branches, and each branch has its own set of commits. Now, let's say the big boss comes in and urgently needs a critical bug fix that you've already implemented and committed in one of the feature branches. Here's where git cherry-pick swoops in to save the day!

Cherry-picking allows you to pluck individual commits from one branch and apply them to another branch. It's like picking out the juiciest cherries from one tree and adding them to your pie. 🥧

Here's how it works in a real-world scenario:

Let's say we have two branches: feature/awesome-new-feature and hotfix/urgent-bug-fix. The bug fix we need is sitting pretty in the feature/awesome-new-feature branch.

1. Identify the commit hash of the bug fix commit using git log.

2. Switch to the hotfix/urgent-bug-fix branch using git checkout hotfix/urgent-bug-fix.

3. Cherry-pick the bug fix commit using git cherry-pick <commit-hash>.

Voila! The bug fix is now applied to your hotfix/urgent-bug-fix branch without bringing along the entire feature branch baggage. 🚀

This comes in handy when you need to apply specific changes across branches without merging entire branches. It keeps your codebase clean and avoids unnecessary conflicts or dependencies.

So next time you find yourself in a pickle (or should I say cherry-pick?), remember this handy little Git command. It might just save your day!

Happy cherry-picking! 🍒

Git stash

Picture this: you're knee-deep in code, making changes left and right, when suddenly, you realize you need to switch gears and work on something else. But wait, you're in the middle of something important, and you don't want to commit half-baked changes or lose your progress. Enter Git Stash!

Git Stash allows you to temporarily stash away your changes, leaving your working directory clean and allowing you to switch branches or work on something else with ease. It's like tidying up your workspace before diving into a new task. 🧹

Here's a real-world scenario to illustrate how Git Stashing can come to your rescue:

Let's say you're working on a feature branch called feature/login-page, and suddenly, you realize there's an urgent bug in the master branch that needs your immediate attention. Instead of committing your half-finished changes or risking losing them, you can stash them away and come back to them later.

Here's how you can do it:

1. Save your changes to the stash using git stash save "Your descriptive message here".

2. Switch to the master branch using git checkout master.

3. Fix the urgent bug.

4. Once done, switch back to your feature branch using git checkout feature/login-page.

5. Retrieve your stashed changes using git stash pop to apply them back to your working directory.

Voila! You're back to where you left off, with your changes intact and ready to pick up where you left off. No fuss, no mess. 🎉

Git Stashing is a handy tool for keeping your workflow organized and your codebase clean. It's like having a magic box where you can stash away your work-in-progress and retrieve it whenever you need it.

So next time you find yourself juggling multiple tasks or switching between branches, remember to stash away your changes. Your future self will thank you for it!

Happy Stashing! 🧹

Tasks for the day.

Task 1

Add a text file called version01.txt inside the Devops/Git/ with “This is first feature of our application” written inside. This should be in a branch coming from master, [hint try git checkout -b dev], swithch to dev branch ( Make sure your commit message will reflect as "Added new feature"). [Hint use your knowledge of creating branches and Git commit command]

• version01.txt should reflect at local repo first followed by Remote repo for review. [Hint use your knowledge of Git push and git pull commands here]

Add new commit in dev branch after adding below mentioned content in Devops/Git/version01.txt: While writing the file make sure you write these lines

• 1st line>> This is the bug fix in development branch

• Commit this with message “ Added feature2 in development branch”

• 2nd line>> This is gadbad code

• Commit this with message “ Added feature3 in development branch

• 3rd line>> This feature will gadbad everything from now.

• Commit with message “ Added feature4 in development branch

• 

Restore the file to a previous version where the content should be “This is the bug fix in the development branch” [Hint use git revert or reset according to your knowledge]

Let's take a commit ID from logs.

Here, we can revert any commit using the commit ID.

git revert <<commit id>> (It will open the editor tab where we need to specify the reason of revert)

git revert <<commit id>> --no-edit ( it will ignore the editor tab)

(you can revert the latest commit with the head option, head points the latest commit.)

git revert HEAD(it will revert the commit which head is pointing)

Note: To revert to earlier commits, use git revert HEAD~x (x being a number. 1 going back one more, 2 going back two more, etc.)

Task 2:

• Demonstrate the concept of branches with 2 or more branches with a screenshot.

• add some changes to dev the branch and merge that branch in master

• as a practice try git rebase too, and see what difference you get.

Let's create a new directory, initialize the repository and create two files in it.

Let's create another branch and create 2 files in it.

view the logs.

as we can see master is behind the two commits, Let's merge dev into master.

as we can now head is pointing same commit for master and dev.

---

Thank you for joining me on this journey into DevOps! Your curiosity is the driving force behind this exploration. If you found value in these insights, I'm thrilled! Keep the DevOps flame alive, and stay tuned for more exciting adventures in the world of technology. Happy Learning! 🚀✨"

"Closing the gap between us—let's connect and make our virtual bond stronger on social media!

Click on -Umesh Salunkhe