From f6d15ba4caab542c7d04e8a19c62ca6e53e43632 Mon Sep 17 00:00:00 2001
From: Ben Anderson <b.anderson@soton.ac.uk>
Date: Mon, 8 Jun 2020 14:21:56 +0100
Subject: [PATCH] Update gitBranches.md

---
 gitBranches.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitBranches.md b/gitBranches.md
index f4af431..e275512 100644
--- a/gitBranches.md
+++ b/gitBranches.md
@@ -6,7 +6,7 @@ You will have seen that git/github/gitlab repos have a `master` code base. You s
 
 Instead you should work inside a 'branch' of the code and when you have finished the code in the branch you should merge it back in via a pull request. That pull request is an opportunity for you and your team to quality-check or test your work _before_ merging it.
 
-For this reason branches should be small small things that fix or make a specific small contribution rather than a huge mass of changes. Once the work is done, merge the branch and start a new ine for a new task. This stops you from trying to fix 2 things in 1 branch and then realising you just want to merge 1 of them in to the master.
+For this reason branches should be small small things that fix or make a specific small contribution rather than a huge mass of changes. Once the work is done, merge the branch and start a new branch for a new task. This stops you trying to fix 2 things in 1 branch and then realising you just want to merge 1 of them in to the master.
 
 ## how
 
-- 
GitLab