 Welcome to this Git and GIFS video, the series where we explain Git concepts using the universal language, GIFS. In this video we'll take a look at what is a branch? My name is Brendan O'Leary and you can reach me on Twitter at O'Leary Crew. So what are Git branches? Well, a branch is a version of a project's working tree. That is if we think of the project as it evolves over time, you create a branch for each set of changes that you make. This keeps each set of changes separate from each other, allowing changes to be made in parallel without affecting one another. Typically, there is a main branch that represents the canonical source. Traditionally, this branch is called master or main, but it can really be named anything. Develop, production, trunk, cute dogs, there's no limit based on Git, but it's typical to have one clear canonical branch. The way you typically start coding is to make your own branch. This is sometimes called a feature branch and can be named again anything. Typically folks will give it a descriptive name, maybe one that includes an issue or a bug number from your issue tracking system, like JIRA or GitLab. That issue number can help tie the changes in this branch back to the idea that started it. The branch is completely detached from the main branch we talked about earlier, so you can change whatever you like, make mistakes, commit them, push them up to your remote system for other people to help add their own thoughts or review them, and just generally do whatever you want without running the risk of breaking anything. Once you're happy with these changes, you can request to merge them back into the main branch. This is called a merge request or pull request and allows the maintainers or engineering lead to review the changes and what impact they will have on the main branch when merged. In this way, Git is basically a magical time machine, so it's able to combine any changes that have happened since you branched off the main branch into yours, unless you change the same line as someone else. In this case, you might have a merge conflict, but don't worry, we'll cover that in a future Git and GIFs video and I promise they aren't as scary as they seem. But what does this all look like in real life? Well, if you have a large enough project, you might have multiple engineers working on one problem or different features, thus most projects will have many branches at any one time with changes that may or may not impact one another. And the merge request or pull request is where the changes really impact production code. This is the chance to review the change, make sure it's up to your code standards, and also run all the continuous integration you want to to make sure that you haven't unknowingly caused an error or introduce a security flaw. There is a lot more to merging and branching in Git. It makes sense, that's kind of the whole point of Git. And many teams use Git in very different ways. That's the beauty and confusing part of the tool. They're one and the same. I would say that often in life we see that something's greatest strength is also its greatest weakness. But that's okay. We're going to cover a lot of these things in the future of Git and GIFs videos. Basically my plans for the rest of it looks like explain these things that are more complex use cases of Git with GIFs. So stay tuned and we'll talk about merge conflicts, different branching strategies, and different ways of looking at merging codes soon. Thanks for watching this video and as always please reach out to me at O'Leary Crew on Twitter if I can be of any help. Take care.