SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgitcode-merge-flow

gitcode-merge-flow

Office & productivity

View repository

Updated 10-15 17:19

About this skill

GitCode Open Source Repository Merge Process Automation

Automate the complete process from local commit to merging code into an open source repository. Invoke this Skill when you need to contribute code to a GitCode open source repository.

Configuration Requirements

The following configurations must be confirmed before execution:

  1. GITCODE_ACCESS_TOKEN: GitCode API access token, read from the token file in the project root directory, or provided by the user
  2. Personal Repository: The user's forked personal repository (format:owner/repo, e.g., skywang2/skill-test）
  3. Open Source Repository: The upstream open source repository (format:owner/repo, e.g., lyzin/111）
  4. GITCODE_API_BASE: API base URL, default https://api.gitcode.com/api/v5

Complete Process

flowchart TD
    A["本地提交"] --> B["远程推送"]
    B --> C["提交Issue"]
    C --> D["提交PR"]
    D --> E["触发流水线"]
    E --> F{"存在流水线失败问题?"}
    F -->|是| G["解决流水线失败问题"]
    G --> E
    F -->|否| H["等待代码评审"]
    H --> I{"存在未解决评审意见?"}
    I -->|是| J["解决评审意见"]
    J --> H
    I -->|否| K{"存在新提交解决的评审意见?"}
    K -->|是| E
    K -->|否| L["等待/lgtm和/approve"]
    L --> M["确认合入"]

Execution Steps

Step 1: Pre-checks

  1. Read the token file in the project root directory to obtain GITCODE_ACCESS_TOKEN, and if it does not exist, ask the user for it
  2. Confirm that the current working directory is a git repository (check whether the .git directory exists)
  3. Confirm the following information with the user (ask if not provided):
    • Personal Repository (owner/repo format): e.g., skywang2/skill-test
    • Open Source Repository (owner/repo format): e.g., lyzin/111
    • Target Branch: default master
    • Current Working Branch: default current git branch name
    • Issue Title and Description(refer to the template in references/issue-templates.md )
    • PR Title
    • PR Description(refer to the template in references/pr-template.md )

Step 2: Local Commit

  1. Run git status to check whether there are unstaged changes
  2. If there are changes:
    • Run git add -A to stage all changes (or the files specified by the user)
    • Run git commit -m "<commit_message>" to commit; the commit_message is provided by the user or automatically generated based on the changes
  3. If there are no changes, prompt the user to confirm whether to continue

Step 3: Remote Push

  1. Confirm that the personal repository remote is configured:git remote -v
  2. If there is no personal repository remote, add it:git remote add origin https://gitcode.com/<personal_owner>/<personal_repo>.git
  3. Push to the personal repository:git push origin <current_branch>
  4. If the push fails (e.g., remote rejects), resolve conflicts and retry

Step 4: Submit Issue

Call the GitCode API to create an Issue in theopen source repository.

API Details: Please refer to the "Create Issue" section in references/api.md .

Execution Script: Use the scripts/create_issue.py script.

Record the returned Issue number (thenumber field) to associate it when creating the PR later.

Step 5: Submit PR

Call the GitCode API to create a PR from the personal repository to the open source repository.

API Details: Please refer to the "Create PR" section in references/api.md .

Execution Script: Use the scripts/create_pr.py script.

[Important] Commit Count Limit：

  • If the current branch has more than 1 commit,squash merge must be used
  • Check the number of local commits before creating the PR:git log --oneline origin/main..main
  • If the commit count > 1, prompt the user that squash or rebase is required before creating the PR

Record the returned PR number (thenumber field); all subsequent steps depend on this number.

Step 5.5: Link PR and Issue (optional)

If you need to explicitly link the PR and Issue, you can call the link API.

API details: please refer to the "Link PR and Issue" section in references/api.md .

Execute script: use the scripts/link_pr_issue.py script.

Note: this operation requires repository maintainer permissions, and ordinary contributors may not be able to perform it. When creating the PR, setting close_related_issue: true can automatically link the Issue.

Step 6: Check pipeline status

After the PR is created, the pipeline is triggered automatically. Get the pipeline status andsuspend directly, letting the user confirm on their own.

API details: please refer to the "Get PR details" section in references/api.md .

Execute script: use the scripts/get_pr_details.py script (field mergeable_state.ci_state_passed）。

[Suspension feedback example - Step 6]：

⏸️ 流程已挂起 - 请确认流水线状态

📋 当前状态：
   • PR 链接: https://gitcode.com/{owner}/{repo}/merge_requests/{number}
   • 流水线状态: ✅ 通过 / ❌ 失败 / ⏳ 运行中
   • 合并状态: ✅ 可合并 / ❌ 不可合并

⏳ 请确认：
   请在 PR 页面确认流水线是否通过
   流水线通过后请告知我继续流程
   若流水线失败，请在修复后告知我

📝 流水线失败处理：
   1. 修复代码问题
   2. 执行 git add → git commit → git push 推送新提交
   3. 新提交会自动重新触发流水线
   4. 流水线通过后告知我继续

Step 7: Wait for code review

[Mandatory requirement] Regardless of the repository configuration, you must wait for at least one maintainer to pass the code review before continuing.

Get the PR review comments and check the review status.

API details: please refer to the "Get PR comments" section in references/api.md .

Execute script: use the scripts/get_pr_comments.py script.

Review status determination logic：

  1. If there are no review comments → no one has reviewed yet,force suspend the process
  2. If there are comments with resolved: false → there are unresolved review comments
  3. If all comments are resolved: true → all review comments have been resolved

[Suspension feedback example - Step 7]: When the process is suspended due to waiting for review, you must clearly show the user:

⏸️ 流程已挂起 - 等待代码评审

📋 当前状态：
   • PR 链接: https://gitcode.com/{owner}/{repo}/merge_requests/{number}
   • 流水线状态: ✅ 通过
   • 评审状态: ❌ 暂无评审评论 / ⚠️ 有未解决评审意见

⏳ 等待操作：
   需要至少一个维护者进行代码评审

📝 下一步：
   请联系仓库维护者进行评审
   评审完成后请告知我，我将检查评审状态并继续流程

There are unresolved review comments：

  1. List all unresolved review comments (comment content and author)
  2. force suspend the process
  3. After the user modifies the code, execute git add → git commit → git push to push a new commit
  4. After the new commit is pushed, tell me to recheck

Step 8: Wait for /lgtm and /approve

[Mandatory requirement] Regardless of the repository configuration, you must obtain at least one /lgtm or /approve comment indicating approval before merging.

Check the PR comments to confirm whether anyone has indicated approval to merge via a comment /lgtm or /approve .

Execute script: use the scripts/get_pr_comments.py script.

Determination logic：

  • If no /lgtm or /approve → suspend the process
  • If /lgtm or /approve is found → proceed to Step 9

[Suspension feedback example - Step 8]：

⏸️ 流程已挂起 - 等待 /lgtm 和 /approve 审批

📋 当前状态：
   • PR 链接: https://gitcode.com/{owner}/{repo}/merge_requests/{number}
   • 流水线状态: ✅ 通过
   • 评审状态: ✅ 已通过
   • 审批状态: ❌ 暂无 /lgtm 或 /approve

⏳ 等待操作：
   需要仓库维护者通过评论 /lgtm 或 /approve 表示同意合入

📝 下一步：
   请仓库维护者在 PR 页面评论 /lgtm 或 /approve
   获得审批后请告知我，我将执行合并

Step 10: Confirm merge

After all conditions are met, call the API to merge the PR.

API details: please refer to the "Merge PR" section in references/api.md .

Execute script: use the scripts/merge_pr.py script.

[Important] Merge method：

  • When the number of commits is greater than 1, squash merge must be used
  • merge_pr.py The script will automatically check the number of commits in the PR, and if it is greater than 1, squash will be enforced
  • When the number of commits = 1, merge or squash can be used (squash by default)

After a successful merge:

  1. Inform the user that the PR has been successfully merged
  2. Provide the PR link after the merge
  3. Suggest the user sync the local main branch:git pull upstream master

Suspend and Resume Mechanism

The following steps in the process require waiting for third-party manual operations and willsuspend directly：

Suspension point Reason for waiting Resume condition
Step 6: Pipeline check Requires user confirmation of the pipeline status After the user confirms the pipeline has passed, tell me to continue
Step 7: Wait for review Requires a reviewer to review the code After the user confirms the review is complete, tell me to continue
Step 8: Wait for /lgtm and /approve Requires maintainer approval After the user confirms approval has been obtained, tell me to continue

Behavior when suspended：

  1. Clearly inform the user of the reason for the current suspension
  2. Inform the user what operation needs to be waited for
  3. Provide relevant links (PR page, pipeline page, etc.)
  4. After the user confirms, continue execution from the suspension point

Error handling

  1. API call failure: Check whether access_token is valid, whether the network is working, and whether the parameters are correct
  2. Git operation failure: Check remote repository permissions, whether the branch exists, and whether there are conflicts
  3. PR closed/rejected: Inform the user of the PR status and ask whether to resubmit
  4. Merge conflict: Prompt the user to resolve the conflict and push again

Notes

  1. All API calls use Python's requests library
  2. access_token must not be hardcoded in the code; it must be read from a token file or entered by the user
  3. If authentication is required when pushing code, use the method of embedding the token in the URL:https://oauth2:<token>@gitcode.com/<owner>/<repo>.git
  4. When creating a PR, the head parameter must include the personal repository owner prefix, in the format <owner>:<branch>
  5. When polling the pipeline status, pay attention to frequency control to avoid triggering API rate limiting
  6. Dependencies need to be installed:pip install requests