Okay welcome back. In this demonstration we're going to perform some branching on our repository and we'll do a pull request as well. Now as we go about doing our branching we're going to use a branching workflow referred to as a feature branch workflow. So let's begin. So the first thing we'll do is select an existing repository. We'll jump into the settings for this repository and we'll quickly review the user and group access for the repository. In the previous demonstration, we set up permissions. In here we can see the permissions as inherited by this repository. So we have a build and release group, who has admin permissions. We have a software devs group who has write permissions on the repository. And finally a testers group we has read only permissions. Now at the repository level we can override these permissions. For example, we could revoke admin on the build and release group. But we won't do that. Likewise for the testers we can improve their permissions by upgrading them to write. But again we won't do that. And also looking at the branch permissions under workflow we can see the permissions specifically for branching. Okay, back with the now terminal. We're going to create a new feature branch in our local repository. We do so by running the command, git branch Feature1. Okay, still within Terminal you can see that we're currently on the master branch. So to create our new feature we need to swap to our Feature1 branch. We do that by running git checkout Feature1. And so now you can see we've changed into that branch. Okay the next thing we're going to do is back within Visual Studio, is we'll change our small edit string within the index.html file and change it to Feature1 representing the Feature1 implementation. We'll jump back into the terminal, we'll do git status again and you can see that the index.html file as within the Feature1 branch has been modified. We can run our git diff on index.html and we can see quite clearly the differences. 

So we've replaced small edit with our Feature1 implementation. Okay we can then stage the change. Next we'll commit this into our local repository. Git commit. Give it a message, added feature1 implementation. And then finally we can push this feature branch up into our remote repository as held within Bitbucket. So we do so by running the command git push dash dash set upstream origin and we'll keep the same branch name, feature1. So you can see here that the push has been denied basically because our permissions aren't correct. Let's jump back into our repository and correct this. So within branch permissions we'll click on the existing permission and we'll edit it. And you'll see here Write Access, nobody has Write Access. So, I'll give Write Access to myself but I'll also give access to our software developers. Save. Go back to the terminal. And we'll rerun the last command. This time the new feature branch has successfully been pushed up to the remote origin. If we now go back into Bitbucket and we select branches and there we can see that the Feature1 branch now exists within our repository as held within Bitbucket. And that it's one commit ahead of master. We can select it. We can then jump into the first commit of this branch and we can see that we've added the feature1 implementation. Okay so from here, we'll now create a pull request, to merge our feature1 changes into the master branch. So we'll click on the create pull request. We'll update the title. At the top of the pull request are the two branches that we're going to merge. 

So on the left hand side is the source branch which is our feature1 branch. And on the right hand side is the destination branch and in this case it's going into master. We can give it a description. Implementation completed, please review and merge, thanks. We can specify a reviewer, in this case we won't worry about that and then we'll click the Create Pull Request button. And this will generate a pull request. So again, if we go into Pull Requests you can see a list of pull requests that have been created. So currently we're viewing all open ones. But we can change the filter to be showing pull requests that have been merged and pull requests that have been declined. So let's jump back into the existing pull request that we just created. If we scroll down we can review the files that have changed, in this case there's one changed file our index.html. And we can actually see the changes within. We can make comments at the file level. Interesting change, I like it. And we can also comment down at the line level. We could simply say, accepted, I like this change. And equally we could actually put a comment in there that requires them to make some edits, save. Now the final thing we can do is we can approve it. So I'll set to approved. And then the last thing in the sequence is to merge the change. So again in this case, we're going to merge from feature1 into master. And for our merge strategy we'll go with the default with is merge commit. Clicking Merge. So the merge is completed successfully as per the merge label up here. 

And again we can review the merging changes. The next thing we'll do within the terminal is we'll just cat out the contents of index.html and the feature1 branch. And again we can see our feature1 implementation exists as we expect it to. So the next thing we'll do, is we'll do git, checkout and we'll go back to the master branch. So we've swapped successfully over into the master branch in our local repository. And we'll cat out the contents of the same file. Just to see what you would expect. So now we're still seeing the implementation pre the feature1 update. So what do we need to do? Well, because we've merged it, but we've only merged it in the remote repository, we need to pull down these changes. So to get the latest changes, we simply write git, pull. And what this will do is this will sync the master branch with the master branch that we merged to up in remote repository within Bitbucket. And we'll do this locally. Here you can see the fast forward merge strategy has been used on the local repository in workspace. So now if we cat out the contents of index.html again we should see our feature1 implementation, which we do. Okay that's completed this demonstration on performing branching using a feature branch workflow and performing a pull request. Go ahead and close it and we'll see you shortly in the next one.