Git-backed Workflow for Research Units with High Rotation

What Is a Unit with High Rotation?

A high-rotation unit (HRU) refers to an academic group—such as a lab, research center, or departmental unit—where personnel turnover is frequent. Graduate students, postdocs, and visiting researchers often join on fixed-term appointments and leave regularly. The unit experiences continual inflow and outflow tied to academic cycles or contract periods.

A few long-term faculty or technical staff typically provide continuity. HRUs often maintain regular onboarding, training, and hand-off procedures to manage turnover.

Common challenges for HRUs include:

1. Maintaining continuity with short-term personnel.
   Reliance on fixed-term roles makes it difficult to preserve institutional knowledge as members regularly join and leave.

2. Balancing training and productivity.
   Frequent onboarding and mentoring require substantial time from senior staff, often diverting effort from research and project advancement.

3. Safeguarding institutional memory.
   Without consistent documentation and hand-off practices, key methods, decisions, and code can be lost when personnel depart.

4. Designing resilient and modular projects.
   Work must be structured so newcomers can contribute quickly without full system mastery.

5. Embedding reproducibility and standardized workflows.
   Clear documentation, version control, and formal onboarding/offboarding processes are essential to sustain quality and reproducibility over time.

Figure 1: HRUs - high rotation units

Git and GitLab provide the scaffolding to ensure these contributions remain transparent, traceable, and reproducible for future team members.

Git and GitLab

Git is a tool that helps people track changes made to files, especially when several people work on the same project. It keeps a complete history of every change, allowing users to see who did what, compare versions, or roll back if something breaks.

GitLab is a platform that helps teams use Git collaboratively. It provides a shared space to store projects, review work, report issues, and automate testing or publishing. GitLab can be used online or installed on a private server.

UW–Madison hosts its own instance at git.doit.wisc.edu, which supports both open and controlled environments.

In short: Git tracks changes, and GitLab helps teams collaborate on those changes.

Figure 2: An onboarded person can create different types of content

How Git and GitLab Help

For HRUs, Git provides a reliable way to preserve and share the history of code and analytical work. Every change to a script or document is automatically recorded with details about who made it and why, helping new members understand prior decisions and pick up where others left off.

GitLab builds on Git by offering a shared workspace for code, documentation, and discussions. It supports code review, issue tracking, and automation—keeping results reproducible even as team members change.

Together, Git and GitLab create a structured, transparent, and well-documented workflow that protects institutional knowledge and minimizes disruption caused by turnover.

UW–Madison researchers have free access to:

• Git: open-source software that can be installed locally.
• GitLab: available to all campus users with a valid NetID.
• Training and support: provided through The Data Science Hub and UW Libraries Workshops.

Figure 3: Visualization of content stewardship within the unit’s Git repository.

Purpose and Use Case

Publishing directly from RStudio or the command line works well for individuals, but when teams need to share ownership and maintain projects over time, Git-backed deployment is the better option.

With GitLab, the code lives in a central repository rather than on a single person’s laptop. This ensures the project remains accessible and deployable, even when contributors rotate in and out.

This workflow is especially useful for:

• Labs or research groups where multiple people publish to Posit Connect
• Teams with frequent staff or student turnover
• Any group that wants to maintain a stable and reliable code base

Prerequisites

Before using Git-backed deployment, ensure you have:

• A GitLab departmental account
• Publisher rights on Posit Connect
• A committed manifest.json file in your repository
• Read access for Connect to your GitLab repository

Designated Branch

When linking your repository, always select a designated branch. This ensures Connect redeploys only from a release-ready source.

Figure 4: Screenshot of Posit Connect settings panel showing branch configuration.

Two-Step Process for Deploying Git-Backed Content

1. Create and commit a manifest file in the development environment.
2. Link Posit Connect to the Git repository from within Connect.

Create Manifest from R

Run the following command in the RStudio console from within the content directory:

rsconnect::writeManifest()

You may specify optional arguments such as:

• appDir: Directory containing the application
• appPrimaryDoc: Primary file if more than one
• contentCategory: Type of content

Create Manifest from Python CLI

Install the required package:

pip install rsconnect-python

Then generate a manifest for your content type:

rsconnect write-manifest notebook my-notebook.ipynb

If a requirements.txt file is missing, the tool will generate one from your active Python environment.

Linking Git to Posit Connect

To link a Git repository to Posit Connect:

1. In Connect, select Publish > Import from Git.
2. Provide the repository’s HTTPS address.
3. Select the desired branch.
4. Choose the target directory (must contain a manifest.json file).
5. Click Import/Publish.

If Connect shows the error “could not find available branches … exit status 128”, it lacks read access. Fix this by using a credentialed HTTPS URL (Deploy Token or SSH Deploy Key).

For details, see Posit Connect Documentation – Git-Backed Publishing.

Figure 5: Screenshot showing Import from Git option in Posit Connect publish menu.

Publishing Directly from the Command Line Interface

Posit Connect supports CLI deployment for:

• Jupyter notebooks
• Python APIs (Flask or FastAPI)
• Dash, Streamlit, Shiny for Python, or Bokeh apps

Other content types can be deployed from the CLI if they have a prepared manifest.json file.

Create API Key on Connect

1. Open your Posit Connect Dashboard.
2. Navigate to your Profile.
3. Select API Keys > Create New.
4. Copy the key and store it securely.

Treat the API key like a password. For secure management in RStudio, see the HTTR Vignette – Managing Secrets.

[Image Placeholder – Figure 7]
Upload screenshot showing API Key creation interface.
Suggested alt text: "Screenshot of Posit Connect profile page showing API Key creation."

Install rsconnect-python

Install the CLI in your virtual environment:

pip install rsconnect-python

Adding a Connect Server

Provide your server URL, API key, and nickname:

rsconnect add --server https://my.connect.server/ --name myServer --api-key $CONNECT_API_KEY

Deployment

Deploy content to your Connect server:

rsconnect deploy notebook --title "My Notebook" my-notebook.ipynb

To set environment variables:

rsconnect deploy notebook --environment MYVAR='hello world' notebook.ipynb

For more details, see Posit Connect Documentation – Publishing via CLI.

Contact

For questions about Git-backed workflows or Posit Connect publishing, contact
Research Cyberinfrastructure (RCI) Support:
rcisupport@doit.wisc.edu

Last Reviewed

October 2025