 Version management with Git makes branching and merging much easier than old versioning systems such as SVM. This allows a wide variety of branching strategies and workflows that can get much more complex than the graph we were just looking at. Almost all of these are an improvement over the methods used before Git, but many organizations end up with a workflow that is not clearly defined, overly complex, or not integrated with issue tracking systems. Because of that, GitLab recommends a strategy for branching that we call GitLab Flow. In its simplest form, GitLab Flow consists of a master branch where all of the code we are going to deploy into production labs. From there, each developer can make a feature branch, a copy of that master branch, at any point in time where they start to make their changes. Merging everything into the master branch and deploying often means you minimize the amount of code in inventory, which is in line with the lean and continuous delivery best practices. But this flow still leaves a lot of questions unanswered regarding deployments, environments, releases, and integrations with issues. With GitLab Flow, we offer an additional guidance for these questions. First is merge requests. If you work on a feature branch for more than a few hours, it's good to share the immediate result with the rest of your team. You can at mention your teammates and mark the merge request as a work in progress or WIP. This means it's not ready to be merged, but feedback is welcome. Your team members can comment on the merge request in general or on specific lines with comments. The merge request serves as a code review tool and no separate tool should be needed. If the review reveals shortcomings, anyone can commit and push a fix. When you feel comfortable with it to be merged, you assign it to the person that knows the most about the code base or who is in charge of approving merges into the master branch. In old workflows, the continuous integration server commenting the ran tests on the master branch only. Developers had to ensure their code didn't break on the master branch. When using GitLab Flow, developers create their branches from the master branch so it is essential that it is green. Therefore, each merge request must be tested before it is accepted. The benefits of continuous integration are huge when automation plays an integral part of your workflow. GitLab comes with built-in continuous integration, continuous deployment, and continuous delivery systems built to support, build, test, and deploy your application. Merge conflicts can be very annoying for both the merge request author and reviewer. As an author, I just want my merge request to be merged. But the reviewer might not be in the same time zone as me, and by the time they review my changes, I might have a merge conflict. I then need to fix it and pass the merge request back to them, which is a lot of busy work for something that could be fairly trivial to fix. Similarly, as a reviewer, I want merge requests to be accepted when they're ready. I don't want to spend my time checking out the author's branch, fixing the conflicts, and pushing back. And I don't particularly like waiting around for them to fix it. As an author or reviewer, I just want to be able to have the merge request accepted and move on to the next problem. If you can't resolve merge conflicts within GitLab, that means that any merge request with a conflict needs to be checked out locally, resolved locally, pushed back, and then merged. That's a hassle and can't be done without having some Git tools installed locally. At GitLab, we want everyone to be able to collaborate on digital content, and that means not having to install special tools wherever possible. That's why we have built-in code review and conflict resolution inside of the GitLab UI. Remember, Git is your friend, and when something goes wrong, but you've embraced a Git workflow, Git can also be a magical time machine to help you figure out what went wrong. There are advanced Git commands that can let you pull back the changes that I've staged, or even revert the files back to the state they were before I started making any changes. I can also add to the last commit if I forgot to stage a particular change, or I can undo my previous commit, placing those changes back into my staging environment. Or if I've made a huge mistake, I can revert my previous commit, removing all of the changes I made. These tools, though advanced, mean Git can protect my source code from malicious or careless changes. This is one of the core reasons that so many enterprise developers choose Git as their source control management tool of choice. Thank you for taking the time to watch this GitLab training video. To learn more about Git, you can visit git-scm.com. Or to learn more about GitLab, you can visit about.gitlab.com.