Work Smarter, Not Harder: Git on Board!

JMP on Git is a call to action that we want to promote. My name is Britta Silbersack. I'm from Roche Diagnostics, and my task there is to support our scientists with scripting solution in JMP. When I started with this activity, I met Bernd, who worked as a consultant for Roche. Now we met again to make this presentation.

My name is Bernd Heinen. Some people may know me as a former JMP Senior Systems Engineer. Now, I'm working as a consultant. I'm helping my customers to understand and apply statistics, or I coach them with JSL. So I met Britta. Some time ago, we talked about programming, and we thought it was a good idea to promote the use of Git repository for JSL development.

What is Git? Git is a distributed version control system. You save your JSL scripts into a Git administrator folder, and then lots of function are available that helps you manage your scripts and make your life easier. It just takes snapshots of your scripts at different time points. It helps you to organize your backup, run version control, support collaboration, and document your work.

You can profit from all the benefits of Git when you are working as a programmer all by yourself. Then you don't need much infrastructure. Your copy on a remote server is recommended for backup. The real power of Git unfolds in a collaborative environment. Team members can work on the same program, push their program versions to the repository, and then consolidate their work. It is a machine behind everything, and its native communication is over a command line interface. But there's a whole lot of add-ins that provide GUIs for Git, and even extend its functionality.

We want to show a short video of a characteristic workflow. It is not intended as a training video for Git, but rather as a motivation for the user of Git. We try to keep it short but informative enough to demo the cooperation with Git. We are going to shed a light on aspects like the programming in JSL, the registration of the script in Git, what a snapshot is, the role of the repository, and how different versions of the same script can be merged.

We start with a view on Britta's laptop. She navigates to the GitLab Cloud, which is one of the possible hosting options for Git. She starts a new group, take it easy, and invites people, in this case, me, to join that group. That takes only a few clicks. In this group, she creates a new empty project, TryGit. She fills the default, creates the project, and then she copies the link here and then goes back on her laptop or works local on her laptop. With Git Extensions, the GUI that we are using for this example—there are many—she pastes the link and clones or copies the repository. This creates an empty workspace on her laptop.

Now, she starts writing her JSL script in JMP, of course. After she's done, she saves it into that Git-administrated folder. Now, she creates a commit—this is a snapshot—and pushes or uploads the current state onto the repository on the web in GitLab.

Now we look at Bernd's laptop, and he works remote in GitLab. When I created the work group, Bernd received an email from Git. He was curious and followed the link to the remote repository. He looks up the project. At the time, there was no content yet. He copies the link as well. He follows the same procedure. He clones the repository from the SSH encrypted URL, and determines where on his laptop that clone should reside. He uses the name from the repository for his folder and opens it.

As expected, it shows just an empty workspace. Unfortunately, I got another urgent call and I asked Bernd to continue the work. After I upload my JSL code, he pulls or downloads the current state of this project. He opens it in JMP and extends the program. He saved his changes to the same file. Then he changed to Git Extension and create a new branch. That allows Git to track the changes. You commit or save the current state, and Bernd can see where the program was added. He pushes the state to the repository as well. Click Check, then change to GitLab. On the web, and there's a new branch. He sets the focus to this branch and creates a new merge request.

In the merge request, I named Britta as a reviewer, and I sent her a message, and this message or the information, she got automatically by email. We are looking now on her laptop. She got that email, follows the link, goes to the repository, and sees the merge request. She navigates to there, reads it, checks it, and finally acknowledge my changes. Git shows where the changes have been happening, and the merge is done.

Now, the two different branches are united to the main branch again. Well, now, Britta is back again on the project, and we decide to work on different tasks in parallel. The pull sets the same base for our development on both computers. You see now in the example of Britta's work, how she creates a new branch. That allows Git to follow up her changes. I do the same on my computer—it's not shown here—and then we go on with our programming work, everybody on his version of the program.

We both make the commit or snapshot for our programs. Note that the differences compared to the prior snapshot are highlighted. We push our branches to the repository.

Britta, on her laptop, looks onto the repository in the web, and she sees that both branches are there. She gives a comment on her branch, and then she creates a merge request and names me as a reviewer.

Bernd's laptop, he works now remotely. Bernd navigates to the web, opens the merge request and approves it. He switched to the main branch. Then he pulled the new state of the program onto his laptop, set the focus to his branch, and start a merge there. He wants to fit the main branch into his Fit a Model branch. Oh my God, there are conflicts.

There are also tools that help mitigate the situation. Bernd uses the meld tool to consolidate the different versions of the program. Here you can see a lot of differences. You can easily identify the changes, remove duplicates, insert some parts, and copy-paste some other stuff. He saves the different changes, commits again, and push things up. Now we can both pull the current version of the program and run the completed program with both parts in it.

One thing that should resonate with JMP users is that there is a visualization of the whole development process and its current state. It's not the bare Git functionality, but it comes with one of the many tools that provide interactive user interfaces to Git.

In conclusion, Git is easy to set up and user-friendly. It enables effortless backups, provides robust version control, and simplifies collaboration with colleagues on scripts. I hope we could at least give some insights into the use, the advantages, and the accessibility of Git. It's your turn to get on board now or latest when you are back at your desk.