For information on using Git with Looker, see this page in our documentation.
Looker uses Git to manage version control of LookML files. This article will provide a brief overview of Git terms and the typical Git workflow in Looker. Read more about Git in Looker here.
###What is Git?
Git is a version control system that allows for many developers to edit a single set of code at once. In Looker, this means that multiple developers can make changes to LookML at the same time. Instead of simply saving changes to common code files, developers can save and test their changes in dev mode before committing and deploying them to the single production model. Git will merge these changes to ensure all of them make it into the final version.
###What are the main terms?
Commit - records a snapshot of all the files in your developer mode, with their changes
Deploy - sends your changes to production mode
Pull - fetches all files from production mode and merges them with the files in your developer mode
Merge - integrates changes from your developer mode and production mode. Git will usually do this automatically when you push changes to production
Merge conflict - occurs when Git cannot automatically merge changes between your developer mode and production. Read more here.
###What is the typical Git workflow in Looker?
Pull from Production
The first thing you want to do before you start developing is to Pull from Production. This retrieves the most recent files from production mode. While not strictly required, it is very useful and can help you avoid the need to resolve merge conflicts later. Looker will prompt you to Pull from Production if another developer has pushed changes since you last made changes.
Make any desired changes
Make the LookML changes you want to make! We have a walk-through of developing in Looker here.
Test your changes
In developer mode, saved changes are reflected in the Explore section and in saved Looks and Dashboards. The Look Validator can help make sure your LookML changes do not break any saved Looks or Dashboards. Test your changes before committing and pushing them to production!
After you have saved and tested your changes, Looker will prompt you Commit Changes. You will be asked to enter comments about the changes you are committing. Descriptive comments ensure easy troubleshooting later.
Pull from Production (not always necessary)
This step is only necessary if changes have been pushed to production by another developer since you last pulled. If this is the case, Looker will prompt you to Pull from Production.
This step will merge your changes with the production files to ensure there are no merge conflicts in your code. A merge conflict is when you and another developer have both made changes to the same code and Git does not know how to automatically merge them. Read about how to resolve merge conflicts here.
Deploy to Production (Push to Production prior to 3.20)
If there are no merge conflicts in your code, you can now Deploy to Production. This will make your changes visible to all users in production mode.
These are your best resources:
Hey! Is it possible to clone a looker repository? Even do pull requests?
You can set up pull requests in the Looker UI in the Project Settings panel, more on that here. As for cloning, I would recommend following this approach where you fork the repo to your own. Let us know if you have any questions.
@vincent for your fast and precise answer 🙂 I should have used the search 🙂