Git Workflow Matters

A consistent Git workflow reduces merge conflicts, simplifies code review, enables reliable releases, and helps new team members contribute quickly. At Nexis Limited, we use a modified GitHub Flow across all products — simple enough for small teams, structured enough for production reliability.

Branching Strategies

Trunk-Based Development

Developers commit directly to the main branch (or merge very short-lived feature branches). This requires strong CI/CD, feature flags for incomplete work, and high test coverage. Best for experienced teams with fast CI pipelines and frequent deployments.

GitHub Flow

Create feature branches from main, make changes, open a pull request, get code review, merge to main, and deploy. Simple and effective for most teams. Main is always deployable. This is our primary workflow at Nexis Limited.

GitFlow

A more complex model with separate branches for development, features, releases, and hotfixes. Useful for products with formal release cycles, multiple supported versions, or regulatory requirements. Overkill for most web applications with continuous deployment.

Branch Naming Conventions

Consistent branch names improve readability and enable automation:

  • feature/ — New features: feature/user-profile-page
  • fix/ — Bug fixes: fix/login-redirect-loop
  • chore/ — Maintenance tasks: chore/upgrade-dependencies
  • docs/ — Documentation: docs/api-authentication-guide

Include the ticket number when applicable: feature/JIRA-1234-user-profile-page.

Commit Message Conventions

Use Conventional Commits for machine-readable commit messages:

  • feat: A new feature — feat: add user avatar upload
  • fix: A bug fix — fix: resolve timezone offset in attendance report
  • refactor: Code restructuring — refactor: extract validation logic into separate module
  • docs: Documentation changes — docs: update API authentication guide
  • test: Test additions or fixes — test: add integration tests for payment processing
  • chore: Build, config, dependency changes — chore: upgrade React to v19

Merge Strategies

Merge Commit

Creates a merge commit that preserves the full branch history. The main branch shows when features were merged and their complete development history. This is our default strategy.

Squash and Merge

Combines all branch commits into a single commit on main. Produces a clean linear history but loses individual commit detail. Good for feature branches with many small work-in-progress commits.

Rebase and Merge

Replays branch commits on top of main, producing a linear history without merge commits. Requires careful handling and can cause issues with shared branches.

Code Review Practices

  • Require at least one approval before merging to main.
  • Use CODEOWNERS files to automatically assign reviewers for specific code areas.
  • Review within one business day to avoid blocking teammates.
  • Require CI checks to pass before merge (tests, linting, type checking).

Branch Protection Rules

Protect the main branch with rules that prevent direct pushes, require pull request reviews, require CI checks to pass, and prevent force pushes. These guardrails prevent accidents and enforce process.

Conclusion

A good Git workflow is one your team follows consistently. Start with GitHub Flow — it is simple and effective for most teams. Add structure (branch naming conventions, commit conventions, protection rules) as the team grows. The goal is reliable, reviewable code delivery.

Setting up engineering processes? Our team helps organizations establish developer workflows.