Git workflows: branches, pull requests and rebase

In short: A Git workflow defines how a team brings changes into a shared project. Most work today with short feature branches and pull requests.

Basic terms

• Branch: a separate line of changes. git switch -c feature/login creates a new one.
• Commit: a saved state with a description. Better several small, sensibly named commits.
• Pull request (PR)/merge request: a request to take a branch into the main branch, including review by others (code review).

The usual process (GitHub Flow)

1. main is always runnable.
2. Branch off main.
3. Change, test, commit, push.
4. Open a pull request; automatic tests run, others look it over.
5. After approval take it into main, delete the branch.

Other models: Git Flow (many long-lived branches, for software with fixed releases) and trunk-based (very short branches, merge constantly, often with feature flags).

Merge, squash or rebase?

• Merge: joins two branches with a merge commit, the history stays as it was.
• Squash: combines all commits of the branch into one, keeping main tidy.
• Rebase: places your commits on top of the latest main, the history becomes straight. Golden rule: never rewrite commits that others already have.

Conflicts

When two people change the same place, Git marks it (<<<<<<<). You decide, keep the right version and commit.

Good habits

Small PRs, clear commit messages, tests before pushing, no secrets in the repository.

See also: Git, Test-Driven Development