3.6 Rebase, PR and Team Workflows

Prerequisites: Remote Repository, Fetch, Pull, and Push

Estimated time: 15 minutes

Reading style: Read the first time for the main idea ("Don't rewrite commits that others depend on") and then read the strategy in detail when participating in collaboration.

You are ready to continue when: you know what rebase rewrites and can choose the appropriate PR merge strategy.

The local-remote experiment explained how data moves, but it hasn't answered how teams review and integrate changes. Next, discuss rebase, PR, and merge strategies on the same commit graph.

Rebase is not a "make history look nice" button

Rebase copies a set of commits to a new base, resulting in new commit IDs:

Original: A---B---C  main
          \
           D---E  topic

After: A---B---C---D'---E'  topic

Interactive rebase can also rearrange, merge, edit messages, or delete commits:

git rebase -i HEAD~3

This interactive command requires at least three commits that are safe to rewrite and a prepared working tree. It does not move topic onto main by itself; the illustrated rebase requires choosing that new base. The editor's todo list determines the operations. Practice on a temporary branch and remember to use git status, git rebase --continue, or git rebase --abort when conflicts occur.

The criterion is dependency: do not rewrite commits that others have based their work on. Personal PR branches that have already been pushed may be rebased after negotiation; when updating the remote, use git push --force-with-lease, and understand that it will still rewrite history. Ordinary --force lacks remote reference checks.

PR is a Hosted Platform Process

A pull request on GitHub or a merge request on GitLab is not a Git object. It brings branch differences, discussions, reviews, automated checks, and merge actions together.

Common workflow:

1. Create short-lived branches after updating the target baseline.
2. Make small, complete commits and test them locally.
3. Push the topic branch and initiate a PR, explaining the motivation, verification, and risks.
4. Continue committing according to review feedback; the same PR is automatically updated.
5. After checks pass, merge according to the repository's rules.

Members of the same repository typically push the topic branch directly; external contributors often fork the repository, naming the original repository upstream. Neither method is a fixed rule; it depends on the permission model.

Three Common Merge Outcomes

• Merge commit: Preserves the branch topology and individual commits.
• Squash merge: Combines the net changes from the PR into a single new commit.
• Rebase merge: Copies the topic commits onto the tip of the target branch.

Choose the one that aligns with your rollback, audit, and release practices. More commits do not automatically produce a more meaningful history. If a merge erases the boundaries that explain the problem and its verification, maintainability can suffer.

Workflow Names Are Not the Rules Themselves

GitHub Flow, Git Flow, trunk-based development, and release branches each have their own use cases. Small teams with continuous deployment often favor short branches and trunk; long release branches may be necessary for multi-version maintenance or strict release windows. Regardless of the choice, clarity is essential:

• Is the main branch required to be deployable?
• Who is allowed to merge, and what checks must be passed?
• How are releases tagged and rolled back?
• How do urgent fixes flow back into other maintenance branches?

When Details Need to Be Checked

• Pro Git: Branches in a Nutshell explains branches in terms of objects and references.
• Pro Git: Rebasing demonstrates how rebase replays commits and the risks involved in public history.
• git-merge official manual provides methods for checking conflicts, --abort, and three-way content.

→ Next Step: Local and Remote Integration Experiment