Git Stash

Sometimes you want to switch branches, but you are working on an incomplete part of your current project. You don't want to make commit to half-done work. Git stashing allows you to do so. The git stash command enables you to switch branches without committing to the current branch.

The stash's meaning is "store something safely in a hidden place." The sense in Git is also the same for stash; Git temporarily saves your data safely without committing.

Stashing takes the messy state of your working directory and temporarily saves it for further use.

Syntax of stash: git stash

Some options with git stash are:

• Git Stash Save: In Git, the changes can be stashed with a message. To stash a change with a message. Command :

  $ git stash save <stash message>

• Git Stash List: To check the stored stashes. Command:

  $ git stash list

  The output will show all the stashes with indexing as stash@{0}: stash@{1}...

• Git Stash Apply: You can re-apply the changes that you just stashed by using the git stash command. To apply the commit, Command:

  $ git stash apply

• Git Stash Pop: Git allows the user to re-apply the previous commits by using the git stash pop command. The popping option removes the changes from the stash and applies them to your working file.

  The git stash pop command is quite similar to the git stash apply. The main difference between both of these commands is the stash pop command that deletes the stash from the stack after it is applied. Command :

  $ git stash pop

Git Cherry-pick:

Cherry-picking in Git stands for applying some commit from one branch into another branch. In case you made a mistake and committed a change into the wrong branch, but do not want to merge the whole branch. You can revert the commit and apply it on another branch.

The main motive of a cherry-pick is to apply the changes introduced by some existing commit. A cherry-pick looks at a previous commit in the repository history and update the changes that were part of that last commit to the current working tree. It can cause duplicate commits and some other scenarios where other merges are preferred instead of cherry-picking. It is in contrast with different ways such as merge and rebase commands.

Why Cherry-Pick

Suppose you are working with a team of developers on a medium to large-sized project. Some changes are proposed by another team member and you want to apply some of them to your main project, but not all. Managing the changes between several Git branches can become a complex task, and you don't want to merge a whole branch into another branch. You only need to pick one or two specific commits. To pick some changes to your main project branch from other branches is called cherry-picking.

Git Merge Conflict

Conflicts generally arise when two people have changed the same lines in a file, or if one developer deleted a file while another developer was modifying it. In these cases, Git cannot automatically determine what is correct. Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict. Git will mark the file as being conflicted and halt the merging process. It is then the developers' responsibility to resolve the conflict.

How to resolve merge conflicts

The most direct way to resolve a merge conflict is to edit the conflicted file. Open the file in your favorite editor. Simply remove all the conflict dividers and Once the file has been edited use the git add command to stage the new merged content, then commit the file.

Git will see that the conflict has been resolved and creates a new merge commit to finalize the merge.

Let's Do Some Tasks :)

Task 1

• Create a new branch and make some changes to it.

• Use git stash to save the changes without committing them.

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

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

  

  Switched to the dev branch then here also added some content and committed them. Then use git stash pop to bring back the stashed file. Then added the file and committed it.

  

  

  Task-02

  • In version01.txt of development, the branch adds the below lines after “This is the bug fix in the 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 the message “ Added feature2.1 in development branch”

    

    • Line4>> This is the advancement of the previous feature

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

      

      • Line5>> Feature 2 is completed and ready for release

        Commit this with message “ Feature2 completed”

        

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

Created a branch Production from the master branch. Then in Production try to rebase the dev branch in it.

Here I made some mistake(not sure) and a conflict occurred

Solved the conflict in the version01.txt file then added and committed the file, and rebase done.

Task-03

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

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

• Line5>>Added few more changes to make it more optimized.

• Commit: Optimized the feature

In the production branch cherry pick the mentioned commit id then add the content. Added the file followed by the commit command.

Thank You For Reading !!