---

Over the next few slides I've prepared I will highlight the problems that GIT and by virtue GITFlow attemptes to solve. I am ignoring for the most part how merges happen and how-to solve conflicts, you can ready plenty on that and it will over-burden this explanation, whereby I am trying to highlight proper use of branching for development, release and code-review.

Imagine a world without SCM (source control management)

Everyone edits from one masive big dirty folder or dropbox or whatever hideous manifestaton it takes. Please ignore those shudders running down your body as we move past this rather insipid example. In this horrible little world developers have to make copies of the folders or acrhive them to a zip to (hopefully) snapshot the state of code at release. You'd think it's a joke, but I've heard of and seen it happen more than any of us would like to think possible.

Now let's assume the (almost) simplest possible use of GIT

We have a develop branch for in progress work, and a master branch for approved and release code (so we know where to deploy code from or look lines that error in live bug reports from users!).

Add in the ability to create numerous feature branches

Branches for everyone! Yes, now a developer can have his own branch just for his or her feature. We can toil away endlessly without fear of running into problems with other developers branches. I'm glossing over the fact you need to perform a re-base or (yuck, don't do it) merge when putting back into develop.

Sometimes there are emergencies that need fixing

That's right, everything will usually break in production at least one point, and you can't wait for a sprint or release to push it through - management wants it fixed now. So we create a hotfix as per below, and it gets subsumed back into master and our develop branch as well.

How can we improve the quality of code and collaboration we do?

Individual developers will usually have individual ideas of code style, and let's face it we all make errors or lack knowledge in certain areas from time to time. Getting a second pair of eyes looking over your code, which may often be a little more critical than we tend to be on our own work is a great way to ensure we don't even let things that are easily stopped get to QA (making developers look way better). It's also a chance for the senior developers to ensure conformity to code styling (which makes working together as a team much easier.

We're not getting ALOT of commits in our log!

This happens, you need to ensure that each feature (or task) is only generating a singular commit tracking what has changed and any task numbers against it to log. Otherwise finding problems and timelines will be a nightmare.