32 lines
2.3 KiB
Markdown
32 lines
2.3 KiB
Markdown
### 单一`master`分支的Git工作流:
|
||
|
||
1. **仓库初始化**：
|
||
- 在GitHub、GitLab或其他代码托管平台上创建一个新的仓库。
|
||
- 在本地机器上，使用`git clone`命令克隆远程仓库到本地。
|
||
|
||
2. **工作开始**：
|
||
- 进入项目目录，使用`cd`命令。
|
||
- 确保始终处于`master`分支，可通过`git branch`查看当前分支，或使用`git checkout master`切换到`master`分支。
|
||
|
||
3. **日常开发**：
|
||
- 在`master`分支上直接进行文件的修改、新增或删除。
|
||
- 使用`git status`查看工作区的状态，了解哪些文件已被修改或新增。
|
||
- 使用`git add .`或`git add <file>`将改动的文件添加到暂存区。
|
||
- 使用`git commit -m "commit message"`提交改动到本地仓库，记得附上清晰的提交信息。
|
||
|
||
4. **推送到远程仓库**：
|
||
- 使用`git push origin master`将本地`master`分支的改动推送到远程仓库的`master`分支。
|
||
- 如果是首次推送，可能需要添加`-u`参数来建立跟踪关系，如`git push -u origin master`。
|
||
|
||
5. **协作与冲突解决**：
|
||
- 在多人协作时，确保及时拉取远程的最新改动到本地，使用`git pull origin master`。
|
||
- 如果出现冲突，Git会提示冲突文件，需要手动编辑这些文件解决冲突，保留或合并必要的改动。
|
||
- 解决冲突后，再次使用`git add`和`git commit`提交解决冲突后的版本，并推送。
|
||
|
||
6. **代码审查与反馈**：
|
||
- 即使在简化的工作流中，也应该鼓励团队成员相互查看提交的代码，可以通过Pull Request（即使是在同一个分支内）或代码审查工具来进行。
|
||
|
||
7. **版本标记**：
|
||
- 对于重要的里程碑或发布版本，可以使用`git tag`命令打标签，例如`git tag v1.0.0`，然后使用`git push origin --tags`将标签推送到远程仓库。
|
||
|
||
尽管此流程简单，但重要的是要意识到，随着项目复杂度和团队规模的增长，这种单一`master`分支的模式很容易导致混乱和错误。推荐过渡到更成熟的工作流，比如引入`develop`分支作为日常开发分支，以及使用功能分支进行特性开发和隔离，最终通过 Pull Request 合并到主分支，以保持代码质量和团队协作效率。 |