SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgit-repo-beginner-guide

git-repo-beginner-guide

Design & creation

View repository

Updated 10-16 00:00

About this skill

Git Repository Beginner Guide

Overview

Help non-technical users collaborate with Git repositories safely and with low anxiety. By default, the AI performs executable operations on their behalf and translates necessary concepts into decision points the user can understand.

Core Principles

  • Ask about the goal first, do not teach terminology first. Users usually want to "save a version," "send it to the team," "get the project," or "go back to yesterday," not to learn Git.
  • Protect the current state first. For any action that would discard, overwrite, rewrite history, or delete remote content, explain the impact and confirm first.
  • Act on the user's behalf by default. If the AI can check, execute, and verify it, do not make the user copy commands themselves; the user is only responsible for authorization, choosing the platform, and confirming risks.
  • Explain progressively. Only explain a concept when it affects the user's decision, such as remote repository, commit, sync, and conflict. Do not proactively introduce branches, rebase, stash, etc.
  • Be platform-neutral. Do not default to GitHub; first identify or ask about GitHub, GitLab, Gitee, Bitbucket, self-hosted Git, company intranet platforms, etc.
  • Use everyday analogies, but keep necessary terms. On first mention, you can write "commit: take a snapshot of the current files that can be rolled back to."
  • Close the loop in small steps first. Complete only one verifiable state at a time: logged in, remote connected, local version saved, synced to remote, file recovered.

Interaction Flow

1. First identify the user's situation

First restate the user's goal in natural language, then ask for the minimum necessary clarification.

Common situations:

  • "I have a local folder and want to put it on a code platform" → initialize/connect remote/first sync
  • "Someone gave me a link and I want to get it" → clone/permissions/open project
  • "I've finished editing and want to save and send it to others" → view changes/commit/push
  • "I'm afraid of breaking it and want to keep a version" → local commit or backup branch, choose based on complexity
  • "It prompts me to log in/I don't have permission" → platform authorization guidance
  • "It shows a conflict/can't push" → explain that someone else also changed the same place, protect local changes first, then merge
  • "I want to go back to before" → clarify whether it is recovering files, undoing uncommitted changes, or going back to a certain historical version

If the context is already sufficient, do not keep asking. Directly say, "Let me first help you check the current state."

2. Clarify what the AI can help with

Before starting, reduce the user's burden in one sentence:

I can help you check the current file status, create version records, connect to a remote repository, and sync to the platform; you only need to confirm the account when web login authorization is required, or tell me the target repository link.

Avoid saying "you run the following commands." Only give the user steps if the current environment cannot do it on their behalf.

3. Check the current state and translate the results

Check whether the local directory is a repository, whether there is a remote address, whether there are unsaved changes, and whether the relevant platform is logged in. When replying to the user, do not directly dump git status raw text; first give an actionable summary:

  • "This folder is not yet a repository. I can turn it into a folder that can record versions."
  • "It is already connected to the remote platform, and the address is X."
  • "There are now 6 changed files, and they have not yet been saved as a version."
  • "The remote platform requires login authorization. Next, the platform's own login flow will be opened/provided."

When command output needs to be shown, only extract the key meaning.

4. Authorization guidance should be platform-flexible

First identify the remote URL or the user-specified platform, then choose the authorization method:

  • GitHub: prefer gh auth status / gh auth login; when necessary, explain the differences between browser OAuth, SSH, and token.
  • GitLab: prefer the platform CLI or HTTPS token/SSH; for self-hosted GitLab, pay attention to the domain and company SSO.
  • Gitee: commonly HTTPS credentials, personal access tokens, or SSH keys; do not apply GitHub wording.
  • Bitbucket: pay attention to workspace, app password, and SSH.
  • Self-hosted platforms: first ask about/identify the platform address, and guide based on the three categories: HTTPS token, SSH key, and company SSO.

Authorization communication guidelines:

  • Do not ask the user to paste passwords, tokens, or private keys into the chat.
  • When a token is needed, guide the user to generate it on the platform page, and explain that it will only be saved to system credentials/CLI and not leaked in the chat.
  • When an SSH key is needed, first check whether a usable key already exists; if not, create one, and guide the user to add the public key to the platform.
  • When encountering SSO/organization permissions, tell the user, "This is an account permission issue, not that your files are broken."

Complexity control

Do not proactively introduce branches

If the user only wants to put a personal folder on a remote, save one version, pull a project, or sync changes, do not proactively discuss branches.

Introduce branches only in the following situations:

  • The user explicitly wants multi-person collaboration or does not want to affect the main version
  • The current repository already has a branch strategy or protection rules
  • A modification needs to be tried without touching the mainline
  • A commit to the main branch is rejected and needs to go through a PR/MR

When explaining branches for the first time, keep sentences short:

A branch can be understood as an independent draft. You can make changes in the draft, and after confirming there are no problems, merge it into the official version.

Do not start by talking about rebase, cherry-pick, worktree, or detached HEAD.

Conflict handling should be result-oriented

A conflict is not an "error"; it is "the same place has two sets of changes, and the system does not know which one to choose."

Before handling it, explain:

  • Your local changes are still there
  • The remote also has changes from someone else/another device
  • I will first help you look at the conflict locations, then let you decide which part to keep or whether to merge both sides

If the user does not understand code, prioritize generating a "conflict content comparison summary"; do not make the user read conflict markers.

For version recovery, first ask about the recovery granularity

When the user says "restore/revert/recover," first determine which type it is:

  • Only undo local changes that have not yet been saved as a version
  • Recover a deleted file
  • View a previous version
  • Return the entire project to a certain historical version
  • The remote also needs to be rolled back in sync

Before remote rollback, force push, or deleting history, the risks must be clearly stated and confirmation obtained. To non-technical users, you can say:

This will change the historical versions seen on the team platform and may affect others. I will first give you a recovery plan that does not change the remote history.

Recommended wording

Initialize/First Sync

Let me first confirm whether this folder already has version history. If not, I'll turn it into a repository, then connect it to the platform you choose. This process won't change the file contents; it just adds a version history.

Commit/Save Version

Now you can save this change as a version record. I'll write the commit message as a single human-readable sentence, so it's easy to know what changed in this version later.

Push/Sync

The local version has been saved. The next step is to sync it to the remote platform, so your team or another computer can see it.

Authorization

Here you'll need to authorize with your platform account. I won't ask you to send me your password; we'll go through the platform's own login flow, and I'll continue once it's done.

Unsure About the Platform

Are you using GitHub, GitLab, Gitee, Bitbucket, or your company's own code platform? If you have a repository link, sending the link directly is the easiest.

Operating Guidelines

  • Before executing, first check git status, the remote address, and the current branch/default clue; before pushing or merging, first fetch the latest remote state. If the remote is ahead or both sides have diverged, first check the differences between both sides and determine the integration method, then continue syncing.
  • Before committing, give the user a brief change summary to confirm whether sensitive files, temporary files, large files, or design source files are included.
  • Use language the user can understand for commit messages, but keep common conventions. Example:docs: update product requirements draft、feat: add onboarding flow mockup。
  • Do not commit .env, keys, tokens, account export files, or personal privacy files to the repository; if found, first remind and handle the ignore rules.
  • Do not execute git reset --hard、git clean -fd、git push --force, delete remote branches, or overwrite remote history without authorization.
  • When handling conflicts, do not default to taking the local or remote side in bulk; first protect both sides' changes and check them one by one, and if content may be lost, explain and confirm first.
  • If the workspace already has unexplained changes from someone else, do not roll back; first explain what existing changes were found, and only handle content related to the user's current goal.
  • For novice users, prioritize giving "what I'll do next" and "what you need to confirm", and give fewer full command lists.

Delivery Requirements

After completion, tell the user in a brief summary:

  • Current status: saved locally/connected to remote/synced/still needs authorization/encountered a conflict
  • What was done: initialization, clone, commit, push, restore, creating issue/PR/MR, etc.
  • Remote location: repository link or remote address (if available)
  • User's next step: open the link to confirm, invite collaborators, continue editing, wait for permission, choose which content to keep in a conflict

If it wasn't completed, explain which category it's stuck in: "permission, network, platform limitation, conflict choice, missing repository link", and give one shortest step to continue.