[Open Source] BranchRift — catch Git integration risk before Unreal branches come back together

Development Pipeline & Plugins
, , ,
1

Hi everyone,

I’ve been working on a small open-source tool called BranchRift after running into a recurring problem in Git-based Unreal workflows: a branch can look ordinary until integration time, while both sides have touched the same map/asset paths or the repository has quietly diverged.

BranchRift is a read-only Git CLI that runs before integration and combines a few signals into one report:

  • branch topology and merge-base provenance
  • ahead / behind counts and fast-forward eligibility
  • paths changed on both sides since the merge-base
  • binary-sensitive .uasset / .umap collisions
  • Git LFS readiness
  • configurable ownership / governance rules
  • a focused manual-review and verification list

A “collision” in BranchRift only means the same repository path changed on both sides since the merge-base. It does not claim that Git will definitely produce a textual merge conflict, and BranchRift does not try to interpret the internal semantics of Unreal binary assets.

It also never merges, checks out, pulls, commits, deletes, or modifies the repository. The goal is simply to make integration risk visible before someone actually performs the integration.

Example:

Integration:
  Topology: DIVERGED
  Fast-forward eligible: no
  Ahead: 7
  Behind: 4
  Same-path collisions: 2
  Binary-sensitive collisions: 1
    - Content/Maps/L_Main.umap [map, BINARY-SENSITIVE]

Install

pipx install branchrift

Then:

branchrift --base main

GitHub:

BranchRift is currently v0.2.0, MIT licensed, Python 3.10+, and has no runtime dependencies outside the standard library.

I’m mainly looking for feedback from people actually using Git / Git LFS with Unreal, especially small teams.

The questions I care about most are:

  • Would these signals be actionable in your workflow?
  • Do you already solve this better with locking, Perforce, custom scripts, CI, or something else?
  • Does this belong as a local developer check, CI/PR automation, or nowhere at all?
  • Is there an important integration risk that this model completely misses?

Negative feedback is useful too. I’d rather find out that the model is wrong than add features around a bad assumption.

Thanks,
Kaan