What’s New in Harness Open Source v3.2.0: PR Workflows, Git LFS, and Smarter Automations

With the v3.2.0 release of Harness Open Source, we’ve shipped several features that smooth out your day-to-day Git operations, improve team workflows, and support CI/CD workloads. Whether you're managing pull requests, dealing with large binaries, or tightening review rules, this release has something for you.

Let’s dig into what’s new — and more importantly, why it matters.

1. 🔍 Git LFS Support Is Here

Git LFS (Large File Storage) support has landed. That means you can now push and pull large binaries (datasets, models, images, compiled assets) with confidence using Harness Open Source as your Git backend.

Why this matters:
Traditional Git isn’t optimized for large binary files — performance suffers, repo size balloons, and diffs become useless. That’s where LFS helps: it stores large files externally and keeps lightweight pointers in your repo. Harness Open Source now supports this seamlessly.

Dev tip: You can enable LFS in your repository config and start pushing .gltf, .psd, .zip, or anything you’ve been awkwardly storing in S3 or somewhere else.

2. 🔁 “Revert PR” — A Safety Net for Everyone

Merged a PR and things broke? Happens to the best of us. Now you can revert a pull request with a single click from the UI.

Why this matters:
This is your new safety net. Instead of manually figuring out the SHA and crafting a revert commit, the platform handles the entire process.

Combine this with branch protection rules and review workflows, and you’ve got a tight feedback loop with minimal room for human error.

‍

3. 🔄 Change the Target Branch of a Pull Request

You opened a PR to main but it was supposed to go to release/1.0? Now you can change the target branch of a pull request without closing or reopening it.

Why this matters:
This one’s for teams working with multi-branch strategies, long-lived releases, or hotfix flows. It unblocks situations where the original base branch was wrong — no more duplicated PRs just to shift the target.

4. 🧠 Smarter Code Owner Review Assignments

CODEOWNERS just got a promotion. Branch rules can now automatically assign Code Owners as reviewers when a PR is opened.

Plus: email matching for Code Owners is now case-insensitive — a small change, but one that avoids weird mismatches.

Why this matters:
Automating reviewer assignment based on ownership enforces clean code boundaries and speeds up review cycles. Especially for large teams with rotating contributors or shared modules, this reduces friction and increases accountability.

5. 🧷 Require Default Reviewers per Branch

You can now configure default reviewers at the branch rule level — so any PR targeting a specific branch gets the right eyes on it automatically.

Why this matters:
In regulated teams, you often need a “second pair of eyes” for production branches or hotfixes. Instead of relying on tribal knowledge or manual reviewer tagging, this feature locks in your process — and you can go further by requiring approval from default reviewers before merging.

6. 🔐 New Commit Auth Setting

There’s now a new setting to enforce that the Git committer matches the authenticated user.

Why this matters:
This adds another layer of security and traceability. Especially useful for teams that use shared CI/CD keys or service users — you can now prevent commits from being spoofed under the wrong identity.

Final Thoughts

This release focuses on developer quality-of-life improvements and tighter workflow automation. If you're using Harness Open Source not just as a Git host but as the backbone of your CI/CD and artifact management stack — this update is a solid leap forward.

Want to give it a try?

Let us know what workflows you're building — or breaking — with these new features.

‍