Git Stash:

Git stash is a powerful feature in Git that allows you to temporarily save changes in your working directory without committing them to the repository.
It's like putting aside your changes in a "stash" so that you can switch to a different branch, pull changes from a remote repository, or work on something else, and then later come back to your saved changes and continue working on them.
"Stash" basically, changes in a dirty working directory away.

Here is an example :

The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use, and then reverts them from your working copy.

Stashing your work :

$ git status
On branch main
Changes to be committed:

$ git stash


$ git status
On branch main
nothing to commit, working tree clean

Re-applying your stashed changes :

You can reapply previously stashed changes with git stash pop"
```
  $ git status
  #On branch main
  #nothing to commit, working tree clean
  $ git stash pop
  #On branch main
  #Changes to be committed:
```
Popping your stash removes the changes from your stash and reapplies them to your working copy.

Cherry-pick

Git cherry pick illo

git cherry-pick is a powerful command that enables Git commits to be picked by reference and appended to the current working HEAD.
Cherry picking is the act of picking a commit from a branch and applying it to another.
git cherry-pick can be useful for undoing changes.
For example, say a commit is accidentally made to the wrong branch.
You can switch to the correct branch and cherry-pick the commit to where it should belong.

When to use git cherry-pick

git cherry-pick is a useful tool but not always a best practice.

Cherry-picking can cause duplicate commits and in many scenarios where cherry-picking would work, traditional merges are preferred instead.

The basic syntax of git cherry-pick is as follows:

git cherry-pick <commit-hash>

Cherry-pick a Single Commit:

This command applies the changes introduced by the specified commit to the current branch.
```
  git cherry-pick <commit-hash>
```
Cherry-pick Multiple Commits:

You can cherry-pick multiple commits one after the other.
```
  git cherry-pick <commit-hash1> <commit-hash2> ...
```

Git Merge Conflicts

In Git, a merge conflict occurs when you attempt to merge two branches, and Git is unable to automatically combine the changes because both branches have made conflicting modifications to the same file(s) or lines within a file. When such conflicts arise, Git needs human intervention to resolve the differences manually.

Here is how to handle merge conflicts in Git:

Identify the Conflict:

When you attempt to merge two branches using Git merge, and Git encounters conflict, it will notify you about the conflicting files. You can identify these files by running git status, which will display a list of conflicted files under the "Unmerged paths" section.
Open the Conflicted File:

Open the conflicted file(s) using a text editor or a code editor. Inside the file, you will see Git's conflict markers, which look like this:
```
  <<<<<<< HEAD
  // Your changes on the current branch
  =======
  // Changes from the branch you are merging
  >>>>>>> branch-name
```
The section between <<<<<<< HEAD and ======= represents the changes made on the current branch (the branch you are merging into), and the section between ======= and >>>>>>> branch-name represents the changes from the branch you are merging (the branch being merged into the current branch).
Resolve the Conflict:

Manually edit the conflicted file to remove the conflict markers and decide which changes to keep. You may choose to keep the changes from one branch, combine the changes, or rewrite the content entirely.
Add the Resolved File:

After resolving the conflict, save the file, and then add it to the staging area using git add <file>.
Commit the Merge:

Once all conflicts are resolved and the resolved files are staged, commit the merge using git commit. The commit message will already be prepared for you, summarizing the merge.
Complete the Merge:

After committing the merge, you have successfully resolved the conflicts, and the branches are now merged.
Optional: Continue with Additional Conflicts:

If multiple files have conflicts, you will need to repeat the steps above for each conflicted file until all conflicts are resolved.

You can use git pull to pull changes and then proceed with the merge.

Task-01

Create a new branch and make some changes to it.

git checkout -b branch1
vim file3.txt
git status

Use git stash to save the changes without committing them.

git status
git add file3.txt
git stash

Switch to a different branch, make some changes and commit them.

git checkout -b dev
vim file4.txt
git add file4.txt
git status
git commit -m "file 4 added"

Use git stash pop to bring the changes back and apply them on top of the new commits.

git stash pop
git add file3.txt
git status
git commit -m " new commit on stash"

Task-02

In version01.txt of development branch add below lines after “This is the bug fix in development branch” that you added in Day10 and reverted to this commit.

vim version01.txt
git status
git branch 
#check the branch
git add version01.txt

Line2>> After bug fixing, this is the new feature with minor alteration”

Commit this with message “ Added feature2.1 in development branch”\

vim version01.txt
git status
git add version01.txt
git commit -m "Added feature2.1 in development branch"

Line3>> This is the advancement of previous feature

Commit this with message “ Added feature2.2 in development branch”

vim version01.txt
git status
git add version01.txt
git commit -m "Added feature2.2 in development branch"

Line4>> Feature 2 is completed and ready for release

Commit this with message “ Feature2 completed”

vim version01.txt
git status
git add version01.txt
git commit -m "Feature 2 completed"

All these commits messages should be reflected in Production branch too which will come out from Master branch (Hint: try rebase).

git checkout -b prod
  git rebase dev
  git log --oneline

Task-03

In Production branch Cherry pick Commit “Added feature2.2 in development branch” and added below lines in it:

git cherry-pick er65b7d

Line to be added after Line3>> This is the advancement of previous feature

vim version01.txt "This is the advancement of previous feature"
  git add version01.txt
  git commit -m "Advancement feature"

Line4>>Added few more changes to make it more optimized.

vim version01.txt "Added few more changes to make it more optimized"
  git add version01.txt
  git commit -m "Optimized the Feature"

Commit: Optimized the feature

If you find my blog valuable, I invite you to like, share, and join the discussion. Your feedback is immensely cherished as it fuels continuous improvement. Let's embark on this transformative DevOps adventure together! 🚀 #devops #90daysofdevops

Day 11 Task: Advance Git & GitHub for DevOps Engineers: Part-2

Table of contents