Tag: git
Pull Requests Done Right: Stop Splitting Tickets and Code Reviews
If you’ve ever worked on a bug fix in GitHub or GitLab, you know the drill: create a branch, write your code, open a pull request, and then… create a whole new artifact that lives separately from the original issue. Now you’re managing two things—the bug report and the PR—with links bouncing between them, comments scattered across both, and a history that requires detective work to piece together.
What if your code, commits, review comments, and the original ticket all lived in one place?
That’s how GForge works.
The Problem with Separate Pull Requests
This pattern shows up across modern toolchains—from GitHub and GitLab to Atlassian’s Jira + Bitbucket stack—where issues and pull requests are linked, but still exist as fundamentally separate objects.
In most DevOps tools, a pull request is its own entity. You have:
- Issue #1234: “Login button doesn’t work on mobile”
- PR #567: “Fix mobile login button”
They are connected, but they are not the same thing.
The ticket describes the work. The pull request holds the code review, comments, approvals, and merge action. That split may feel harmless in the moment, but it creates friction over time.
A developer opens a ticket. A branch is created. A pull request is opened. Review comments and approvals live in the PR. The ticket shows a link or status update. The PR is merged, the branch is deleted, and the team moves on.
Months later, someone needs to understand what was reviewed, who approved it, and why certain decisions were made. Now the team is reconstructing context across multiple tools: the ticket history, commit logs, and a pull request that may no longer exist in any meaningful way. Critical review discussion is fragmented—or gone entirely.
For regulated industries—defense, aerospace, finance, and on-premise enterprise environments—this isn’t just inconvenient. It’s a structural risk. When compliance, audits, or long-lived programs demand a clear, authoritative history of work and review, “linked artifacts” aren’t enough.
What’s needed is a single system of record where the work item is the review.
GForge’s Approach: The Ticket IS the Pull Request
In GForge, when a developer is ready for code review, they simply change the ticket’s status to “Needs Merge” (or whatever status your team configures for this stage). The ticket itself becomes the pull request.ds Merge” (or whatever status your team configures for this stage). The ticket itself becomes the pull request.
Here’s what that looks like in practice:
1. Work Branch Association
When creating or editing a ticket, developers specify a Work Branch—for example, next/ticlone_events_#64221. GForge automatically associates all commits on that branch with the ticket. No need to remember special commit message formats (though you can use [#64221] in commit messages if you prefer).
2. One-Click Code Review
When the ticket moves to “Needs Merge” status, reviewers see a Merge tab right on the ticket. This shows:
- All commits on the work branch
- A full diff with inline and side-by-side views
- The ability to add line-by-line comments directly in the code
3. Inline Review Comments
Reviewers can click any line of code and add a comment. Need to mention a teammate? Just type @mtutty and they’ll be notified. These comments appear in the ticket’s timeline alongside status changes, assignment updates, and follow-up discussions..
4. Comments That Survive Branch Deletion
When you add a comment on a specific line of code, GForge captures the surrounding context. Even after the work branch is merged and eventually deleted, those review comments—with their code context—remain part of the ticket’s permanent history.Here’s a detail that matters: when you add a comment on a specific line of code, GForge captures the surrounding context. Even after the work branch is merged and eventually deleted, those review comments—with their code context—remain part of the ticket’s permanent history.
5. Complete the Merge
When review is done and the code is approved, click Complete Merge. GForge performs the merge server-side (no need to switch to your terminal). If there are conflicts, you’ll see them immediately and can complete the merge locally instead.
The Promotion Model: Structured Branch Flow
GForge supports a Promotion Model that defines how code flows from development to production. You configure the sequence of branches—for example:
gforge-next(development)gforge-next-deploy(staging)gforge-com(production candidate)master(production)
When merging from a work branch, GForge automatically targets the first branch in your promotion model. Reviewers can override this if needed, but the default keeps your process consistent.
Commit Message Intelligence
GForge parses commit messages to link commits to tickets and even advance workflow status. Some examples:
Basic linking:
git commit -m '[#12345] Make the spinning logo bigger'
This links the commit to ticket #12345.
With time tracking and status change:
git commit -m '[#12345,1.5,merge] Make the spinning logo bigger'
This links the commit, logs 1.5 hours of work, and moves the ticket to “Needs Merge” status.
Multiple tickets:
git commit -m '[#12345,1.5,merge] [#11234,.5,wontfix] Refactor shared component'
Handle multiple tickets in a single commit, each with their own time and status updates.
Why This Matters for Regulated Industries
For defense contractors, aerospace companies, and other organizations with strict audit requirements, GForge’s unified approach provides:
Complete Traceability: Every code change, review comment, and approval lives in one place. An auditor can open a single ticket and see the entire history of a change from request to deployment.
Simplified Compliance: No need to correlate separate PR systems with ticketing systems. The ticket number IS the change record.
On-Premise Deployment: For ITAR compliance or air-gapped networks, GForge runs entirely on your infrastructure. Your code review history never leaves your network.
Two Ways to Merge
GForge actually offers two approaches to code review:
1. Ticket-Based Merge (Recommended): Use the Merge tab on tickets in “Needs Merge” status. This is the full-featured approach with complete audit trails and comment preservation.
2. SCM-Based Merge: For teams not using GForge’s tracker, the Git repository’s Merge tab lets you select source and target branches directly. This works well for small teams or simple workflows, but you lose the ticket integration benefits.
The Bottom Line
Pull requests shouldn’t be separate artifacts. Your bug report or feature request should evolve naturally into a code review and then into a merged change—all in one place, with one timeline, one set of comments, and one audit trail.
That’s what GForge delivers. No more bouncing between issues and PRs. No more scattered review comments. No more compliance headaches trying to prove who approved what.
Ready to see it in action? Start a free trial or schedule a demo with our team.
GForge is an integrated DevOps platform that combines project tracking, Git/SVN repositories, wikis, CI/CD, and team collaboration in a single solution. Available as SaaS or self-hosted for organizations requiring on-premise deployment.
Introducing gforge-cli: GForge from Your Terminal
If you’re a developer who lives in the terminal, context-switching to a web browser just to check your tickets or create a branch feels like friction. That’s why we built gforge-cli—a command-line tool that brings GForge to where you already work.
What It Does
gforge-cli lets you interact with GForge directly from your terminal. Check assigned tickets, change statuses, create branches linked to issues, and access any API endpoint—all without leaving your workflow.
Here’s what’s available:
gforge login --server https://your-gforge-instance.com
gforge ticket list --project myproject
gforge ticket view 12345
gforge ticket transitions 12345
gforge ticket transition 12345 "Works for Me"
gforge branch 12345 "Add user authentication"
gforge api /api/project/myproject/trackerThe tool works with both Git and SVN repositories. When you create a branch with gforge branch, the ticket ID is automatically embedded in the branch name for traceability—no more manually typing feature/12345-description.
Quick Start
1. Download and install from gforge.com/gforge-cli
2. Authenticate with your GForge server:
gforge login --server https://next.gforge.com3. List your tickets:
gforge ticket listSession tokens are stored securely in ~/.config/gforge/, so you only need to authenticate once per server.
Use Cases
Morning standup prep: Pull up your assigned tickets in seconds.
gforge ticket list --project gforge-developmentStart work on a ticket: Create a linked branch without copying IDs.
gforge branch 47397 "Add manual search to nav bar"
# Creates: feature/47397-add-manual-search-to-nav-barFinish a task: Update the ticket status from your terminal.
gforge ticket transition 47397 "Works for Me"CI/CD automation: Script GForge interactions in your pipelines. The gforge api command gives you raw access to any endpoint:
gforge api GET /api/project/myproject/tracker/item/47397
gforge api POST /api/project/myproject/tracker/item --data '{"summary":"New ticket"}'What’s Next
We’re actively developing gforge-cli. Wiki commands for managing documentation are coming soon—create, edit, and publish wiki pages without leaving your editor.
Have a feature request? Let us know at feedback@gforgegroup.com.
Get Started
Download gforge-cli and bring GForge into your terminal workflow.
GForge 25.0 Released!
The GForge Group team is happy to announce the release of GForge 25.0! This is primarily a feature release, though it includes a number of bug fixes and infrastructure updates.
Key Highlights in 25.0
- Core System
- Added support for Microsoft SSO (oAuth). We already supported this for SaaS, this feature is for on-prem customers who want to configure their GForge instance to only use Microsoft (and not others like Google, etc)
- Continued work on the migration from AngularJS ot Angular
- Fixed an issue with Postfix not restarting cleanly during GForge restarts.
- Site Admin
- Site Admins now receive email and in-app notifications when a user account is locked, enabling more proactive support.
- Added configuration options related to authentication:
- Password aging rules
- Password reuse rules/restrictions
- Notification preferences on account lockouts
- Introduced a new cron job administration page allowing Site Admins to view and manage the status of all GForge cron jobs.
- Fixed a bug where the User Administration page incorrectly displayed groups.
- Version Control
- Git Blame is now available while browsing Git repositories.
- Fixed a bug where switching from Subversion to Git still allowed commits to the SVN repository.
- Corrected the example provided for using Subversion over SSH.
- Tickets
- Mass Update now allows the addition of tags to multiple tickets (note: tag removal is not supported yet)
- The Planning Board now includes direct links to it’s underlying data sources.
- Fixed a bug where saved queries spanning multiple sprints would fail to load properly.
- Improved performance when displaying tickets with high activity (e.g. follow-ups, commits).
The 25.0 ChangeLog details all the changes made in this release.
GForge 23.1 Released!
The GForge Group team is happy to announce the release of GForge 23.1! This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 23.1
- Single Sign-On – Our Single Sign-on support now support numeric external IDs (used by a few, specific SSO vendors).
- Tickets – Improvement to planning boards specifically when showing/hidding specific rows and columns.
- Security – Fixed a number of security vulnerabilities found by both internal and external audits.
- Angular 14 Migration – While this doesn’t impact our customers in any obvious way, this is a large undertaking to pay some technical debt.
- Releases – For non-contributing project members (e.g. project members associated with but not contributing to a project) releases not specifically marked as “Released” are now hidden. This allows for releases to be better planned without giving access to them to specific members. Also, users may now add a “watch” to a release to get updates when the release changes. Finally users only see tickets on a roadmap unless they are contributors.
The 23.1 ChangeLog details all the changes made in this release.
GForge 23.0 Released!
We’re happy to announce the immediate availability of GForge 23.0. This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 23.0
- SSO – Many improvements to our Single Sign-On support.
- Security – Fixed a number of security vulnerabilities found in an audit.
- Angular 14 Migration – While this doesn’t impact our customers in any obvious way, this is a large undertaking to pay some technical debt.
- Releases – We’ve made a number of improvements to the visibility of releases, particularly in the case where you want to prevent a release from being accessible but want to keep all its associations to tickets, etc intact.
The 22.2 ChangeLog details all the changes made in this release.
Health Checks: Commits
This category of health checks focuses on the code you check into your GForge Next project, how it relates to task management, team and file sizes.
Commits Per Tracker Item
Definition: The number of separate commits associated to each Tracker Item in your project. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: Having too many commits makes it harder to understand the associated Tracker Item’s history later on. It can also skew Sprint, Burndown, and Release metrics to look bigger or smaller than they really are.
How to fix? Although you can add or remove associations between a commit and a Tracker Item, it’s better to look forward than try to change history. When planning a Sprint or Release, consider the size of each Tracker Item, and break them down into smaller tasks that might affect fewer files, or involve fewer iterations for each TI.
Commits with Tracker Items
Definition: The percentage of commits in the last 90 days that are associated (or not) to a Tracker Item. Also checks for commits that are tied to more than on TI.
What it means: Pushing commits without an associated task is an easy way to mess up your code base over time. It’s also bad for team collaboration and Sprint and/or Release tracking.
How to fix? To fix existing commits, you can create Tracker Items, and associate them using the SCM Commits listing. Click a commit and use the “Tracker Item Associations” section at the bottom of the commit details view.
You can (and should) also fix the process for pushing commits to your project:
- Go to the Project Admin SCM tab, and choose “Require” for the “Associate Tracker Items” option.
- You might also check the “Restrict Tracker Item Associations” setting, depending on whether you want to allow associations between commits in this project and Tracker Items from other projects.
- Usually, this setting should be “Yes” to keep it to the current project.
Committers
Definition: The number of users with commits in the last 90 days, and the proportion of all commits made by each user.
What it means: For smaller projects (with only one or two contributors) this check won’t mean much. For full-sized Agile teams (4-5 contributors) or larger, traditional teams (10 or more contributors), this check can help you understand if work is balanced properly between team members.
How to fix? If you’re not using Tracker Items (and requiring that commits tie to them), then you should start right away. Having a specific task should be required in order to make code changes anyway, and an official task list lets the Product Owner, Scrum Master, or even the team itself to balance tasks among contributors by size, functional area and dependencies. Proper task balancing will lead to balanced commits from the team.
Files Per Commit
Definition: The number of files changed (or added, or removed) by each commit. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: In general, commits should touch less than ten files. Large commits (many files and/or many lines of code) are harder to review, harder to understand later, and more likely to cause merge conflicts with other commits.
How to fix? This is another one where what’s done is done. Going forward, make sure that the team is doing proper analysis on task sizes during planning, and on the changes to be made when working each task. If a specific task requires changing many files, try to find a way to iterate on it, changing a few files in one commit, reviewing/merging that commit, then moving on to the next set of files.
Of course, sometimes you’ll just need to bite the bullet – a breaking change in a dependency/library, an urgent security fix, etc. But those hefty commits should be the exception and not the rule.
GForge 22.2 Released!
We’re happy to announce the immediate availability of GForge 22.2. This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 22.2
- HTTP/2 Support added – To learn more about the benefits of HTTP/2 here.
- Tickets can now be filtered based on whether or not they have attachments.
- Tickets can also be filtered based on they have a parent and/or child ticket.
- Users can now react (thumbs up/down) on comments.
- File Uploads – Fixed the issue where file uploads would die after 20MB regardless of the configured value.
- REST API – Updated missing and incomplete documentation.
- Site Admin – Searching projects by name has been improved.
- Browse Projects – Users could only search for projects they knew about in prior GForge versions. This version allows users to browse all projects they have access to.
Looking Ahead to 23.0
We want to point out some important changes coming in GForge 23.0 (spring 2023). This version will add support for Kubernetes and it is going to have a new ticket editor. We’d love to get some feedback on the new editor before it is released so if you would like a sneak peak you can register a test project or you can send us an email and we can shoot over some screenshots. Additionally, for you users interested in Kubernetes, if you have any specific questions or would like to beta test this in your environment we’d love to hear form you. Just contact us at feedback@gforgegroup.com.
The 22.2 ChangeLog will help you understand the changes you can expect.
GForge 22.1 Released!
GForge v22.1 is primarily a bug fix release with a fair number of new features included!
GForge Now Supports Windows
Over the years we have been asked numerous times if GForge can run under windows. The complexities of GForge’s collaboration features had tied us completely to Linux. When we released our first version of GForgeNext under Docker we saw a future that might eventually include Windows. Today is that day.
You’re probably wondering why now when Docker has been out for years. The key lies in GForge’s interactions with the host filesystem and now with WSL (Windows Subsystem in Linux) those final hurdles have been dealt with.
GForge Includes Podman Support
We’re not here to ding Docker, it’s served us well for many years. That said, their approach to virtualization has caught the eye of many in the security world and because of that Podman was born. Podman was built to do everything Docker does but addressing many of the security concerns in Docker. With all that in mind, GForge now support Podman in addition to Docker. As important, your choice of Podman vs Docker is independent of your choice of Linux vs Window+WSL.
Other Key Highlights in v22.1
- Tickets
- Tickets can now be filtered based on whether or not they have attachments.
- Tickets can also be filtered based on they have a parent and/or child ticket.
- Users can now react (thumbs up/down) on comments.
- Chat – We have added a few useful macros. For example you can search StackOverflow, Microsoft, and Wikipedia. You can also send private messages to a specific user. To see all of the supported macros just type “/help”.
- Markdown – Anywhere GForge supports markdown now includes support for tables.
- Version Control – All the repository homepages now include a link to a GForge-specific FAQ addressing common issues our customers have using Git, SVN and CVS
The 22.1 ChangeLog will help you understand the changes you can expect.
GForge 22.0 Released!
GForge v22.0 is primarily a feature release with a fair number of bug fixes included
Introducing Planning Boards
You already know GForge allows you to plan, distribute and track your work. With GForge you are already able to plan a release, break the release down into manageable sprints and assign work to your team. Planning Boards gives our existing kanban features a big shot in the arm by allowing you to create boards and quickly begin moving work around. The image below gives an example of moving tickets in a release into sprints and assigning the work out.
We’ll be sharing a deeper dive covering Planning Boards on here and on our YouTube Channel.
Other Key Highlights in v22.0
Project Navigation – We’ve made a big improvement to the project navigation bar. The new version now groups related project features and adds labels. The prior version assumed you knew the icon for each feature).
- Tickets
- There are cases where you want to have tickets in one project reference commits made in other projects. The commits tab in the ticket editor will now show the commit data.
- There is a printable version of a ticket.
- Documents – You can now add tags to documents.
- Version Control – There’s been a number of improvements:
- For Git repositories we’ve replaced the “master” branch with the name “main” (this only applies to new projects)
- We’ve added a script to convert CVS repositories to Git
- Some minor bug fixes (see ChangeLog below for more information)
- Admin:
- We now have the ability to share a software bill of materials (SBOM) listing all the libraries and packages GForge uses in each release. You can request the SBOM by email feedback@gforgegroup.com
- Projects can now to exported from one GForge instance and imported into another GForge instance assuming both instances are running the same version of GForge.
The 22.0 ChangeLog will help you understand the changes you can expect.
Check back soon as we’ll be sharing our plans for the rest of 2022!