Fast-Forward-Only Merges in GitHub Actions: A Safer Way to Sync Branches

Riddhi Jathar — Tue, 07 Jul 2026 13:35:16 +0000

The problem

We maintain a repo with two long-lived branches, master and main, that need to stay in sync. The manual routine was: checkout locally, pull both, merge, hope nothing conflicts, push. Every time. Repetitive, and one distracted moment away from a messy merge commit or a conflict resolution you didn't mean to make.
A co-maintainer on this repo set up a GitHub Action to handle it instead. I just liked it enough to write about it.

The workflow

name: Manual Fast-Forward Master to Main
on:
  workflow_dispatch:
jobs:
  merge-branches:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Configure Git Identity
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
      - name: Attempt Fast-Forward Merge
        id: git_merge
        run: |
          git fetch origin main
          git fetch origin master

          git checkout main

          if ! git merge origin/master --ff-only; then
            echo "::error::Cannot fast-forward! Histories have diverged or conflicts exist. Aborting."
            exit 1
          fi
      - name: Push Changes
        run: |
          git push origin main

workflow_dispatch means this only runs when someone manually clicks "Run workflow" in the Actions tab, no accidental triggers on push or schedule. Click it, and the job:

Checks out the full history (fetch-depth: 0 needed so the merge actually has both branches' history to compare)
Checks out main
Tries git merge origin/master --ff-only
Pushes if it worked

Why --ff-only is the part worth understanding
A regular git merge will happily create a merge commit, or ask you to resolve conflicts, or in some configs auto-resolve things in ways you didn't explicitly review. --ff-only refuses all of that. It only allows the merge if main hasn't diverged from master at all, meaning main can just "fast-forward" its pointer forward to match, with no new commit and no ambiguity about what changed.
If the branches have diverged, the flag makes git fail instead of guessing. That's the whole safety net. The workflow catches that failure explicitly (if ! git merge ... ; then echo "::error::..."; exit 1; fi) so it shows up loud and clear in the Actions log instead of silently pushing something wrong.
That's the actual lesson here: automating a merge is easy. Automating it so that it fails safely instead of doing something unintended, that's the part worth copying into your own workflows.

Is this novel?

No, and worth being upfront about that. workflow_dispatch has existed since GitHub introduced it in 2020, and fast-forward-only merges are just core git behavior. This isn't a new invention, it's a small, well-known pattern for anyone who's automated branch syncing or release promotion with Actions.
But it's a good example of a broader habit worth building: find the repetitive manual git step you don't fully trust yourself to do carefully every single time, and hand it to a machine that does the exact same safe thing, consistently, with a paper trail.

Jenkins Freestyle Jobs vs Pipeline: Which Should You Use?

Riddhi Jathar — Thu, 29 Jan 2026 20:15:32 +0000

When working with Jenkins, you'll encounter two main job types. Here's what I learned about when to use each.

Freestyle Jobs: GUI-Based Configuration

Freestyle projects are Jenkins traditional approach, where everything is configured through the web interface.
It is best for:

Simple build tasks
Quick prototypes and experiments
Jobs that rarely change

Limitations:

Configuration isn't version-controlled
Manual replication across projects
Gets messy with complex workflows
No code review for changes

Pipeline Jobs: Code-Driven Automation
Pipeline defines your CI/CD workflow as code in a Jenkinsfile:

pipeline {
    agent any {
    stages {
        stage('Build') {
           steps {
               sh 'npm install && npm run build'
           }
        }
        stage('Test') {
           steps {
               sh 'npm test'
           }
        }
        stage('Deploy') {
            steps {
               sh './deploy.sh'
           }
        }
     }
}

It is best for:

Production deployments
Multi-stage workflows (dev-> stage -> prod)
Anything you need to replicate
Complex orchestration needs

Key advantages:

Version controlled with your code
Reusable across projects ( just copy the Jenkinsfile )
Code review for pipeline changes
Supports parallel execution

The Bottom Line
Freestyle jobs are beginner-friendly and work fine for simple tasks. Pipelines are the modern standard for production CI/CD because they're scalable, version-controlled, and automatable.
Start learning with freestyle to understand Jenkins basics, then transition to pipelines for anything production-grade. You don't need to convert everything; keep simple jobs as freestyle if they work well.

Further reading:
Jenkins Pipeline Documentation
Pipeline Best Practices

DEV Community: Riddhi Jathar

Fast-Forward-Only Merges in GitHub Actions: A Safer Way to Sync Branches

The problem

The workflow

Is this novel?

Jenkins Freestyle Jobs vs Pipeline: Which Should You Use?