AchoBeta Pluto System - 2024 Group G - Backend - Re-examination Project
_______ ___ ____ ____ ___________ ______
| __ "\ |" | (" _||_ " |(" _ ")/ " \
(. |__) :)|| | | ( ) : | )__/ \\__/// ____ \
|: ____/ |: | (: | | . ) \\_ / / / ) :)
(| / \ |___ \\ \__/ // |. | (: (____/ //
/|__/ \ ( \_|: \ /\\ __ //\ \: | \ /
(_______) \_______)(__________) \__| \"_____/
Team Management System
- Gin
- Gorm
- Mysql
- Redis
- zap
- viper
- ...
├── cmd Program entry
├── configs Configuration entity classes
├── global Global variables and constants
├── initalize Initialization files
├── internal Core business code
├── log Log file configuration
├── pkg Third-party common packages
├── test Test files
├── utils Utility classes
├── config.yaml.template Configuration file template
├── go.mod
└── go.sum
git config core.hooksPath .githooks
chmod -R -x .githooksBranch naming convention We must confirm:
-
Branch naming should include a name to identify the person responsible.
-
Branch naming must clearly express what problem the branch is working on.
So branch naming must be standardized.
<type>-<name>-<description>For example:
- If it is a branch to develop new functions, the naming convention is as follows
feature-<name>-<feature description>
e.g.: feature-jett-dev_log_system- If it is to fix bugs:
bugfix-<name>-<bug name>
e.g.: bugfix-jett-login_errorAnd other types:
hotfix、release...
Commit message should be written as clearly as possible, and each commit should only do one thing.
<type>(<scope>): <subject>
e.g.: feat: add new api
or: feat(common): add new api# Main type
feat: add new features
fix: fix bug
# Special type
docs: only document-related content has been changed
style: changes that do not affect the meaning of the code, such as removing spaces, changing indentation, adding or deleting semicolons
build: changes to construction tools or external dependencies, such as webpack, npm
refactor: used when refactoring code
revert: the message printed by executing git revert
# Do not use type yet
test: add a test or modify an existing test
perf: changes to improve performance
ci: changes related to CI (Continuous Integration Service)
chore: other modifications that do not modify src or test, such as changes to the build process or auxiliary tools
No period or punctuation at the end
e.g.
feat: add new feature
fix: fix a bugPlease delete useless import. You can also use the shortcut key ctrl + alt + o to automatically delete useless import by setting idea.
- Do not submit any sensitive information, such as
api_key,address, orpasswordin any code. - You can use the configuration file
config.yamlto store some sensitive information, but do not attempt to submit it. Each time you modify the structure ofconfig.yaml, you must also updateconfig.yaml.template. - Never use
git push --forceunless you know what you are doing.
- Project Initialization
- Project Initialization
- Project Directory Structure
- Project Configuration File
- Project Global Variables and Constants
- Project Log Configuration
- Project Initialization File
- Gin Module Setup
- Gin Framework Setup
- Gin Routing Setup
- Gin Middleware Setup
- Gin Parameter Binding
- Gin Response Data Encapsulation
- Login and Registration Module
- Login and Logout functionality
- Auto-login within 30 days
- Force logout
- Display commonly used devices
- Team Homepage Module
- Personal Center
- Points Overview
- Message Module
- Feishu Multi-dimensional Table
- Team Information Module
- Like personal information
- User list
- Add new user
- Admin team structure management
- View and edit user information details