diff --git a/Maintainer-Guide.md b/Maintainer-Guide.md
index 9fd2c7b..abda47a 100644
--- a/Maintainer-Guide.md
+++ b/Maintainer-Guide.md
@@ -6,7 +6,7 @@ Every release requires the maintainer to:
 
 1. Rebase the downstream kernel patches
 2. Update the configuration
-3. Create a release branch and tags
+3. Create a release branch/tags
 
 Once that is done, the result can be imported into a dist-git repository and built in Koji.
 
@@ -16,10 +16,12 @@ The downstream kernel patches are in a branch called `ark-patches`. This branch
 
 The rebase consists of the following steps:
 
-1. Rebase the kernel patches: `git rebase <upstream-tag> ark-patches`.
-2. If a patch fails to apply and the fix is clear, go ahead and fix it. Otherwise, file an [issue](https://gitlab.com/cki-project/kernel-ark/issues) for each patch that does not apply with the commit hash and conflict details so it can be resolved later. 
-3. If rebasing onto a tag, create a branch for this revision of the kernel patches. This is useful when comparing the state of the patches between versions: ``git branch ark/patches/<upstream-tag> && git push upstream ark/patches/<upstream-tag>``.
-4. ``git push -f upstream ark-patches``
+1. Update master: `git checkout master && git reset --hard linus/master`
+2. Rebase the kernel patches: `git rebase master ark-patches`.
+3. If a patch fails to apply and the fix is clear, go ahead and fix it. Otherwise, file an [issue](https://gitlab.com/cki-project/kernel-ark/issues) for each patch that does not apply with the commit hash and conflict details so it can be resolved later. 
+4. If rebasing onto a tag, create a branch for this revision of the kernel patches. This is useful when comparing the state of the patches between versions: ``git branch ark/patches/<upstream-tag> && git push upstream ark/patches/<upstream-tag>``.
+5. `git push upstream master`
+6. `git push -f upstream ark-patches`
 
 ### Common Problems
 
@@ -46,25 +48,27 @@ An example of this is https://gitlab.com/cki-project/kernel-ark/merge_requests/9
 
 ## Configuration
 
-1. ``git checkout internal``
-2. ``git pull``
-3. ``git merge <upstream-tag>``
-4. ``make FLAVOR=fedora rh-configs-commit && make FLAVOR=rhel rh-configs-commit``
-5. ``git push upstream internal``
-6. ``./redhat/gen_config_patches.sh``
-7. Open a merge request for each branch created in step 6: ``git branch | grep configs/"$(date +%F)" | xargs git push -o merge_request.create -o merge_request.target=internal -o merge_request.remove_source_branch upstream``
+Once the patches are rebased, update the configuration branch:
+
+1. `git checkout internal`
+2. `git pull`
+3. `git merge master`
+4. `make FLAVOR=fedora rh-configs-commit && make FLAVOR=rhel rh-configs-commit`
+5. `git push upstream internal`
+6. `./redhat/gen_config_patches.sh`
+7. Open a merge request for each branch created in step 6 (if any): ``git branch | grep configs/"$(date +%F)" | xargs git push -o merge_request.create -o merge_request.target=internal -o merge_request.remove_source_branch upstream``
 
 ## Release branch
 
 Once the kernel patches and configuration have been updated for the new release, it's time to create the release branch:
 
-1. ``git checkout -b ark/<upstream-tag> ark/patches/<upstream-tag>``
-2. ``git merge internal``
-3. Ensure the branch can at least build the SRPM: ``make rh-srpm``
-4. ``touch localversion``
-5. ``make rh-release``
-6. ``make rh-release-tag``
-7. ``git push upstream <upstream-tag> ark/<upstream-tag> ark/patches/<upstream-tag> kernel-<version>-<release>``
+1. `git checkout -b ark/<upstream-tag> ark/patches/<upstream-tag>`
+2. `git merge internal`
+3. Ensure the branch can at least build the SRPM: `make rh-srpm`
+4. `touch localversion`
+5. `make rh-release`
+6. `make rh-release-tag`
+7. `git push upstream <upstream-tag> ark/<upstream-tag> ark/patches/<upstream-tag> kernel-<version>-<release>`
 8. `git checkout ark-latest && git reset --hard ark/<upstream-tag> && git push -f upstream ark-latest`