Autosave: 2023-04-06 14:30:22

DevOps/Git/Cherry_picking.md

@@ -15,21 +15,25 @@ Cherry-picking can sometimes result in conflicts, especially if the changes you'
 
 ## Syntax
 
-Suppose you have two branches: `main` and `feature`. You want to apply the changes from the commit with hash `abcdefg` from the `feature` branch to the `main` branch.
+Suppose you have two branches: `main` and `feature`. You want to apply the changes from the commit with hash `xyx` from the `main` branch to the `feature` branch.
 
-First, switch to the `main` branch:
+First, switch to the `feature` branch:
 
 ```
-git checkout main
+git checkout feature
 ```
 
-Next, cherry-pick the commit from the `feature` branch:
+Next, cherry-pick the commit from the `main` branch:
 
 ```
-git cherry-pick abcdefg
+git cherry-pick xyz
 ```
 
-This will apply the changes from the commit with hash `abcdefg` to the `main` branch.
+This will apply the changes from the commit with hash `xyz` from thee `main` branch to the `feature` branch. This will create a new SHA on `feature` (pqr) but the changes will be identical.
+
+![](/_img/cherry-pick.svg)
+
+The benefit is that you only take the select changes you want, you are not merging the whole `main` branch into feature.
 
 Note that you can also cherry-pick multiple commits by specifying their hashes separated by spaces:
 
@@ -37,6 +41,11 @@ Note that you can also cherry-pick multiple commits by specifying their hashes s
 git cherry-pick abcdefg hijklmn opqrst
 ```
 
+## Limitations
+
+- You don't have to just cherry-pick locally, you can also cherry-pick from a [remote tracking branch](/DevOps/Git/Remote_tracking_branches.md).
+- You cannot cherry-pick merge commits since these commits do not implement a set of changes, they are connecting commits.
+
 ## Use case
 
 The time when I have cherry-picked is when a commit has been reverted via GitHub. This typically happens on the `main` branch when breaking changes have been merged and we want to undo this by reverting back to the previous commit, from before the problematic commit was merged in.

DevOps/Git/Effective_logging_in_Git.md

@@ -0,0 +1,13 @@
+---
+categories:
+  - DevOps
+tags: [git, procedural]
+---
+
+# Effective logging in Git
+
+| Root command      | Variant      | Output                                                   |
+| ----------------- | ------------ | -------------------------------------------------------- |
+| `git log`         | filename.txt | List the commits that changed the given file             |
+| `git log --patch` | filename.txt | Show the diff changes for each commit for the given file |
+| `git log --patch` | null         | Show the diff changes for each commit for all files      |

DevOps/Git/Git_bisect.md

@@ -0,0 +1,25 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Bisect
+
+Bisect can be used to identify commits that introduce a bug or regression in our code.
+
+It is most useful for when we know there is a problem in the code and we know there was a point in the past where the bug did not exist. We can compare the two points and try to identify where things went wrong.
+
+We mark the last good revision and the first bad revision. Bisect will the reset the code to the midpoint between the good and bad versions and let you test it. You mark that as a good or bad version and then bisect repeats the process.
+
+![](/_img/git-bisect.svg)
+
+## Procedure
+
+```
+git bisect start
+
+git bisect good <SHA, tag, branch>
+
+git bisect bad <SHA, tag, branch>
+```

DevOps/Git/Rename_a_branch.md

@@ -1,7 +1,7 @@
 ---
 categories:
   - DevOps
-tags: [git]
+tags: [git, procedural]
 ---
 
 # Rename a branch

DevOps/Git/Reset_to_remote_version.md

@@ -1,7 +1,7 @@
 ---
 categories:
   - DevOps
-tags: [git]
+tags: [git, procedural]
 ---
 
 # Reset to remote version of a branch