This is a guest blog post by GitKraken Ambassador, Benjamin Daniels. Benjamin works as a Research Analyst for the World Bank Group, specializing in international development economics. His team, DIME Analytics (Development Impact Evaluations), believes in teaching Git, GitHub, and GitKraken to new researchers through a focus on time and task management.

When we heard how Ben and his team were using GitKraken to improve and expedite their work—outside of the software development realm—we wanted to learn more.

Teaching Git and GitHub with a Focus on Task Management

Our team teaches a GitFlow branching model to researchers and other staff who want to better manage their research projects across teams of any size and timeframes of any scale. We do this because research projects are a classic case where the tools of version control with Git, such as GitKraken, really shine; the ability to maintain multiple branches and revisit historical snapshots are very valuable when we are iterating econometric modelling.

However, when we train teams to use Git for the very first time, we don’t teach tools from a technical perspective, but from a task-based perspective. We don’t care as much that our staff understands from the very beginning what is going on behind the scenes, but we want to make sure they can get started and become comfortable using a new technology that will have many unfamiliar aspects.

Making Git Relatable

Our functional model starts from an analogy of a service everyone already knows: email. In our introduction, “Git” is a “protocol” — an invisible thing just like email that runs behind the scenes.

How do you interact with email? Most often, through a desktop client or a webapp. We let GitKraken or GitHub Desktop stand in for the client, and GitHub.com for the webapp (we make sure to pronounce the dot-com to reinforce that distinction). We emphasize that the client interacts well with the work you do on your computer, and the webapp interacts well when you need to coordinate that work with other people.

Understanding Git Terms

We want to make sure users are comfortable making mistakes in these new interfaces, so they feel confident trying new things and asking for help if something goes wrong. Git terminology is frequently not the most encouraging for this: merges are conflicts; tasks are issues; contribution is blame. Similarly, the enormous amount of jargon in the Git documentation can seem impenetrable.

Therefore, we do three things to make Git workflows more accessible when we introduce people to using Git individually.

First, we reduce the functionality of Git to simply committing and branching, and say most other tasks are just complex combinations of these. We give staff the motto “you really can’t break it”; and we ask them to phrase questions in terms of “what they want to do” rather than teaching a great deal of nonessential vocabulary. This provides the most basic onramp into using Git by managing the essential tasks locally in the Git client, GitKraken.

Introducing GitFlow to Economics Research

Our second step is teaching staff to collaborate using Git, by educating them on the following simplified mental model of GitFlow. We focus on relating Git concepts to task management ideas our teams are already familiar with.

The master branch is for executive-level tasks like completing a conference draft or submitting a manuscript.

The develop branch is for project-level tasks, like adding a new figure or table, or writing up a new chapter.

Since code tasks are not done at those levels, we don’t do new work on those branches. We use feature branches to organize the daily work of coding, and each commit should correspond to a sensible human task, like “Add controls to regressions in Table 1.”

Then we show them how pull requests are created and merged on GitHub.com by the person responsible for the higher-level task. The code tasks add up to a project task when a pull request is submitted, and the project tasks eventually add up to an executive task when we prepare a release.

You Don’t Have to be a Computer Scientist to Use Git

The majority of our team members lack computer-science backgrounds; they are mostly highly-trained econometricians, statisticians, survey specialists, or have other backgrounds. The statistical programming tools our teams use on a day-to-day basis do not work like modern webapps or even like regular compiled languages, so code itself is not yet thought of as a primary product. Instead, they tend to hew closer to interactive and scripting languages, and therefore, staff think in terms of what they are trying to do with their code rather than in terms of what they are trying to make.

This model makes that relationship relatively clear, and in doing so provides intuition for some of the most essential technical questions of using Git in practice: “When should I commit?” and “When should I branch and merge?” The answer we used to give was something not much better than “not too often and not too rarely,” but now the answer is more like “when the corresponding task is done,” and this seems to make sense.

This also makes it much easier to introduce people to task management in GitHub and GitKraken Glo Boards, since issues can be directly connected to feature branches, and resolutions of the tasks they contain can be directly connected to individual commits.

Task tracking and code review are two of the main processes we have been able to introduce to our teams without development backgrounds, particularly when senior and managerial staff are often those with the least detailed familiarity of the code base on a given project.

For us at the World Bank Group’s Development Impact Evaluations team, the task-centric method provides a language and an interface for linking code to research analysis work in a way that is relatively easier to understand than, well, this article on distributed workflows; and we hope that this method can be useful to others as well!

DISCLAIMER: The findings, interpretations, and conclusions expressed here are those of the authors alone and do not necessarily represent the views of the World Bank, its executive directors, or the governments they represent.