Git Address and Authentication Instructions

About 407 wordsAbout 1 min

Git Repository Address

The Git repository address uses the repository page URL directly, without adding a .git suffix:

https://cnb.cool/group-path/repo-path

This is the same URL users see when accessing the repository homepage in a browser. The traditional .git suffix format is also supported.

Explanation

Convenience: You can copy the repository URL directly from the browser address bar as the Git address.
Traditional Format Support: The .git suffix format is also supported.
Consistent Functionality: Both formats support full Git operations (cloning, pulling, and pushing) without any functional differences.

Authentication Method

Authentication is performed via an access token:

Username: Always enter cnb.
Password: Enter the access token you have created (supports permission configuration).

For more usage details, please refer to: Access Token.

When connecting with third-party tools (such as IDEs, Git clients), enter the token in the password field and cnb in the username field.

Command Examples

The following example shows the complete workflow of cloning and pushing code using an access token:

# 1. Clone the repository (you will be prompted for credentials if it is private)
git clone https://cnb.cool/group-path/repo-path
cd repo-path

# 2. Commit and push changes
git add .
git commit -m "feat: init"
git push origin main

When prompted for credentials, enter cnb as the username and your access token as the password.

Design Background

Tokens support fine-grained permission control (read/write or read-only) and can be revoked or updated at any time, offering higher security compared to static passwords.
Using the fixed username cnb simplifies authentication, preventing security risks from custom username conflicts or weak passwords.

SSH Not Supported

The platform does not support SSH protocol access for the following reasons:

Higher Security: HTTPS + tokens support short-term validity and hierarchical permissions, making them easier to manage than long-term SSH private keys and revocable at any time.
Lower Barrier to Entry: No need to generate SSH keys or upload public keys, making it suitable for beginners and temporary collaborators.
Anti-MITM: The SSH protocol is vulnerable to man-in-the-middle attacks over the public network, as most users do not verify host key fingerprints on first connection. HTTPS's CA trust chain mechanism resolves this issue automatically.