forked from Gitlink/gitlink_help_center
tran1
This commit is contained in:
zjb
parent
0d455dd908
commit
50283cd5f0
|
|
@ -0,0 +1,85 @@
|
|||
# CI/CD Configuration File Validation Guide
|
||||
|
||||
## Configuration File Format
|
||||
GitLink uses `.gitlink-ci.yml` as the CI/CD configuration file, which is automatically validated for syntax when committed.
|
||||
|
||||
## Validation Rules
|
||||
1. **Basic Syntax Check**
|
||||
- YAML format must be correct
|
||||
- Indentation must use 2 spaces
|
||||
- Tab characters are not allowed
|
||||
|
||||
2. **Required Field Validation**
|
||||
```yaml
|
||||
version: 1.0 # Required, specifies configuration file version
|
||||
stages: # Required, defines pipeline stages
|
||||
jobs: # Required, defines specific tasks
|
||||
```
|
||||
|
||||
3. **Field Type Validation**
|
||||
- `version`: string
|
||||
- `stages`: array
|
||||
- `jobs`: object
|
||||
- `script`: string array
|
||||
|
||||
4. **Environment Variable Format**
|
||||
- Variable names can only contain letters, numbers, and underscores
|
||||
- Variable names must start with a letter
|
||||
|
||||
## Error Message Description
|
||||
When there are issues with the configuration file, the system will display error messages in the following locations:
|
||||
1. Immediate feedback during commit
|
||||
2. Build logs in the CI/CD page
|
||||
3. Status checks in merge requests
|
||||
|
||||
## Common Errors and Solutions
|
||||
1. **Indentation Error**
|
||||
```yaml
|
||||
# Incorrect example
|
||||
jobs:
|
||||
build: # Should be indented 2 spaces
|
||||
script:
|
||||
- echo "Hello"
|
||||
```
|
||||
|
||||
2. **Missing Required Fields**
|
||||
```yaml
|
||||
# Correct example
|
||||
version: 1.0
|
||||
stages:
|
||||
- build
|
||||
jobs:
|
||||
build:
|
||||
script:
|
||||
- echo "Hello"
|
||||
```
|
||||
|
||||
3. **Environment Variable Format Error**
|
||||
```yaml
|
||||
# Incorrect example
|
||||
variables:
|
||||
1_invalid: "value" # Variable name cannot start with a number
|
||||
```
|
||||
|
||||
## Configuration File Template
|
||||
```yaml
|
||||
version: 1.0
|
||||
stages:
|
||||
- build
|
||||
- test
|
||||
- deploy
|
||||
|
||||
variables:
|
||||
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
|
||||
|
||||
jobs:
|
||||
build:
|
||||
stage: build
|
||||
script:
|
||||
- mvn compile
|
||||
|
||||
test:
|
||||
stage: test
|
||||
script:
|
||||
- mvn test
|
||||
```
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
# Repository Settings Guide
|
||||
|
||||
## Force Push Settings
|
||||
To enable force push functionality, the following conditions must be met:
|
||||
|
||||
1. **User Permission Requirements**
|
||||
- Must be repository administrator
|
||||
- Or have write permission for specific branches
|
||||
|
||||
2. **Repository Setting Requirements**
|
||||
- Go to repository settings page
|
||||
- Find "Branch Protection" settings
|
||||
- Enable `allow_force_push` option
|
||||
|
||||
### Configuration Steps
|
||||
1. Enter repository settings
|
||||
2. Select "Branch Management"
|
||||
3. Find target branch
|
||||
4. Enable "Allow Force Push" option
|
||||
5. Save settings
|
||||
|
||||
### Notes
|
||||
- Force push may overwrite others' commits
|
||||
- Recommended for use on personal branches
|
||||
- Not recommended for main branch
|
||||
- Backup code before operation
|
||||
|
||||
## Basic Repository Settings
|
||||
|
||||
### Repository Information
|
||||
- Repository name
|
||||
- Repository description
|
||||
- Visibility settings
|
||||
- Default branch
|
||||
|
||||
### Access Control
|
||||
- Collaborator management
|
||||
- Team permissions
|
||||
- Branch protection rules
|
||||
- SSH key management
|
||||
|
||||
### Feature Toggles
|
||||
- Issues functionality
|
||||
- Wiki functionality
|
||||
- Projects functionality
|
||||
- Pages service
|
||||
|
||||
## Storage Limitations
|
||||
- Free account: 1.2GB
|
||||
- Single file limit: 100MB
|
||||
- LFS support: Optional
|
||||
|
||||
## Advanced Features
|
||||
- Repository migration
|
||||
- Repository archiving
|
||||
- Repository templates
|
||||
- WebHook configuration
|
||||
- Deployment keys
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
# Repository Template Guide
|
||||
|
||||
## Accessing Template Repositories
|
||||
There are two ways to access template repositories:
|
||||
|
||||
1. **Via URL Parameter**
|
||||
- Add `?template=true` to the repository URL
|
||||
- Example: `https://gitlink.org/org/repo?template=true`
|
||||
|
||||
2. **Through Interface**
|
||||
- Click "New Repository" button
|
||||
- Select "Create from Template" option
|
||||
|
||||
## Creating Template Repositories
|
||||
|
||||
### Setting a Repository as Template
|
||||
1. Go to repository settings
|
||||
2. Find "Repository Type" option
|
||||
3. Check "Set this repository as template"
|
||||
4. Save settings
|
||||
|
||||
### Template Repository Features
|
||||
- Cannot be directly pushed to
|
||||
- Can be used as template by anyone
|
||||
- Maintains clean commit history
|
||||
- Supports custom initialization configuration
|
||||
|
||||
## Using Templates to Create Repositories
|
||||
|
||||
### Basic Steps
|
||||
1. Visit template repository
|
||||
2. Click "Use this template" button
|
||||
3. Fill in new repository information
|
||||
4. Select branches to include
|
||||
5. Confirm creation
|
||||
|
||||
### Custom Options
|
||||
- Selectively copy branches
|
||||
- Include all tags
|
||||
- Copy Issue templates
|
||||
- Preserve commit history
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Template Repository Structure
|
||||
```
|
||||
template-repo/
|
||||
├── .gitlink/
|
||||
│ ├── ISSUE_TEMPLATE/
|
||||
│ └── PR_TEMPLATE/
|
||||
├── docs/
|
||||
│ └── README.md
|
||||
├── src/
|
||||
├── tests/
|
||||
├── .gitignore
|
||||
└── README.md
|
||||
```
|
||||
|
||||
### Recommended Configuration
|
||||
1. Add detailed README
|
||||
2. Include necessary configuration files
|
||||
3. Provide example code
|
||||
4. Set up Issue and PR templates
|
||||
5. Configure CI/CD templates
|
||||
|
||||
## Notes
|
||||
1. Template repositories should be minimal
|
||||
2. Update template content regularly
|
||||
3. Provide clear usage documentation
|
||||
4. Avoid including sensitive information
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# Merge Request Guide
|
||||
|
||||
## Creating Merge Requests
|
||||
|
||||
### Basic Steps
|
||||
1. Go to source branch
|
||||
2. Click "New Merge Request"
|
||||
3. Select target branch
|
||||
4. Fill in title and description
|
||||
5. Submit merge request
|
||||
|
||||
## Reviewing Merge Requests
|
||||
|
||||
### Code Review
|
||||
1. Review changed files
|
||||
2. Add inline comments
|
||||
3. Submit overall review comments
|
||||
4. Set review status
|
||||
|
||||
### Merge Operation
|
||||
1. Ensure all checks pass
|
||||
2. Scroll below comments
|
||||
3. Find "Merge" button (below comments section)
|
||||
4. Choose merge method
|
||||
- Regular merge
|
||||
- Squash merge
|
||||
- Rebase merge
|
||||
|
||||
## Merge Options Explained
|
||||
|
||||
### Regular Merge
|
||||
- Preserves complete commit history
|
||||
- Creates merge commit
|
||||
- Suitable for feature branch merges
|
||||
|
||||
### Squash Merge
|
||||
- Combines all commits into one
|
||||
- Keeps main branch history clean
|
||||
- Suitable for bug fix merges
|
||||
|
||||
### Rebase Merge
|
||||
- Replays all commits
|
||||
- Creates linear history
|
||||
- Suitable for long-term maintenance branches
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Submitting Merge Request
|
||||
1. Ensure local tests pass
|
||||
2. Update branch to latest
|
||||
3. Resolve conflicts
|
||||
4. Write clear description
|
||||
|
||||
### Review Points
|
||||
1. Code quality
|
||||
2. Test coverage
|
||||
3. Documentation updates
|
||||
4. Performance impact
|
||||
|
||||
### After Merge Operations
|
||||
1. Delete source branch
|
||||
2. Update related Issue status
|
||||
3. Deploy new version (if needed)
|
||||
4. Notify relevant personnel
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Account Management Guide
|
||||
|
||||
## Login Methods
|
||||
GitLink provides multiple convenient login methods:
|
||||
|
||||
### 1. Username and Password Login
|
||||
- Login with registered email/username + password
|
||||
- Support "Remember me" option
|
||||
|
||||
### 2. Mobile QR Code Login
|
||||
1. Click "QR Code Login" on the web login page
|
||||
2. Open GitLink mobile APP
|
||||
3. Click the scan icon in the top right corner of the APP
|
||||
4. Scan the QR code displayed on the webpage
|
||||
5. Confirm login on your phone
|
||||
|
||||
### 3. Third-party Account Login
|
||||
- GitHub account login
|
||||
- GitLab account login
|
||||
- WeChat login
|
||||
|
||||
## Account Security
|
||||
1. **Two-factor Authentication**
|
||||
- Support Google Authenticator
|
||||
- Support mobile phone verification code
|
||||
|
||||
2. **Login History**
|
||||
- View recent login records
|
||||
- Display login IP and device information
|
||||
|
||||
3. **Access Tokens**
|
||||
- Create personal access tokens
|
||||
- Manage token permissions and validity period
|
||||
|
||||
## Account Limitations
|
||||
- Free account repository storage limit: 1.2GB
|
||||
- Single file size limit: 100MB
|
||||
- API call frequency limit: 1000 times per hour
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Keyboard Shortcuts Guide
|
||||
|
||||
## Global Shortcuts
|
||||
- `shift + ?`: Display keyboard shortcuts help panel
|
||||
- `t`: Open quick file search
|
||||
- `s`: Focus search box
|
||||
- `g + c`: Jump to code page
|
||||
- `g + i`: Jump to Issues page
|
||||
- `g + p`: Jump to Pull Requests page
|
||||
|
||||
## Code Browsing
|
||||
- `/`: Search in current repository
|
||||
- `l`: Jump to specific line
|
||||
- `b`: View file history
|
||||
- `y`: Copy permanent link
|
||||
- `i`: Show/hide differences
|
||||
|
||||
## Code Editing
|
||||
- `ctrl + s`: Save changes
|
||||
- `ctrl + f`: Find
|
||||
- `ctrl + g`: Jump to line
|
||||
- `ctrl + /`: Comment/uncomment
|
||||
- `ctrl + space`: Trigger code completion
|
||||
|
||||
## Issues and PRs
|
||||
- `ctrl + enter`: Submit comment
|
||||
- `r`: Reply
|
||||
- `n`: Create new Issue
|
||||
- `m`: Set milestone
|
||||
- `l`: Add label
|
||||
|
||||
## Navigation
|
||||
- `h`: Return to homepage
|
||||
- `g + n`: View notifications
|
||||
- `g + d`: Jump to dashboard
|
||||
- `g + s`: Jump to settings
|
||||
|
||||
## Tips
|
||||
1. Press `shift + ?` on any page to view all supported shortcuts for the current page
|
||||
2. Some shortcuts are only available on specific pages
|
||||
3. Shortcuts may change with platform updates, please refer to the help panel for the most up-to-date information
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# WebIDE User Guide
|
||||
|
||||
## Overview
|
||||
GitLink provides powerful online WebIDE functionality, allowing you to edit and run code directly in your browser without installing a local development environment.
|
||||
|
||||
## How to Access WebIDE
|
||||
1. Enter any code repository
|
||||
2. On the file list interface, click the "Edit" button on the right side of the file
|
||||
3. The system will automatically open the Cloud IDE interface
|
||||
|
||||
## Main Features
|
||||
- Online code editing
|
||||
- Real-time syntax highlighting
|
||||
- Code auto-completion
|
||||
- Integrated terminal
|
||||
- Live preview
|
||||
- One-click commit changes
|
||||
|
||||
## Shortcut Support
|
||||
WebIDE supports various keyboard shortcuts to improve development efficiency:
|
||||
- `Ctrl + S`: Save file
|
||||
- `Ctrl + F`: Search in current file
|
||||
- `Ctrl + Shift + F`: Search in project
|
||||
- `F5`: Run/Debug
|
||||
|
||||
## Notes
|
||||
1. First-time opening WebIDE may require a few seconds for environment initialization
|
||||
2. Recommended to use modern browsers like Chrome or Firefox for the best experience
|
||||
3. Remember to commit changes after editing
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# Issue Management Guide
|
||||
|
||||
## Automatic Issue Closure
|
||||
GitLink supports automatically closing issues through commit messages. Using specific keywords in commit messages can automatically close related issues.
|
||||
|
||||
### Supported Keywords
|
||||
- `fix #123`
|
||||
- `fixes #123`
|
||||
- `fixed #123`
|
||||
- `close #123`
|
||||
- `closes #123`
|
||||
- `closed #123`
|
||||
- `resolve #123`
|
||||
- `resolves #123`
|
||||
- `resolved #123`
|
||||
|
||||
### Usage Example
|
||||
```
|
||||
git commit -m "fix #123: Fixed unresponsive login button"
|
||||
```
|
||||
|
||||
### Multiple Issue Closure
|
||||
You can close multiple issues in one commit message:
|
||||
```
|
||||
git commit -m "fix #123, closes #456: Refactored login module"
|
||||
```
|
||||
|
||||
### Cross-Repository Closure
|
||||
You can close issues in other repositories by specifying the full path:
|
||||
```
|
||||
git commit -m "fix organization/repo#123: Fixed dependency issue"
|
||||
```
|
||||
|
||||
## Manual Issue Closure
|
||||
1. Open the issue you want to close
|
||||
2. Click the status dropdown menu on the right
|
||||
3. Select "Close Issue"
|
||||
4. Optional: Add a closure reason
|
||||
|
||||
## Issue Label Management
|
||||
- Use appropriate labels to categorize issues
|
||||
- Customize label colors and descriptions
|
||||
- Support batch label editing
|
||||
|
||||
## Issue Templates
|
||||
1. Create an `ISSUE_TEMPLATE` folder in the repository's `.gitlink` directory
|
||||
2. Add template files (markdown format supported)
|
||||
3. Choose from templates when creating new issues
|
||||
|
||||
## Best Practices
|
||||
1. Use clear titles to describe problems
|
||||
2. Provide complete reproduction steps
|
||||
3. Attach relevant error logs or screenshots
|
||||
4. Keep issue status up to date
|
||||
5. Use automatic closure syntax to link commits and issues
|
||||
Loading…
Reference in New Issue