Welcome back, in this lecture we'll now dive into the details of how to use Atlassian BitBucket to create and manage a Git repository, and then review all of the associated BitBucket features you can perform within this repository. Within BitBucket you typically start by creating a new and empty Git repository, which you then later clone locally. Having completed this you then begin to populate your local working directory with your source code. Next you stage your source code into your staging or index area, followed by committing into the local repository. Finally, once you are ready to share your coding changes with the rest of the team you push your changes back up to the remote BitBucket cloud hosted repository also known as the origin. Creating a repository is very simple, within the BitBucket web admin console you click on the create repository option. You provide the repository name and specify the access level being public or private. By default the repository will be created using Git but you can change this to Mercurial. Additional options allow for the inclusion of a readme file, control over forking, integration with project management tools and specifying the main source code language as used within your software project. Having completed the creation of your BitBucket repository. 

You're presented with the next screen which helps you in terms of getting your new repository cloned locally, and then how to go about populating it. Later on in the course, we'll demonstrate this initial workflow. You can simply copy and run locally the HTTPS or SSH clone URL, which when executed will clone the repo. Within your BitBucket repository, you'll have immediate access to a number of features specific to this repository. Features are presented as menu items in the left-hand side menu and include each of the following. Source, commits, branches, pull requests, pipelines, downloads, boards and then finally settings. We'll cover off each feature in the coming slides. The source view allows you to view directly, the source code files within your repository. The source view presents the source code for a particular brand and in this case as seen here displays the master branch source code. When in the source view, you can never go down through the directory structure and then into any particular source code file, within the source code file itself you have the option to directly edit in line and commit back any changes. All without having to leave the web console itself. At the file level you can examine the source code as it was for any of the commits past or present.

 You can also examine the source code as is currently for any branch still being tracked. Finally within the source view you can perform a file diff on the selected version, and any other version of the same file. This can be very helpful to understand how a particular file has evolved between individual commits. The commits view allows you to quickly see all of the commit history across the entire repository. With this view you can also see the branching history illustrating both when a branch occurred and later on when the same branch is merged back. All commits are presented with the commit ID the associated commit message and when the commit actually took place. Finally, linkage is provided through the pipeline builds we'll cover pipeline builds later on in the course. Clicking on a commit ID will take you into a view that shows all of the files that contributed to a change within that commit with the difference or differences within each file highlighted. When it comes to branching with Git it is expected that you will branch and branch often. 

A branch in Git is simply a lightweight movable pointer to an existing commit. The default branch in Git is the master branch, branching is the norm within Git and shouldn't be feared, so get familiar with it early and do it as often as required. The branches view by default shows a listing of all active branches, the master branch is considered the main branch, branching first takes place off the main branch, but later branches can branch off of other branches. In this view as seen here the feature2 branch is three commits behind and one commit ahead. What this means is that since branching occurred, the master branch has been committed to three times and one commit has been made into the feature2 branch. Inside the branches view we can compare any two branches to determine which commits are missing and require to allow a merge to happen from the source branch into the destination branch. In this view the master branch is one commit behind the feature2 branch. Finally from within the branches view, new branches can be created and baselined off any existing branch. 

All you need to do is provide a new branch name and select the branch you want to derive from. Pull requests provide a convenient way for developers within a team to discuss and collaborate on proposed coding changes before they are merged and integrated into the master project. This feature is available within the BitBucket web console and provides the designated reviewers with a way to quickly visualize all coding changes. Both at the file and code line levels. The pull requests view allows you to create and manage pull requests. A pull request must specify both the source branch the target branch for the merge, and a title. Additionally you can provide a description, and who within the team should review the pull request. You can also automatically have the source branch closed off if the review is accepted and the merge is completed successfully. 

In this example a pull request is created to merge the feature3 branch back into the master branch. Once the pull request has been created, all designated reviewers will be notified via email and can then review the pull request within the BitBucket web console. Reviewing typically requires you to understand which files have changed and what the changes are within each file, reviewers can make comments either associated at the file level or directly in line with any file considered part of the merge. If the pull request is accepted then the approver can merge by clicking the Merge button. A merge strategy needs to be selected and the current options supported by BitBucket cloud are, one, merge commit using Git merge dash dash no dash if if. Two, squash using Git merge dash dash squash and three, fast forward using Git merge dash dash if dash only. 

Additional merge strategies are available in the on prem hosted versions of BitBucket. If the pull request merge is completed successfully then the pull request itself is tagged with the merged label as seen here, additionally, the designated reviewer can change the approval status on the pull request to approved, back within the pull requests main view you can filter by merge status, open, merged or declined. By author, and or by target branch. In this example, we are viewing all merged pull requests. The BitBucket pipelines feature provides a powerful and flexible CICD system for automating build and deployments of your software projects as mentioned earlier, you get 50 build minutes for free per month on the free version of BitBucket. The standard version increases up to 500 build minutes per month, and the premium version giving you 1,000 build minutes per month. Additional to any of these kits is the ability to purchase extra build time increments of $10 per month for 1,000 minutes. Having enabled pipelines within your repository then any time you commit and push into your BitBucket repo will result in an automated build being triggered. The build can be viewed in real time as can be seen here. The build when triggered will operate on the latest commit of the source code, internally the build system used by pipelines is based on using Docker containers. Setting up automated pipeline builds within your own repositories is as simple as creating a YAML file named BitBucket dash pipelines and hosting it in the root of your project. Having done this, then when next entering the pipelines view pipeline will recognize and parse the BitBucket dash pipelines file and if the parsing succeeds and all is well. You will be presented with an enable pipelines button which you need to click to complete the setup. After this, any new commit into the repo will result in a new pipelines build kicking off automatically. The declarative syntax for the BitBucket pipelines YAML file is very simple and uses YAML for form and structure. As already mentioned the BitBucket pipelines file is hosted in the root of the project and is checked and stored within the repo itself. To get up and running you will typically specify the branches that the build will activate on followed by a number of named build steps. 

Each build step then provides a script composed of any number of script statements. Additional configuration can be supplied within the build steps. For example, to use caching services and or the Docker Daemon as seen here. Again, the pipelines build system itself uses Docker under the hood. In this screenshot, the very first line within the BitBucket pipelines file specifies the Docker image that will be used to host and run the build sequence, you can actually download this Docker image locally and test your build commands in sequence locally. Doing so affords you a couple of beneficial things. Firstly, if the build process fails you have the ability to access the locally running Docker container providing you with the ability to troubleshoot. Secondly, by validating the build process locally you are conserving your allocated BitBucket pipeline build minutes. With BitBucket deployments you have the ability to either manually approve, then deploy, or just straight up automatically deploy the latest built and tested software deployment artifacts. Deployments uses the concept of environments and specifically supports the following three environments. Test, staging, and production which together with pipelines allows you to build and deploy environment specific software project functionality. BitBucket downloads simply allows you to upload arbitrary files for later download into an area that is associated to a repository. But is not part of the repository's commit history itself. Typically downloads is used in conjunction with pipelines to store deployment artifacts that have been produced as an output from a pipeline build. We'll give a demonstration of this later on. BitBucket boards provides a simple way to integrate your repositories with a Trello based board and in doing so provides you with another team collaboration tool for organizing and prioritizing your software projects. If you are unfamiliar with Trello, Trello is a popular collaboration tool. This allows you to quickly visualize the current status of your entire software project knowing whose working on what, and where something is within a process. 

Trello is very flexible and allows you to completely model your own processes to suit. To begin the integration process, simply click the connect to Trello button. Next, you have the option to provision an entirely new Trello board or simply select an existing board once the Trello board has being connected up with your BitBucket repository you then need to specify the default permissions for your BitBucket users. For example here we are allowing all team members within the existing repo write permission to join the Trello board. Assuming your access is granted into the Trello board you will be able to visualize and contribute to your software project processes as presented within the board model. Each BitBucket repository has its own set of repository specific settings. However, do keep in mind that there are two levels of setting within BitBucket. There are those configured at the individual repository level as well as a single set specified at the account level. We won't cover off all of the available settings in this course, many are self explanatory. However we will go over and demonstrate some of the more unfamiliar but nevertheless important ones. For our repository level settings we'll cover user and group access, branch permissions, webhooks, chat notifications and pipelines. Starting with the user and group access settings for a repository you are able to specify individual BitBucket users or BitBucket groups and assign them, read, write, or admin permissions. In doing so you will control who can do what within the current repository. Read permissions allows you to clone and view the repository code base but not write or update back to it. Write permissions extends on the read permissions by allowing you to push commits back into the repository, and admin extends on write by allowing you to perform full administration of the repository.

 Keep in mind that the permission structure here is configured at the repository level, inherits the permissions set and managed at the account level at the time of repository creation, permissions modified at the repository level after creation override those set at the account level. Branching permissions set down at the repository level allows you to control how branching and merging is performed and by who. Configuring branch permissions allows you to enforce particular branching workflows and prevent unintended errors such as deleting the master branch. In this example presented here all team members in the build and release group have write access to any feature branch as per the wildcarded feature branch name. But only the user Jeremy Cook can merge via a pull request. Additionally the user Jeremy Cook is the only individual who can write to the master branch. With webhooks you can perform integrations with other external systems. The basic process involves registering against one or several triggers, examples of triggers are repository push, repository fork, pull request created and or pull request merged. You supply a URL to which BitBucket will make an HTTP post request where the body of the request carries a payload of information regarding the event that fired the trigger. 

The payload is encapsulated using JSON on the receiving side you can parse this data and do whatever you want with it. Chat notifications allows you to set up and configure subscriptions which in turn allows you to configure Slack as a receiver of notifications about events that take place within your BitBucket repository. For example, you can have BitBucket tell Slack to message you that a commit has just been pushed into your repository, and specify the commit ID. Or that the associated pipeline build has just completed successfully. Pipeline settings simply allows you to activate the pipeline's functionality and provides a walkthrough approach to crafting the required BitBucket pipelines YAML file. The pipeline's view provides a number of preconfigured BitBucket pipelines YAML files, for various types of build and deployment activities such as building and deploying to the cloud, either using AWS, or GCP as examples. Okay that completes this lecture on managing BitBucket repositories. Later on in the course we'll provide several hands-on demonstrations of the various repository management activities we have just covered. But for now go ahead and close this lecture and we'll see you shortly in the next one.