Gitfence
Start free

Working on pull requests

Push your own branch, open a draft pull request, update it after review, and use Gitfence tools for commit ids, tags and large clones.

Short answer: Push to a branch named <your-gitfence-name>/<change>. The first push opens a draft pull request, and later pushes update it. You can mark it ready, edit it and close it in Gitfence or with MCP.

Steps

  1. Push to your own branch. Replace alice with your Gitfence name and use a short name for the change:
git push origin HEAD:alice/fix-login

The default branch (main) and protected branches cannot be pushed to. Only branches starting with your name are yours.

  1. Open the pull request. The first push opens it as a draft by default, so code owners are not pinged while work is in progress.
  2. Mark it ready for review. Choose Ready for review on the pull request page in Gitfence, use the MCP tool update_pull_request with {"number": N, "draft": false}, or run:
git push -o ready origin HEAD:alice/fix-login

git push -o draft=false also works. Code owners from CODEOWNERS are asked to review when the pull request is ready.

  1. Push review changes. Push new commits normally. If you rebased or amended commits, see Update a pull request after review.

Push options

Pass options with git push -o:

git push -o title="Fix login timeout" -o description="Closes #12\n\nTested with ..." origin HEAD:alice/fix-login
  • title=... sets the pull request title.
  • description=... sets the description. A literal \n becomes a line break.
  • draft and ready set the draft state. draft=false also marks a pull request ready.
  • base=<branch> chooses the base branch.

Title and description

The description starts from the repository's pull request template: .github/pull_request_template.md or another place GitHub looks for it. This happens even when that file is outside your access.

Edit the title and description later with Edit on the pull request page or with update_pull_request. Gitfence keeps a short footer and its review summary below your text.

Text with a credential, a Gitfence token or Gitfence's secret stand-in is refused before it reaches GitHub.

Choose the base branch

git branch -r lists the branches you can see. To target a release branch, pass its name as the base:

git push -o base=release/1.4 origin HEAD:alice/fix-login

Without a base option, pull requests go into the default branch.

Update a pull request after review

Push new commits normally. After a rebase or git commit --amend, force-push your own branch:

git push --force-with-lease origin HEAD:alice/fix-login

Merging the base branch in also works:

git fetch origin && git merge origin/main && git push

Gitfence refuses a force push when it would remove commits on GitHub that your copy does not have yet. Someone else may have pushed, for example with a reviewer's Commit suggestion. Run git fetch origin, then git rebase origin/<your-branch>, and push again.

Gitfence also refuses to drop a commit someone else made to files you cannot edit. Merge the base branch in instead of rebasing.

If you are only behind because someone pushed and you did not rewrite anything, the hint is:

git pull --rebase origin <branch>

A merge that conflicts in files outside your access needs the core team. They can use the Update branch button on GitHub; then run git pull. Every rejection says what to do instead.

Close a pull request and delete a branch

Close your own pull request with the Close button or the MCP tool close_pull_request. Reopen it with the same tool and {"reopen": true}.

Delete your own branch with the Delete branch button, the MCP tool delete_branch, or git:

git push origin --delete alice/fix-login

Deleting the branch of an open pull request closes it on GitHub. You cannot delete main or other people's branches.

Tags

Release tags from GitHub are in your clone. Run git fetch --tags to fetch them. They point at your copy's commits, so git describe --tags works.

Annotated tag messages are filtered like pull request conversations. You cannot push tags.

Commit ids

Commit ids in your clone differ from GitHub's because Gitfence rewrites history for your copy. To translate an id from a review comment, a CI log or a ticket, use one of these:

  • Find a commit on the pull request page.
  • The MCP tool translate_commit with {"commit": "abc1234"}.
  • The same tool without MCP:
sh .git/gitfence-mcp translate_commit '{"commit": "abc1234"}'

Only commits in your copy are answered. A GitHub commit that changed only files outside your access has no commit of its own in your copy; you get the one it was folded into.

Clone a large repository

A shallow first clone works:

git clone --depth 1 <url>

Run git fetch --unshallow later if you need the full history. Partial clone (--filter=blob:none) is not supported yet: the server ignores the filter and sends everything.

Use tools without MCP

Every MCP tool also works from inside your clone:

sh .git/gitfence-mcp <tool> '<json>'

Gotchas

  • On GitHub plans without draft pull requests, the first push opens the pull request as ready and prints a warning.
  • Unknown push options give a warning, not a failure.

Next: AI agents and MCP and code review.

Related guides