112 lines
3.0 KiB
Markdown
112 lines
3.0 KiB
Markdown
---
|
|
title: Git Workflows
|
|
description: Practical Git workflow patterns for teams and personal infrastructure repositories
|
|
tags:
|
|
- git
|
|
- devops
|
|
- workflow
|
|
category: devops
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Git Workflows
|
|
|
|
## Introduction
|
|
|
|
A Git workflow defines how changes move from local work to reviewed and deployable history. The right workflow keeps collaboration predictable without adding unnecessary ceremony.
|
|
|
|
## Purpose
|
|
|
|
This document covers the most common workflow choices for:
|
|
|
|
- Application repositories
|
|
- Infrastructure-as-code repositories
|
|
- Self-hosted service configuration
|
|
|
|
## Architecture Overview
|
|
|
|
A Git workflow usually combines:
|
|
|
|
- Branching strategy
|
|
- Review policy
|
|
- Merge policy
|
|
- Release or deployment trigger
|
|
|
|
The two patterns most teams evaluate first are:
|
|
|
|
- Trunk-based development with short-lived branches
|
|
- Feature branches with pull or merge requests
|
|
|
|
## Common Workflow Patterns
|
|
|
|
### Trunk-based with short-lived branches
|
|
|
|
Changes are kept small and integrated frequently into the default branch. This works well for active teams, automated test pipelines, and repositories that benefit from continuous deployment.
|
|
|
|
### Longer-lived feature branches
|
|
|
|
This can be useful for larger changes or teams with less frequent integration, but it increases drift and merge complexity.
|
|
|
|
### Infrastructure repositories
|
|
|
|
For IaC and self-hosting repos, prefer small reviewed changes with strong defaults:
|
|
|
|
- Protected main branch
|
|
- Required checks before merge
|
|
- Clear rollback path
|
|
- Commit messages that explain operational impact
|
|
|
|
## Configuration Example
|
|
|
|
Example daily workflow:
|
|
|
|
```bash
|
|
git switch main
|
|
git pull --ff-only
|
|
git switch -c feature/update-grafana
|
|
git add .
|
|
git commit -m "Update Grafana image and alert rules"
|
|
git push -u origin feature/update-grafana
|
|
```
|
|
|
|
Before merge:
|
|
|
|
```bash
|
|
git fetch origin
|
|
git rebase origin/main
|
|
```
|
|
|
|
## Troubleshooting Tips
|
|
|
|
### Merge conflicts happen constantly
|
|
|
|
- Reduce branch lifetime
|
|
- Split large changes into smaller reviewable commits
|
|
- Rebase or merge from the default branch more frequently
|
|
|
|
### History becomes hard to audit
|
|
|
|
- Use meaningful commit messages
|
|
- Avoid mixing unrelated infrastructure and application changes in one commit
|
|
- Document the operational reason for risky changes in the pull request
|
|
|
|
### Reverts are painful
|
|
|
|
- Keep commits cohesive
|
|
- Avoid squash-merging unrelated fixes together
|
|
- Ensure deployments can be tied back to a specific Git revision
|
|
|
|
## Best Practices
|
|
|
|
- Prefer short-lived branches and small pull requests
|
|
- Protect the default branch and require review for shared repos
|
|
- Use fast-forward pulls locally to avoid accidental merge noise
|
|
- Keep configuration and deployment code in Git, not in ad hoc host edits
|
|
- Align the Git workflow with deployment automation instead of treating them as separate processes
|
|
|
|
## References
|
|
|
|
- [Git: `gitworkflows`](https://git-scm.com/docs/gitworkflows)
|
|
- [Pro Git: Branching workflows](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows)
|