Overview: Git and Looker

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

4 Likes

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

1 Like

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!

Thanks,
Jay

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.

Thanks,

Cheers

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?

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.

1 Like

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?

1 Like

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!