git reflog

Using the git reflog command should reveal Git's internal diary of all of the commits that HEAD has pointed to in your local repository—even the ones you thought were lost forever (assuming they weren’t old enough to have expired).

git whatchanged --since='2weeks ago'

Shows commit logs and diff output each commit introduces.

The git merge --squash command combines changes from one branch into another branch but does not create a merge commit. Step 1: Initialize project

git init

Step 2: create index.html file and 2 commit m1,m2 add text "m1" into index.html and commit as m1

echo "m1" > index.html
git add .
git commit -m "m1" 

add text "m2" into index.html and commit as m2

echo "m2" >> index.html
git add .
git commit -m "m2" 

Step 3: create feature branch and checkout

git checkout -b feature

Step 4: create feature folder&file create feature.html into the feature folder and add text "f1" then commit as f1

echo "f1" >> feature/feature.html
git add .
git commit -m "f1" 

Step 5: Checkout to master

git checkout master

Step 6: add text "m3" into index.html and commit as m3

echo "m3" >> index.html
git add .
git commit -m "m3" 

Step 7: Checkout to feature

git checkout feature

Step 8: add text "f2" into feature.html and commit as f2

echo "f1" >> feature/feature.html
git add .
git commit -m "f2" 

Step 9: Checkout to master

git checkout master

Step 10: Merge feature branch into master with squash

git merge --squash feature

Step 11: See git status because files we will have into the staging area and we need create a commit for it

git status
git commit -m "Merge feature branch into master"

The git rebase command moves or combines a sequence of commits from one branch onto another branch. Step 1: Initialize project

git init

Step 2: create index.html file and 2 commit m1,m2 add text "m1" into index.html and commit as m1

echo "m1" > index.html
git add .
git commit -m "m1" 

add text "m2" into index.html and commit as m2

echo "m2" >> index.html
git add .
git commit -m "m2" 

Step 3: create feature branch and checkout

git checkout -b feature

Step 4: create feature folder&file add text "f1" into feature.html and commit as f1

echo "f1" >> feature.html
git add .
git commit -m "f1" 

Step 5: Checkout to master

git checkout master

Step 6: add text "m3" into index.html and commit as m3

echo "m3" >> index.html
git add .
git commit -m "m3" 

Step 7: Checkout to feature

git checkout feature

Step 8: rebase master branch into feature

git rebase master

Step 8: add text "f2" into feature.html and commit as f2

echo "f2" >> feature.html
git add .
git commit -m "f2" 

Step 9: Checkout to master

git checkout master

Step 10: Merge the feature branch into master

git rebase feature

The git merge command combines changes from one branch into another branch and creates a new "merge commit" that represents the merge. Step 1: Initialize project

git init

Step 2: create index.html file and 2 commit m1,m2 add text "m1" into index.html and commit as m1

echo "m1" > index.html
git add .
git commit -m "m1" 

add text "m2" into index.html and commit as m2

echo "m2" >> index.html
git add .
git commit -m "m2" 

Step 3: create feature branch and checkout

git checkout -b feature

Step 4: create feature folder&file create feature.html into the feature folder and add text "f1" then commit as f1

echo "f1" >> feature/feature.html
git add .
git commit -m "f1" 

Step 5: Checkout to master

git checkout master

Step 6: add text "m3" into index.html and commit as m3

echo "m3" >> index.html
git add .
git commit -m "m3" 

Step 7: Checkout to feature

git checkout feature

Step 8: add text "f2" into feature.html and commit as f2

echo "f1" >> feature/feature.html
git add .
git commit -m "f2" 

Step 9: Checkout to master

git checkout master

Step 10: Merge the feature branch into master

git merge feature

as the result, we will get a new commit

 Merge branch 'feature'  

Displays the

author and last commit information

for each line in a file, helping track the origin of changes. Create a file and add some content:

echo "Line 1" > myfile.txt
echo "Line 2" >> myfile.txt
echo "Line 3" >> myfile.txt

Add and commit the file:

git add myfile.txt
git commit -m "Initial commit"

Make changes to the file and commit them

Make changes to the file and commit them

git blame myfile.txt

02fa3e76 (Luka 2023-06-01 20:07:40 +0400 1) Line 1
02fa3e76 (Luka 2023-06-01 20:07:40 +0400 2) Line 2
02fa3e76 (Luka 2023-06-01 20:07:40 +0400 3) Line 3
91354ada (Luka 2023-06-01 20:08:10 +0400 4) Line 4
91354ada (Luka 2023-06-01 20:08:10 +0400 5) Line 4
7ba66ba6 (Luka 2023-06-01 20:08:23 +0400 6) Line 5

Reverts the changes made in a specific commit by creating a new commit that undoes those changes.

echo "This is the initial content." > myfile.txt

add and commit file

git add myfile.txt
git commit -m "Initial commit"

make changes

echo "This is the modified content." > myfile.txt
git add myfile.txt
git commit -m "Modified myfile.txt"

revert last commit

git revert HEAD

or we can use specifying with the commit ID

git revert 4c04ecc

git log will return

 Revert "added file 4" --- Commit name

    This reverts commit 4c04eccff32e195ac0df17b1543f7f81de32d938. --- Commit id

"git grep "example" git grep command allows you to search for specific patterns within your Git repository This command will search for the word "example" in all tracked files in your repository and display the file names and the lines where the word is found. Example: Create files

echo "This is an example file" > file1.txt
echo "Another example file" > file2.txt

Add the files

git add file1.txt file2.txt
git commit -m "Initial commit"

Search for the word "example"

git grep "example"

Use a regular expression to search for words starting with "ex":

git grep "ex\w*"

Perform a case-insensitive search for the word "example":

git grep -i "example"

Git cherry-pick is a powerful command that enables arbitrary 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 accidently 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 many scenarios where cherry picking would work, traditional merges are preferred instead. With that said git cherry-pick is a handy tool for a few scenarios...

Team collaboration.

Often times a team will find individual members working in or around the same code. Maybe a new product feature has a backend and frontend component. There may be some shared code between to two product sectors. Maybe the backend developer creates a data structure that the frontend will also need to utilize. The frontend developer could use git cherry-pick to pick the commit in which this hypothetical data structure was created. This pick would enable the frontend developer to continue progress on their side of the project.

Bug hotfixes

When a bug is discovered it is important to deliver a fix to end users as quickly as possible. For an example scenario,say a developer has started work on a new feature. During that new feature development they identify a pre-existing bug. The developer creates an explicit commit patching this bug. This new patch commit can be cherry-picked directly to the main branch to fix the bug before it effects more users.

Undoing changes and restoring lost commits

Sometimes a feature branch may go stale and not get merged into main. Sometimes a pull request might get closed without merging. Git never loses those commits and through commands like git log and git reflog they can be found and cherry picked back to life.

How to use git cherry pick

To demonstrate how to use git cherry-pick let us assume we have a repository with the following branch state:
o demonstrate how to use git cherry-pick let us assume we have a repository with the following branch state:

    a - b - c - d   Main
         \
           e - f - g Feature
git cherry-pick usage is straight forward and can be executed like:

git cherry-pick commitSha
In this example commitSha is a commit reference. You can find a commit reference by using git log. In this example we have constructed lets say we wanted to use commit `f` in main. First we ensure that we are working on the main branch.

git checkout main
Then we execute the cherry-pick with the following command:

git cherry-pick f
Once executed our Git history will look like:

    a - b - c - d - f   Main
         \
           e - f - g Feature
The f commit has been successfully picked into the main branch

Examples of git cherry pick

 git cherry pick can also be passed some execution options.

-edit
Passing the -edit option will cause git to prompt for a commit message before applying the cherry-pick operation

--no-commit
The --no-commit option will execute the cherry pick but instead of making a new commit it will move the contents of the target commit into the working directory of the current branch.

--signoff
The --signoff option will add a 'signoff' signature line to the end of the cherry-pick commit message

In addition to these helpful options git cherry-pick also accepts a variety of merge strategy options. Learn more about these options at the git merge strategies documentation.

Additionally, git cherry-pick also accepts option input for merge conflict resolution, this includes options: --abort --continue and --quit this options are covered more in depth with regards to git merge and git rebase.

Summary

Cherry picking is a powerful and convenient command that is incredibly useful in a few scenarios. Cherry picking should not be misused in place of git merge or git rebase. The git log command is required to help find commits to cherry pick.

Git stash - temporarily shelves (or stashes) changes you've made to your working copy so you can work on something else, and then come back and re-apply them later on. Stashing is handy if you need to quickly switch context and work on something else, but you're mid-way through a code change and aren't quite ready to commit.

Stashing your work

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. At this point you're free to make changes, create new commits, switch branches, and perform any other Git operations; then come back and re-apply your stash when you're ready. Note that the stash is local to your Git repository; stashes are not transferred to the server when you push. Re-applying your stashed changes You can reapply previously stashed changes with git stash pop Popping your stash removes the changes from your stash and reapplies them to your working copy. Alternatively, you can reapply the changes to your working copy and keep them in your stash with git stash apply. This is useful if you want to apply the same stashed changes to multiple branches. Now that you know the basics of stashing, there is one caveat with

git stash 

you need to be aware of: by default Git won't stash changes made to untracked or ignored files. Stashing untracked or ignored files By default, running git stash will stash: changes that have been added to your index (staged changes)changes made to files that are currently tracked by Git (unstaged changes) But it will not stash: new files in your working copy that have not yet been staged, files that have been ignored. So if we add a third file to our example above, but don't stage it (i.e. we don't run

git add

),

git stash

won't stash it. Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files. You can include changes to ignored files as well by passing the -a option (or --all) when running

git stash.

Managing multiple stashes You aren't limited to a single stash. You can run

git stash

several times to create multiple stashes, and then use git stash list to view them. By default, stashes are identified simply as a "WIP" – work in progress – on top of the branch and commit that you created the stash from. After a while it can be difficult to remember what each stash contains. To provide a bit more context, it's good practice to annotate your stashes with a description, using git stash save "message" By default, git stash pop will re-apply the most recently created stash: stash@{0} You can choose which stash to re-apply by passing its identifier as the last argument, for example: git stash pop stash@{2} Viewing stash diffs You can view a summary of a stash with git stash show Or pass the

-p

` option (or --patch)to view the full diff of a stash.

Creating a branch from your stash

If the changes on your branch diverge from the changes in your stash, you may run into conflicts when popping or applying your stash. Instead, you can use git stash branch to create a new branch to apply your stashed changes to.This checks out a new branch based on the commit that you created your stash from, and then pops your stashed changes onto it. Cleaning up your stash If you decide you no longer need a particular stash, you can delete it with git stash drop. For example : git stash drop stash@{1}. Or you can delete all of your stashes with: git stash clear