Advance Git & GitHub for DevOps Engineers: Part-2

what is Git Stash?

Git stash is a command in Git that allows you to temporarily save changes that are not yet ready to be committed. This is useful when you are in the middle of working on a feature branch, for example, and need to switch to a different branch to fix a bug or work on another feature.

When you run the?git stash?command, Git will save your changes and revert your working directory to the state it was in when you last committed. This allows you to switch to another branch or perform other Git operations without the changes you've made getting in the way.

You can later retrieve your saved changes using the?git stash apply?command. This will restore your saved changes to your working directory, allowing you to continue where you left off. You can also use other?git stash?commands to manage your saved changes, such as?git stash list?to view a list of your saved stashes, and?git stash drop?to remove a saved stash.

what is Cherry-pick?

Cherry-pick is a command in Git that allows you to apply a specific commit from one branch to another branch. Essentially, it allows you to "pick" a commit from one branch and "cherry-pick" it onto another branch, as if you had made the changes directly on that branch.

The?git cherry-pick?command works by creating a new commit in the current branch that applies the changes made in the specified commit. This new commit will have a different commit hash than the original commit, but will contain the same changes.

Cherry-picking can be useful in situations where you want to apply a specific change from one branch to another branch without merging the entire branch. For example, if you have a bug fix in a feature branch that you want to apply to your main branch, you can use cherry-pick to apply only the bug fix commit to the main branch.

It's important to note that cherry-picking can sometimes result in conflicts if the changes made in the cherry-picked commit conflict with changes in the target branch. In these cases, you may need to manually resolve the conflicts before committing the changes.

what is Conflicts and how can we resolve Conflicts?

In Git, conflicts occur when there are conflicting changes made to the same file or files in different branches or commits. This can happen when two or more people are working on the same project at the same time, or when you are working on different branches or commits and you try to merge or apply changes.

When a conflict occurs, Git will notify you of the conflict and mark the conflicting lines in the affected file or files. You will need to manually resolve the conflict by choosing which changes to keep and which changes to discard.

Here are the general steps to resolve conflicts in Git:

1. Use the?git status?command to identify which files have conflicts.
2. Open each file with conflicts in a text editor and search for the conflict markers. These markers show the conflicting changes and where they are located.
3. Edit the file to remove the conflict markers and choose which changes to keep and which to discard. You can also make additional changes if necessary.
4. Save the file and add it to the staging area using the?git add?command.
5. Use the?git commit?command to commit the changes.

Alternatively, you can use a Git GUI tool to resolve conflicts. These tools provide a visual representation of the conflicts and allow you to easily select which changes to keep and which to discard.

It's important to carefully review and test your changes after resolving conflicts to ensure that the code is functioning as intended.

Create a new branch and make some changes to it.

git checkout -b new-branc
# make some changes to the files in this branch
git add .
git commit -m "made some changes to new-branch"        

Use git stash to save the changes without committing them.

git stash        

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

git checkout main
# make some changes to the files in this branch
git add .
git commit -m "made some changes to main"        

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

git checkout new-branch
git stash pop
# resolve any conflicts if necessary
git add .
git commit -m "applied changes from stash"        

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.

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

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

• Checkout to the?development?branch:

git checkout development         

• Open the file?version01.txt?in a text editor and add the following lines after the line "This is the bug fix in development branch" that was added in Day10 and then reverted:

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

• Stage and commit the changes with the message "Added feature2.1 in development branch":

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”

• Add the next feature by adding the following line after the previous one:

This is the advancement of previous feature         

• Stage and commit the changes with the message "Added feature2.2 in development branch":

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”

• Add the last line to complete the feature by adding the following line after the previous one:

Feature 2 is completed and ready for release         

• Stage and commit the changes with the message "Feature2 completed":

git add version01.txt 
git commit -m "Feature2 completed"        

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

• Switch to the?production?branch and merge the?development?branch with?--no-ff?option to preserve the commit history:

git checkout production git merge --no-ff development         

1. Checkout to the?master?branch and rebase it with the?production?branch to include the new commits from the?development?branch:

git checkout master 
git rebase production         

Now, the commits made in the?development?branch are also reflected in the?production?branch, which in turn is merged with the?master?branch using rebase.