 Hello, my name is William. Let's learn today how teams can take advantage of GitLab Distributed Version Control and Collaboration. This is a distributed team. They have adopted GitLab, which allows for asynchronous collaborative work, supporting different patterns for source code management and integration. A regular day on this team can start with Parker, the architect. Using the issues board for planning work in GitLab, assigning it to the respective developers. Like in many regular days, Parker, the architect, can assign an issue to Devon, the developer. Here, Devon, the developer, can take advantage of local IDE and using GitLab plugin work on his own copy of the project. Here we can see that he has installed GitLab plugin where he can take a look of the issues that has been assigned to him, the merge request that he has opened, status of pipelines, and when he's done with his code, he can also start or create a merge request using the GitLab command from his local IDE. The merge request will take him to GitLab where he can describe the changes that he wants to make and also assign the merge request to some other developer and in addition to that, they can look to the approval rules that he has to go through in order to get his changes merged. In addition to local IDE, collaborative work can also be done using GitLab Web IDE, which allows using branching. Here, Devon, the developer, wants to work on the development branch and in the path to production, if he wants to merge his code, he will have to ask Sasha, the developer, the senior developer, to review his code before merging it. So Devon works on his code and once he is ready to commit, he will add a meaningful commit message and commit to the development branch, where we will see it will start a pipeline that will execute all the building and test the steps that have been previously defined and it will make this merge request available for Sasha to review. Now Sasha can start the code review. She can execute multi-inline review, add suggestions to the code, she can even add snippets of code that later Devon, if he agrees, he can apply the suggestion and make it part of his changes. Devon can apply the suggestions made by Sasha and submit his merge request. In addition, he could also start a discussion on the code review. All of these things again power on the same platform in GitLab. Alright, so once Devon is done applying the changes and with the suggestions and all the threats are resolved, he is ready to finally submit his merge request. Now, collaborative work also requires strict measurements for approvals without this being an obstacle to slow down teams. In this case, let's assume Sasha has created a merge request and as we can see here, there are different rules that have been activated, being one of them a security one. There must be a security scan that has to be successful in order for this merge request to be approved. In addition to that, there is also a code owners, the one that gets activated for specific persons or group, depending on the file extension that has been changed. In addition to the granular permissions and approval, here we can see that GitLab can adapt to different patterns to use branching effectively, be it a short-life branch that are frequently integrated, like this one that was created from a merge request, or environment branches, such as the ones using GitLab Flow. Click on this link for more information about GitLab Flow. Well, and what if Devon tries a Git push force? In GitLab, branches can be protected, forcing any change to be reviewed before it gets merged, keeping the code safe and protected. Async remote collaboration wouldn't be complete without proper documentation for each project. In GitLab, you can easily create wikis, add pages and version it, helping any new team member to jump straight to documentation and start contributing. Remember, this team is very distributed and GitLab has something for them. GitLab Geo allows for read-only mirrors of the main GitLab instance. Reducing this way, the time it will take to Sasha to clone and fetch large repos from the primary instance in the US. Distributed version control and collaboration are cornerstone for software development lifecycle. Capabilities described previously along with strict and granular permissions, such as merge approvals, code owners, security reviews, protected branches, and Geo make this step a solid foundation for the iterative process of building software and deploying to production. Stay tuned and let's continue learning at GitLab.