Person: An important component of the overall LookML workflow is project version control. In this section, we will discuss how Looker integrates with Git for version control of LookML projects. Git is a widely used version control system for multiple programmers to collaborate on the same library of code. Through Looker's integration with Git, you can make and test changes locally, first in Looker's integrated development environment, or IDE, and then send your changes to the primary production environment after the changes have been tested locally. This version control process allows you to collaborate on one project with other developers who can receive your updates as well as share their updates with you. To understand how version control with Git works, it is helpful to think of the Git repository for a LookML project as a tree. New LookML code is always written in a branch of a tree. The main production code that is live would be the trunk of the tree, while each developer creates a branch from the trunk to create and test new objects such as dimensions, measures, explorers and more. After changes have been tested locally in a branch, the LookML developer can send the changes to the trunk or the production environment for the LookML project. After that point, other developers can pull changes from the trunk to the branches of the project. Git is commonly managed through a third-party provider such as GitHub, GitBucket or GitLab. To configure Git, you need a URL or connection string for the repository you would like to use. The Git configuration is typically completed by a Looker team lead or administrator and only has to be completed once per LookML project. The lead or administrator will set up the GitHub repository to allow write access from the LookML developers so that all of them can sync their changes to and from the primary production repository on GitHub. One key point that you need to know as a LookML developer is that when you enter development mode, Looker automatically creates a local branch for you to make and test changes. This branch can only be modified by you, though developers with access to the same project can view others' branches if they like. The Looker ID will always display which branch you are working on at the top of the page next to the project name. In this example, the project is training_ecommerce, and the personal branch is called dev. On the Git actions page, you can also view others' branches in read-only mode and even create new branches and even shared branches known as feature branches. You may want to create a new branch if you have only partially completed a large workflow on your branch, and you need to develop and deploy and unrelated change without sending all of your other code changes to the production environment. Shared branches are useful for allowing multiple developers to collaborate on the same version of code to implement a new feature or bug fix. The shared branch can easily be deleted once the collaboration is complete. Another key concept for developers to remember is that all changes made in development mode remain in the active development branch until they are pushed to production, so you can continue to make and test changes to LookML code in development mode without having to push your changes to production until you are ready. Depending on the settings configured by your administrator, you may have access to send your changes directly to production. While by default, LookML developers can merge and deploy their changes to production, Looker administrators can choose to restrict the deployment of changes to production by configuring projects to use pull requests using the configuration options on the project settings page. When pull requests are enabled, developers submit pull requests to notify others that they want to submit changes to the production code. Another team member, usually a lead or designated reviewer, reviews the pull requests in a Git provider such as GitHub.com, and if they approve the changes, they could choose to merge the changes to production. While you are working in your branch, you may decide that you no longer want to save the changes you have been making. Luckily, in the Looker IDE you can revert any changes made in development mode that have not been pushed to production by using the revert to options on the Git actions page. This action will undo all uncommitted changes so that you can start over with a clean branch that matches the latest production environment. In summary, when you enter development mode, Looker will automatically create a local branch for you to make and test changes. The branch that you are currently working in will always be displayed at the top of the Looker IDE. You can see additional information about your branch and access different options under the Git action page of the IDE. All changes made in development mode will remain in development mode until they are merged to production. Depending on the settings configured by your Looker admin, you may have permission to directly merge your changes to production, or you may have to submit a pull request for someone else to review and approve your changes. With this introduction to Looker's integration with Git, you are now ready to start using version control to manage your changes and collaborate with others in your organization's Looker instance.
