diff --git a/DevOps/Git/.gitkeep b/DevOps/Git/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/DevOps/Git/Cherry_picking_a_branch.md b/DevOps/Git/Cherry_picking_a_branch.md
new file mode 100644
index 0000000..0006d63
--- /dev/null
+++ b/DevOps/Git/Cherry_picking_a_branch.md
@@ -0,0 +1,44 @@
+---
+categories:
+  - DevOps
+tags:
+  - git
+---
+
+# Cherry-picking a commit
+
+Cherry-picking is the act of selecting a specific commit or set of commits and applying them to a different branch. It allows you to extract a change or a series of changes from one branch and apply them to another branch without merging the entire branch.
+
+It can also be used to apply a series of commits that are not sequential in a branch to another branch in a specific order.
+
+Cherry-picking can sometimes result in conflicts, especially if the changes you're trying to apply conflict with changes in the destination branch. In such cases, you'll need to resolve the conflicts manually before completing the cherry-pick process.
+
+## 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.
+
+First, switch to the `main` branch:
+
+```
+git checkout main
+```
+
+Next, cherry-pick the commit from the `feature` branch:
+
+```
+git cherry-pick abcdefg
+```
+
+This will apply the changes from the commit with hash `abcdefg` to the `main` branch.
+
+Note that you can also cherry-pick multiple commits by specifying their hashes separated by spaces:
+
+```
+git cherry-pick abcdefg hijklmn opqrst
+```
+
+## 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.
+
+In this scenario, you will want to start from the reverted `main` branch and then cherry-pick the breaking commit. You can then fix the bug and keep an accurate record of the whole history.
diff --git a/DevOps/Git/Reset_to_remote_version.md b/DevOps/Git/Reset_to_remote_version.md
index d6c972e..e0e71f3 100644
--- a/DevOps/Git/Reset_to_remote_version.md
+++ b/DevOps/Git/Reset_to_remote_version.md
@@ -10,5 +10,5 @@ The scenario: your local Git history has become corrupted in some way and you wa
 
 ```
 git fetch origin
-git reset --hard origin/master
+git reset --hard origin/main
 ```
diff --git a/Programming_Languages/Shell/Capturing_user_input_in_Bash.md b/Programming_Languages/Shell/Capturing_user_input_in_Bash.md
index 58fc461..73a6d45 100644
--- a/Programming_Languages/Shell/Capturing_user_input_in_Bash.md
+++ b/Programming_Languages/Shell/Capturing_user_input_in_Bash.md
@@ -63,7 +63,32 @@ do
 done
 ```
 
-## Validating the user inputs
+## Ensuring you capture a valid response from the user
+
+### Set a default response value with `-i`
+
+If the user doesn't enter anything, the value will be set to the default.
+
+```sh
+read -ep "Favourite colour? " -i "blue" favecolour
+echo "$favecolour"
+# blue
+```
+
+Alternative formulation:
+
+```sh
+
+read -p "Favourite colour? [blue]" fave
+
+# If response empty...
+if [[ -z $fave ]]; then
+    fave="blue"
+fi
+echo "$fave was selected"
+```
+
+### Check right number of arguments supplied
 
 Here we test that the right number of [arguments](/Programming_Languages/Shell/Passing_arguments_and_options_to_Bash_scripts.md) have been passed to the script:
 
@@ -77,3 +102,16 @@ else
     echo "favourite number: $3"
 fi
 ```
+
+## Check the response is valid
+
+The following example demonstrates checking an input for a pattern (a data-link integer sequence):
+
+```sh
+read -p "Which year? [nnnn] " year
+until [[ $year =~ [0-9{4} ]];
+    read -p "A four-digit year, please! [nnnn] " year
+done
+echo "Selected year: $year"
+
+```