diff --git a/README.md b/README.md
index f42e759..0d78d1b 100644
--- a/README.md
+++ b/README.md
@@ -32,7 +32,7 @@ flowchart TD
 
 When working with other developers you're all going to be cloning and pulling the code fromt he rmeote repository to start with and then committing and pushing your changes back. Now this is where it can get messy. Let's say theres a file called **header.html** in your repository and you and another developer change that file and push it back to remote repository. This could end up in whats known as a **merge conflict**. Basically you have both created a different version of the file from the initial clone so what happens now? Which one should be the one stored. Well this is where git is really clever. It accept the first persons commit and push without issues, the second person however will be notified of the conflict and be presented with some options. They will be asked to review the file locally and will be given a version of **header.html** that contains a diff showing both users contributions. You can then resolve this conflict by creating a merged version of both of your files or accept their changes or your changes only.
 
-The way to read the merge conflict is to look in the file(s) affected and look for the merge markers **<<<<<<<**, **=======** and **>>>>>>>** which highlights the conflicting sections. You decide which changes to keep, remove or modify and save the file.
+The way to read the merge conflict is to look in the file(s) affected and look for the merge markers ```<<<<<<<```, ```=======``` and ```>>>>>>>``` which highlights the conflicting sections. You decide which changes to keep, remove or modify and save the file.
 
 A good way to minimise this happening to you is to frequently run ```git pull``` in your working directory to keep up to date with others work, however, whilst this works for small teams larger teams will want to consider something more robust so they don't keep tripping over each other. This is where branches come in!
 
@@ -406,4 +406,4 @@ Now you're all ready to get started with learning how to use Git.
 ---
 ##### Follow me for more guides
 
-[<img src="./img/mastodon.png" width="10%">](https://awscommunity.social/@Ric)[<img src="./img/linkedin.png" width="6.5%">](https://www.linkedin.com/in/richarvey/)
\ No newline at end of file
+[<img src="./img/mastodon.png" width="8%">](https://awscommunity.social/@Ric)[<img src="./img/linkedin.png" width="5%">](https://www.linkedin.com/in/richarvey/)
\ No newline at end of file
diff --git a/cheat-sheet.md b/cheat-sheet.md
new file mode 100644
index 0000000..7ee8954
--- /dev/null
+++ b/cheat-sheet.md
@@ -0,0 +1,56 @@
+## Git Cheatsheet
+
+```
+# Clone a Repository
+git clone <repository_url>
+
+# Stage Changes for Commit
+git add <file(s)>
+
+# Commit Changes
+git commit -m "Commit message"
+
+# Push Changes to the Remote Repository
+git push
+
+# Force Push Changes (use with caution)
+git push --force
+
+# Reset Working Directory to Last Commit
+git reset --hard
+
+# Create a New Branch
+git branch <branch_name>
+
+# Switch to a Different Branch
+git checkout <branch_name>
+
+# Merge Changes from Another Branch
+git merge <branch_name>
+
+# Rebase Changes onto Another Branch (use with caution)
+git rebase <base_branch>
+
+# View Status of Working Directory
+git status
+
+# View Commit History
+git log
+
+# Undo Last Commit (use with caution)
+git reset --soft HEAD^
+
+# Discard Changes in Working Directory
+git restore <file(s)>
+
+# Retrieve Lost Commit References
+git reflog
+
+# Interactive Rebase to Rearrange Commits
+git rebase --interactive HEAD~3
+```
+
+---
+##### Follow me for more guides
+
+[<img src="./img/mastodon.png" width="8%">](https://awscommunity.social/@Ric)[<img src="./img/linkedin.png" width="5%">](https://www.linkedin.com/in/richarvey/)
\ No newline at end of file
diff --git a/commit.md b/commit.md
new file mode 100644
index 0000000..bd7757c
--- /dev/null
+++ b/commit.md
@@ -0,0 +1,27 @@
+## Working with commits
+
+When working with commits, utilize git commit -m to record changes, git amend to modify the most recent commit, and try your best to adhere to commit message conventions.
+
+```
+# Make sure to add a message to each commit
+git commit -m "meaningful message"
+```
+
+If you have changes to your last commit, you don’t have to create another commit altogether, you can use the - — amend flag to amend the most recent commit with your staged changes
+
+```
+# make your changes
+git add .
+git commit --amend
+# This will open your default text editor to modify the commit message if needed.
+git push origin your_branch --force
+```
+
+> Exercise caution when utilizing --force, as it has the potential to overwrite the history of the target branch. Its application on the main/master branch should be generally avoided.
+
+As a rule of thumb it’s better to commit more often than not, to avoid losing progress or accidentally resetting the unstaged changes. One can rewrite the history afterward by squashing multiple commits or doing an interactive rebase.
+
+Use git log to show a chronological list of commits, starting from the most recent commit and working backward in time
+
+### Sync Commits
+