Merge a Git feature as one squashed commit

Run git merge --squash feature-x on the target branch to prepare the feature's combined changes, then commit them yourself. The resulting commit has the target's previous tip as its parent; it does not record the feature tip as a merge parent.

Prepare and review the change

Start with a clean working tree and an up-to-date target:

git switch main
git merge --squash feature-x
git diff --cached
git commit -m "Add WeChat Pay and Alipay payment support"

The payment example retains the original feature scope; replace the message with a description of your own change. If conflicts occur, resolve them and stage the corrected files before committing. Run the project's tests against the combined result.

A successful squash does not automatically create the final commit or move HEAD. Avoid mixing unrelated staged changes into the operation.

Use a pull request when that is the team workflow

GitHub's Squash and merge offers the same broad outcome: one new commit on the base branch. Repository settings can restrict the available merge methods. Message defaults, authorship, checks, and platform policy still differ from a local command; follow the review process rather than bypassing it with a direct push.

Retire or rebuild the source branch deliberately

The original feature commits are normally not ancestors of the squashed target. Continuing to merge that old branch can cause repeated comparison of earlier changes or additional conflicts. A practical workflow is to start the next feature from the updated target.

After confirming the integration and any retention requirements:

git branch -D feature-x
git push origin --delete feature-x

These are optional cleanup operations. -D removes the local ref without a merged-history check, and the push deletes the shared remote branch. Verify nobody still needs either ref. Deletion is not required for the squash commit itself to work.

Keep meaningful intermediate commits instead

If reviewers need the development steps, use interactive rebase on a private feature branch to fold small fixups into the relevant commits, then merge using the team's policy. That retains useful milestones rather than reducing the whole feature to one commit.

Preserve original history if you may need it

Create a backup branch or tag before deleting the original ref. Reflogs can help recover recent history, but their retention is finite, and deleting a branch can delete its branch reflog. A pull request page is not a permanent archival guarantee.

See git-merge and GitHub's merge methods.