Overview: Git and Looker

Userlevel 4

For information on using Git with Looker, see this page in our documentation.

Looker integrates with Git services (e.g. GitHub, GitLab, Bitbucket, Phabricator Diffusion) for LookML source code management. Each LookML project corresponds with a Git repository. Looker uses Git to record changes and manage file versions.

Starting in 3.20, we have changed the workflow behind the scenes for LookML code deployments to include developer branches as described below:

  • Each user’s developer mode now correlates to a branch

  • Commit Changes will sync changes with Git service

  • Deploy to Production will update production environment by merging that branch to master

12 replies

Is it possible to point production to a different branch, like release branch, than master?

Userlevel 2

Hey @Y_Duan,

It is not currently possible to point production to a branch other than master, but this is an option that the product team is looking into adding. I will let them know you are looking forward to having that option!

Hi @ryan.dunlavy,

Has there been any update on this?

Hi Far,

There is no definitive timeline set on this request as of yet but I can see Friartuck’s interest in this feature has been mentioned in the request to the product guys. We will let you know if the status changes!



Hello guys,

Any news about the ability to point production to a different branch than master ?

It would be great to unlink production version from master and merge master to production only when needed.



Userlevel 7
Badge +1

That feature request is being tracked here: Set Production branch to something other than master.

@yuriy has also posted a clever workaround in that thread, check it out.

I am in the process of moving our repo from Looker’s Git repo to our own company’s hosted Bitbucket instance. Is it best practice to start with an empty repo or can I use an existing one? Does having other files in the repo cause an issue for Looker? For instance, can I have my own DB scripts that create the Looker and Looker PDT users/permissions in the same repo that Looker uses for its LookML?

Userlevel 7
Badge +1

This part sounds like a bad idea, to me. Looker will try to read in anything from that repo into its IDE, and I know it only supports some file types. I’m not sure if it’d totally ignore some files, or what, but this sounds like a recipe for a broken git configuration.

We have a neat help center article that talks specifically about migrating:

The upshot is that yeah, if you just reset the git connection and point it at a new repo, it will clone all of that LookML over to the new repo. And yeah, I’d say it’s a best practice to have that new repo be empty— Although I don’t think it would break anything outright.

Userlevel 7
Badge +1

Just gave it a little test, and everything seemed to work okay— But my gut is still telling me that if you end up hitting the deploy webhook or something, things might break.

Anyone have a more conclusive answer?

Izzy, I agree it’s probably best practice to just start with an empty repo. No need to introduce unnecessary complexity. I’ll keep my non-core Looker code in a separate repo. Thanks!

Is there away to programmatically push changes to production?

Userlevel 7
Badge +1

I don’t believe we have any API endpoints that actually manage git flows— But all of that could be handled programmatically via github APIs (or, just git on the command line, which I think would be the easiest thing to do).

I think you’d need access to the box running Looker in order to do this, so unless you’re self-hosted, you may not be able to do this.

Note that if you make changes to your git repo outside of Looker, you’ll need to hit the deploy webhook to sync things up:

If you explain more about your desired workflow, someone here might be able to provide more advice!