At Looker, we place a high priority on making LookML development easy, efficient, and effective for analysts.
This idea - along with a strong support of coding best practices for collaboration - is grounded in Looker’s powerful integration with Git.
With the launch of Looker 5, this integration has grown even more powerful with the introduction of Git Branches in Looker.
Looker and Git
Developed by software engineer Linus Torvalds in 2005, Git was intended to help manage large code bases with multiple collaborators and has seen worldwide adoption since then.
Git at its core is version control, which is an absolute requirement for all development as it allows tasks that are critical to writing efficient performant code, such as:
- Test uncommitted code in a development sandbox without affecting production code.
- Allow others to view and refine uncommitted code before it’s pushed to production.
- Manage multiple separate additions to the code base, before pushing out production.
LookML centralizes SQL logic in one place and allows analysts to collaborate on a single codebase, a workflow much closer to that of a software developer’s and one that is perfectly suited for a tool like Git.
Before Looker 5, Looker’s version control capabilities gave analysts the ability to test out new additions to explores and LookML dashboards before making those changes available to everyone else.
But it was a clunky process to view uncommitted code that other developers were working on, and there wasn’t really a way for a single developer to manage multiple additions to the model simultaneously.
So, we’ve made it possible to create shared branches in Looker.
What’s in a branch?
Think of a branch as an entirely separate copy of your codebase that’s still connected to the version of the codebase that’s functioning as the production code for your users. A branch allows you to develop and experiment freely without fear that your code will affect other users. It’s your own private sandbox.
That branch is still connected to the master code however, so when developers are ready, they can “push their code to production”, which merges changes on their branch with the master branch.
Prior to Looker 5.0, the only branches that could be created in Looker were branches for individual developers. Developers in Looker would work on their own private Git branch whenever they were in development mode. Looker would automatically create branches for LookML developers, and they were accessible to only that user (the only way to view another person’s branch would be to sudo as that user).
Enter Shared Branches in Looker
Shared branches in Looker change all of that. Now, developers in Looker can create shared branches that can be edited and modified by other LookML developers.
This is a big deal because this feature finally allows analysts in Looker to collaborate on the same enhancements to their data model. Now, if I’m working on something and want input from my team, I can get help from another LookML developer easily because they can just check out and modify the branch I created.
This of course, doesn’t mean that your private developer sandbox goes away. LookML developers can still develop on their own personal branch. Other developers will be able to view (but not modify) that branch. If another developer wants to modify code on another user’s private branch, they can always create another branch from that user’s personal branch.
We believe this will allow analysts to organize and collaborate in new and productive ways, and hopefully make life a little easier for analysts, as well.
Want to learn more about what makes Looker the perfect platform for version control? Learn what makes building a data model on Looker so powerful.