【补充】Gitee的介绍与使用

王如意 · 发表于 2023-8-19 17:35:00

【参考博客地址】

Git使用教程总和 - Chimengmeng - 博客园 (cnblogs.com)
本地项目推送至 Gitee - Chimengmeng - 博客园 (cnblogs.com)

【一】Gitee的介绍

Gitee是一个基于Git版本控制系统的代码托管平台，提供了代码仓库、协同开发、代码管理等功能，适用于个人开发者和团队进行代码管理和项目协作。

【1】使用Gitee的原因

对代码版本进行管理：
- Gitee可以有效地进行代码版本管理
- 能够帮助用户在开发过程中记录不同的代码版本
- 并且轻松回退到某个特定的版本。
协同开发：
- Gitee支持多人协同开发，多个开发者可以并行工作，并在最后合并各自的代码。
- 当多人对同一个文件进行修改时，Gitee会提示冲突，并提供解决方案来解决冲突问题。

【2】版本管理软件：主流就两个

目前，常用的版本管理软件有两种：Git和SVN。

Git：
- Git是目前最广泛使用的版本管理软件，它具有分布式管理的特点。
- 每个开发者都可以拥有一个完整的Git仓库，并且能够独立地进行版本管理，即使远程仓库挂掉，本地代码仍然可用。
- Git具有高速、灵活和强大的分支管理能力。

SVN：
- SVN是一种集中式版本管理软件，它采用客户端-服务器架构。
- SVN仓库位于服务器上，多个客户端通过与服务器交互进行代码管理。
- 如果服务器挂掉，开发者将无法进行提交等操作。

【3】Git与SVN比较

SVN是集中式版本管理软件，而Git是分布式版本管理软件。
SVN采用客户端-服务器架构，Git可以同时作为服务端和客户端。
SVN仓库挂掉后，无法进行操作；Git远程仓库挂掉后，本地仍能独立进行版本管理。
Git具有强大的分支管理能力，更适合团队协作和多人并行开发。
SVN相对较老，Git目前被广泛使用，成为主流版本管理工具。

【二】Gitee的安装

要安装Gitee，首先需要安装Git。
打开Git官方网站：https://git-scm.com/download/win
在官网上下载适用于Windows操作系统的Git安装程序。
下载完成后，运行安装程序，按照提示进行下一步的安装。
安装完成后，打开命令行终端（如cmd），输入命令git version，如果显示了版本信息，则说明Git安装成功。

【三】git,github，gitee，gitlab

【1】git

版本管理软件，可以做版本管理

Git是一种分布式版本控制系统，用于跟踪代码的修改历史和协作开发。
它主要用于管理项目代码的版本，并可以方便地进行团队合作和协同开发。

【2】GitHub

它是一个网站：https://github.com/ 全球最大的开源代码管理仓库，git远程仓库

运营商不让访问

GitHub是一个基于Git的远程代码托管平台，是全球最大的开源代码管理仓库。
- 它提供了强大的版本控制功能，并且允许用户将自己的代码库与其他人共享。
- 用户可以创建、展示和共享他们的项目，也可以与其他开发者合作开发项目。
需要注意的是，在某些情况下，运营商可能会限制对GitHub网站的访问。
- 这可能由于网络政策、地理位置或其他原因造成。

【3】Gitee

中国最大的开源代码管理仓库（私有仓库）

https://gitee.com/kitego/hashmart

Gitee是中国最大的开源代码管理仓库，也是一个基于Git的远程代码托管平台。
- 与GitHub类似，Gitee提供了代码托管、版本控制和协作开发等功能。
- 除了开源项目外，Gitee还支持私有项目，使开发者可以更加灵活地管理自己的代码。
例如
- 我们可以在Gitee上找到一个名为"hashmart"的项目
- 路径为https://gitee.com/kitego/hashmart。

【4】GitLab

公司内部搭建自己的远程仓库，只在公司内部用，外网访问不到(到公司用这个多)

GitLab是一个用于企业内部的自托管Git仓库管理系统，它允许企业在内部搭建自己的远程代码仓库，并提供对项目代码的版本控制和团队协作功能。
与GitHub和Gitee不同，GitLab的访问限制在公司内部，外部网络无法直接访问。

【四】Gitee工作流程

【五】Gitee的3个区

git 分3个区(三个区的来回操作)

工作区：存放代码的文件夹，只要工作区文件发生变(修改，新增，删除)

暂存区：工作的变更，提交到暂存区 git add . 把工作区变更提交到暂存区

版本库：暂存区内容，放到版本库，被版本管理---》git commit -m ''

在Git中，代码管理涉及三个主要的区域：工作区、暂存区和版本库。
- 工作区：
  - 工作区即存放代码文件的目录。
  - 在工作区进行修改、新增或删除文件时，这些变更尚未被Git跟踪或纳入版本控制管理。
- 暂存区：
  - 当工作区的代码发生变更后，需要通过将这些变更提交到暂存区来准备进行版本控制。
  - 通过使用命令git add，我们可以将工作区的变更添加到暂存区。
  - 例如，运行命令git add .会将工作区中的所有变更加入到暂存区中。
- 版本库：
  - 版本库是Git中存储所有代码历史记录的地方。
  - 一旦变更被提交到暂存区，我们可以使用git commit命令将暂存区的内容添加到版本库中，形成一个新的版本。
  - 每次提交都会生成一个唯一的版本号，并且保留了该提交的元数据信息，例如作者、提交时间等。
  - 通过这种方式，我们可以追踪和管理代码的不同版本。
综上所述，Git的三个区域之间的操作流程可以描述如下：
- 首先，我们在工作区进行代码的修改。
- 然后，使用git add命令将工作区的变更添加到暂存区。
- 最后，通过git commit命令将暂存区的内容提交到版本库中，形成一个新的版本。
- 这样，我们就可以记录代码的历史变更并进行版本控制管理。

【六】Gitee常用命令

【1】新建仓库文件夹

在使用Gitee之前，首先需要创建一个仓库文件夹。通过以下步骤创建：
- 在所需位置新建一个文件夹。
- 右键选择"git bash here"，打开命令窗口（等同于cmd）。
- 在命令窗口中可以执行Linux命令来操作Windows系统。

【2】初始化仓库

初始化仓库是指使用Git进行版本控制的前提条件。
在当前文件夹下执行以下命令进行初始化：

git init

在当前文件夹下就会创建出 .git 文件夹，这个就会被git管理

如果希望在当前路径下创建一个名为"xxx"的文件夹并使用Git管理
- 可以执行以下命令:

git init xxx

在当前路径下创建 xxx文件夹，并用git管理xxx文件夹

【3】查看仓库状态

git status

如果是红色，表示在工作区有文件发生了变化，但尚未提交到暂存区。

如果是绿色：表明，表示暂存区有文件等待提交到版本库。

如果没有东西，表示当前目录下所有文件均已被Git管理。

【4】工作区提交到暂存区

将工作区的变更提交到暂存区可以通过以下命令实现：

git add  .

当前目录下所有变更都提交

如果只想提交当前目录下的"1.txt"文件的变更，可以执行以下命令：

git add 1.txt

只提交当前目录下 1.txt这个文件的变更

【5】暂存区提交到版本库

把暂存区内容，提交到版本库（只要被版本管理的东西，你尽管操作，后期都能回退回来）

git commit -m '我的第一次，提交'

如果没有设置用户信息，将无法进行提交。

因此，在使用Git之前，必须设置全局或局部用户配置。

全局配置会被应用到所有的仓库，而局部配置只会在当前仓库生效。

【6】查看版本信息

通过以下命令可以查看提交过的版本信息（包括作者和注释）：

git log

除了使用git log命令外，还可以使用git relog命令对版本信息进行更详细的查看。

git relog

【补充】配置用户(必要)

（1）全局配置

以后所有的版本提交时，都用这个用户和邮箱
- 配置信息将保存在C:\Users\git\.gitconfig文件中。
- 保存位置因个人而有差异直接找gitconfig

git config --global user.name '用户名'
git config --global user.email '用户邮箱'

（2）局部配置

只在当前仓库生效--》仓库路径下 .git 文件夹下config文件中配置的

git config user.name '用户名'
git config user.email '用户邮箱'

【七】Gitee其他命令

【1】将工作区变更回退

使用以下命令将工作区的变更回退：

git checkout .

【2】将暂存区内容拉回工作区（由绿色变红色）

使用以下命令将暂存区的内容拉回工作区：

git reset HEAD

【3】从版本库拉回到暂存区（版本库内容回退，变绿色）

使用以下命令将版本库的内容回退到暂存区，并指定上一个版本：

git reset --soft  1603edf06d7d302ba50c22373c963af15725eda5

【4】将版本库退回到工作区（版本库内容回退，变红色）

使用以下命令将版本库的内容回退到工作区，并指定上一个版本：

git reset --mix 1603edf06d7d302ba50c22373c963af15725eda5

【5】将版本库直接完整回退到工作区

使用以下命令将版本库完全回退到工作区，这将删除所有新增的内容：

git reset --hard 1603edf06d7d302ba50c22373c963af15725eda5

【6】回退到某个特定版本

使用以下命令可以将版本库回退到指定版本：

git reset --hard 19f5891

【八】Gitee忽略文件

在项目开发过程中，有时希望某些文件或文件夹不被Git管理，可以通过忽略这些文件和文件夹来实现。
在仓库的根目录下创建一个名为.gitignore的文件，并在其中指明需要忽略的文件和文件夹。例如：

-.idea 
-node_models
-xx

需要写个忽略文件 .gitignore 必须叫它，没有后缀名
- 在里面写忽略的文件或文件夹，写法如下

.idea   # 忽略idea文件夹及其下面所有的文件
test.txt  # 忽略仓库中所有的test.txt
/test.txt # 忽略当前路径下的test.txt
a/test.txt # 只忽略当前路径下a文件夹下test.txt
*x*：名字中有一个x的都会被过滤（*代表0~n个任意字符）

【九】Gitee分支操作

企业Gitee分支方案

主分支（Master/Main Branch）：

主分支是最重要的分支，用于保存稳定的、可发布的代码版本。

它包含已经过测试和验证的功能和修复代码。

主分支通常用于生产环境部署。

开发分支（Development Branch）：

开发分支用于日常的代码开发和功能添加。

团队成员可以在开发分支上创建个人分支，并在其上进行开发工作。

当某个功能或一组功能完成并经过测试后，可以将这些更改合并到开发分支中进行集成测试。

bug分支（Bug Branch）：

bug分支用于修复软件中的错误和漏洞。

当发现问题时，可以从主分支或开发分支中创建bug分支，解决问题后再将更改合并回主分支或开发分支中。

确保在修复bug之前优先处理紧急性较高的问题。

分支注意的地方

定期合并主分支到开发分支，以确保开发分支中包含最新的稳定代码。

创建和命名分支时，使用有意义的名称，描述该分支的目的和内容。

在合并分支之前，进行代码检查和测试，确保不会引入新的问题。

使用code review等方式来审查其他开发者的更改，提高代码质量和团队合作。

【1】查看分支

本地

git branch

本地和远程

git branch -a

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch
* master

【2】创建分支

git branch dev

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch dev

查看全部分支

git branch -a

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch -a
  dev
* master

【3】切换分支

git checkout dev

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git checkout dev
Switched to branch 'dev'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$

查看全部分支

git branch -a

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git branch -a
* dev
  master

【4】删除分支

不能删除当前所在的分支

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git checkout master
Switched to branch 'master'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch -d dev
Deleted branch dev (was a23b19d).

查看当前全部分支

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch -a
* master

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$

【5】本地合并分支

（1）主分支master初始化

文件内容

.git
master2.txt
master1.txt

提交主分支

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git add .

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git commit -m '主分支提交'
[master 54bee1b] 主分支提交
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename a.txt => master1.txt (100%)
 create mode 100644 master2.txt

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git status
On branch master
nothing to commit, working tree clean

（2）创建子分支 dev

创建分支

git branch dev

（3）子分支dev添加自己的记录

切换分支

git checkout dev

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git branch dev

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git checkout dev
Switched to branch 'dev'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$

新增一个文件 dev1.txt,加入一行内容
- this is a test msg from dev1

git add .

git commit -m 'dev分支提交'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git status
On branch dev
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        dev1.txt

nothing added to commit but untracked files present (use "git add" to track)

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git add .

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git commit -m 'dev分支提交'
[dev c36201c] dev分支提交
 1 file changed, 1 insertion(+)
 create mode 100644 dev1.txt

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git status
On branch dev
nothing to commit, working tree clean

（3）子分支修改主分支文件数据

修改master1.txt 加入内容
- this is a change from dev in master1

git add .

git commit -m 'dev修改master1文件'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git status
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   master1.txt

no changes added to commit (use "git add" and/or "git commit -a")

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git add .

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git commit -m 'dev修改master1文件'
[dev c014630] dev修改master1文件
 1 file changed, 1 insertion(+)

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git status
On branch dev
nothing to commit, working tree clean

如果现在切换到主分支，在原来的文件中新增加的东西看不到

（4）子分支与主分支对比

当我们切换到子分支时可以看到如下

切换到主分支

git checkout master

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (dev)
$ git checkout master
Switched to branch 'master'

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$

（5）将子分支dev合并到主分支master上

注意要分清楚到底是合在谁的身上
- 要切换到 master 分支进行合并

git merge dev

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git merge dev
Updating 54bee1b..c014630
Fast-forward
 dev1.txt    | 1 +
 master1.txt | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 dev1.txt

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$

可以看到主分支的文件也和子分支的一样了
- 主分支保持最新，子分支可以继续开发相应的功能

【6】线上合并分支

（1）前提

假设存在一个主分支（master）和一个开发分支（dev）。
- 开发人员在开发分支上完成了开发工作。
- 现在需要将开发分支合并到主分支。

（2）创建并拉取分支

本地创建dev分支并推送到远程：
- 若远程还没有dev分支，在本地创建该分支（git checkout -b dev）。
- 然后将本地的dev分支推送到远程仓库（git push origin dev）。
远程创建dev分支并拉取到本地：
- 在远程仓库的网页界面上，点击相应的操作来创建dev分支。
- 在本地使用命令拉取远程的dev分支（git pull origin dev）。
- 使用git checkout dev切换到dev分支。此时，你就能看到最新的dev分支代码。

（3）操作数据

前提：本地和远程仓库都存在master和dev分支

若要在本地的dev分支上删除文件或进行其他修改操作：
- 将删除的文件或修改的内容提交到本地版本库（git commit -a -m "删除文件"）。
- 将本地的dev分支代码推送到远程仓库（git push origin dev）。

（4）远程分支合并

团队成员创建一个Pull Request（PR）或Merge Request（MR）请求。
该请求表示将dev分支合并到master分支。
组长或审核人员对该请求进行审核。
若审核通过，即同意合并，dev分支就会被合并到master分支。

【十】Gitee远程仓库

我们要协同开发，代码要提交到远程仓库

可以使用gitee，github，gitlab

本文以gitee为例

注册账号过程可以参考最上边的地址博客
- 本地项目推送至 Gitee - Chimengmeng - 博客园 (cnblogs.com)
- 这个博客是简述建仓库的过程

Linux的GPL协议简解

Linux是一个开源操作系统，其源代码是公开的。

Linux内核使用GNU通用公共许可证（GPL）授权。

GPL是自由软件基金会（FSF）制定的一种版权协议，旨在保护软件自由和开放源代码的原则。

GPL协议有以下几个主要特点：

自由分发：

使用GPL许可证的软件可以自由地复制、分发和修改，无论是个人还是组织都可以这样做。

修改和衍生作品：

根据GPL许可证，如果你修改了GPL许可证下的软件，你必须将修改后的版本发布为开源项目，并以GPL许可证许可给其他人使用。

源代码的可用性：

GPL要求开发者提供软件的全部源代码，以便用户能够查看和修改源代码。

不得添加限制：

使用GPL许可证的软件，不能添加额外的限制，即不能对用户施加任何限制，保障用户的自由。

状态的保持：

如果你在使用GPL许可证下的软件的时候，必须维持该软件的GPL许可证状态，不得更改或删除它。

总之，GPL协议确保了软件的自由和开放性，使得用户能够自由地使用、复制和修改软件，以及与其他人共享这些修改和衍生作品。

这种协议促进了开源社区的发展和合作。

创建一个新的空仓库进行测试

简易的命令行入门教程:

Git 全局设置:

git config --global user.name "用户名"
git config --global user.email "自己的邮箱"

创建 git 仓库:

mkdir test-warehouse
cd test-warehouse
git init 
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin 仓库地址
git push -u origin "master"

已有仓库?

cd existing_git_repo
git remote add origin 仓库地址
git push origin "master"

我们本地已有仓库

【1】切换到指定仓库文件夹

cd F:\桌面\测试git

【2】添加远程仓库链接

git remote add origin 自己的远程仓库地址

git remote add origin 仓库地址

origin 可以自定义自己的名字，但是一般第一个都叫 origin

【3】查看已有远程仓库

git remote

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git remote add origin 仓库地址

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git remote
origin

【4】删除本地和远程仓库的关系

git remote remove origin

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git remote remove origin

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git remote

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$

【5】推送本地仓库

把本地仓库中所有的内容，提交到远程仓库

git push origin master

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$ git push origin master
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (11/11), 1.02 KiB | 260.00 KiB/s, done.
Total 11 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.4]
To https://gitee.com/chi-meng/test-warehouse.git
 * [new branch]      master -> master

Administrator@WIN-20230103NMO MINGW64 /f/桌面/测试git (master)
$

第一次使用 Git 推送本地仓库时，会弹出对话框需要输入用户名和密码

输入过一次就会被保存

本地凭据保存位置

控制面板

用户账户

凭据管理器

Windows凭据

即可查看到自己所有的凭据

git凭据叫

git:https://gitee.com

远程仓库上传成功
- 注意这里的每个文件后面的时间是和本地仓库的时间是一样的
- 比如昨天做的更改推到了本地仓库，今天才将本地仓库推到远程，时间会显示昨天的

【补充】使用SSH方式连接Gitee远程仓库

（1）生成公钥和私钥：

在本地电脑上生成公钥和私钥是首要步骤。
- 可以通过以下命令在用户家目录的 .ssh 文件夹下生成两个文件
  - 一个用于存放公钥（id_rsa.pub）
  - 一个用于存放私钥（id_rsa）：

ssh-keygen -t rsa -b 4096

按照提示输入生成公钥私钥的路径和密码，也可以直接按回车使用默认路径和无密码。

（2）将公钥配置到Gitee网站：

登录到Gitee网站，并在用户设置中找到SSH公钥配置页面（通常为 https://gitee.com/profile/sshkeys）。将刚才生成的公钥文件（id_rsa.pub）的内容复制到该页面的输入框中，并保存配置。
修改本地Git仓库的remote地址：
- 在本地Git仓库中，使用以下命令将远程地址修改为SSH方式连接：

git remote set-url origin git@gitee.com:<用户名>/<仓库名>.git

其中，<用户名>是你在Gitee网站上的用户名，<仓库名>是你要连接的远程仓库名。
至此，你已经完成了通过SSH方式连接Gitee远程仓库的配置。

从现在开始，你可以免密提交代码到Gitee远程仓库。

在每次提交时，Git会使用你的私钥进行身份验证，确保只有拥有对应公钥的机器才能访问和修改仓库内容。

【补充】在公司使用GitLab的使用流程

[1]一到公司，你会收到GitLab账号和密码
- 如果还没有账号，你需要注册，并等待管理员审核通过。
[2]使用提供的账号和密码登录GitLab
- 在初始登录时，你可能看不到任何项目。
[3]配置SSH链接：
- 在本地生成公钥和私钥。
- 你可以使用以下命令在本地生成公钥和私钥文件：

ssh-keygen -t rsa -b 4096

这将生成公钥文件（id_rsa.pub）和私钥文件（id_rsa）。

然后，将公钥文件的内容添加到你的GitLab账户上

具体方法如下：

a. 复制刚才生成的公钥文件（id_rsa.pub）的内容。

b. 登录到GitLab网站，并找到用户设置中的SSH密钥配置页面（通常为 https://gitlab.com/profile/keys）。

c. 将公钥内容粘贴到该页面的输入框中，并保存配置。

[4]领导会将你添加为某个仓库的开发者，并给你一个仓库地址。
- 你可以点击这个地址，进入你即将参与开发的项目。
[5]在本地使用以下命令将项目克隆到本地：

git clone <仓库地址>

其中，<仓库地址>是你领导给你的项目地址。

[6]使用一个IDE（比如PyCharm）打开刚刚克隆的项目
- 开始进行代码编写。
[7]当你需要将代码提交到本地仓库时
- 可以执行以下命令：

git add <文件名>

其中，<文件名>是你要提交的文件名

如果你要提交全部文件，可以使用 . 表示全部文件。

[8]接下来执行以下命令
- 将提交保存到本地仓库：

git commit -m "<提交信息>"

其中，<提交信息>是你对本次提交的详细描述

通常包括修改内容、修复的问题等信息。

[9]在提交前
- 最好先执行以下命令从远程仓库拉取更新：

git pull origin master

这个命令会将远程仓库中的最新代码同步到你的本地仓库。

如果拉取过程中遇到冲突，需要解决冲突后再提交。

[10]解决完冲突后
- 重新执行 git add 和 git commit 命令
- 将合并后的代码提交到本地仓库。
[11]最后使用以下命令将本地代码推送到远程仓库：

git push origin master

这将把你的本地代码推送到你所在的项目的主分支上（通常为master分支）。

这样，你就完成了基于GitFlow工作流的代码开发和提交流程。
记住，在每次提交前，都要先拉取最新代码，并及时解决冲突，确保代码的整体一致性和可维护性。

【十一】Gitee协同开发

【1】仓库成员角色

管理员（Admin）:
- 管理管理员角色权限
- 可设置和修改仓库访问权限
- 可添加和删除仓库成员
- 可进行仓库设置和配置
开发者（Developer）:
- 具备完整的代码读写权限
- 可以提交新的代码、创建分支、合并代码和推送到仓库
- 可以访问和拉取仓库的源代码
- 可以参与团队的协作开发
观察者（Observer）:
- 只有只读权限，无法修改代码
- 可以克隆仓库、查看源代码和提交历史
- 适合那些对项目感兴趣但不需要直接参与代码编写的人员
报告者（Reporter）:
- 只具备查看和提交问题（Issue）的权限
- 可以报告bug、提出建议或参与讨论
- 适合非开发人员或用户提供反馈的角色

【2】成为开发成员

仓库管理员创建仓库：
- 仓库管理员（也可称为领导）使用Git服务提供商（如GitHub、GitLab等）创建一个新的仓库，并进行相应的初始化设置。
邀请成员：
- 仓库管理员在仓库设置中找到"成员"或"Collaborators"选项，并添加您的用户名或电子邮件地址作为一个新的成员。
- 根据您所提供的信息，系统将向您发送一封邀请邮件。
登录账号：
- 按照邀请邮件中的指示，您需要登录您的Git服务提供商账号（如果没有账号，则需要先注册一个）。
- 确保使用的是您收到邀请邮件的地址来登录。
访问仓库：
- 一旦您登录成功，您可以点击邀请邮件中提供的链接或者在Git服务提供商的界面上找到相关的仓库。
- 您应该能够看到仓库的名称和简介等信息。
作为开发成员，您通常会获得相应的权限，可以克隆代码、提交更改、创建分支、合并代码等。
请注意，具体的权限可能因为管理员的设置、仓库类型以及相关规定而有所不同。
如果有需要，您可以根据您的角色和项目要求进一步调整和配置您的权限。

【3】多人协同开发

多人协同开发是指多个开发人员在同一项目中合作开发，共同完成软件开发任务

版本控制系统：
- 使用版本控制系统（如Git）进行代码管理是多人协同开发的基础。
- 每个开发人员通过克隆仓库到本地，进行开发工作并提交代码更改。
- 通过版本控制系统，可以轻松地管理、合并和追踪各个开发人员的代码变动。
分支管理：
- 在多人协同开发中，使用分支来隔离不同开发任务是一个常见的做法。
- 每个开发人员可以在自己的分支上工作，完成任务后再将分支合并到主分支或其他适当的分支上。
- 这样可以确保各个任务的代码不会相互干扰，并且方便代码审查和合并。
代码审查：
- 代码审查是确保团队成员之间代码质量和一致性的重要步骤。
- 通过代码审查，团队成员可以共同审查彼此的代码并提供反馈和建议。
- 这有助于发现潜在的问题、改进代码结构和风格，并提高整体代码质量。
沟通与协作：
- 多人协同开发需要团队成员之间良好的沟通和协作。
- 使用协作工具（如Slack、Microsoft Teams等）进行实时聊天和讨论，共享进度和问题，并及时解决团队中出现的任何困难。
- 此外，定期的会议和迭代计划也是确保团队在同一方向上前进的重要方式。
自动化测试与持续集成：
- 引入自动化测试和持续集成工具可以加快开发流程并提高团队的效率。
- 自动化测试可以帮助捕获潜在的代码错误和缺陷，而持续集成则允许团队成员频繁地将其代码更改集成到共享代码库中，并进行自动化构建和测试。
文档和注释：
- 良好的文档和注释对于多人协同开发至关重要。
- 在代码中添加清晰的注释，以解释复杂的逻辑和设计思路。
- 另外，编写详细的开发文档、API文档和用户文档有助于其他开发人员了解项目的目标、架构和使用方法。

【十二】Gitee仓库冲突问题

【1】问题引入

在多人协同开发的情况下，使用Gitee仓库时可能会遇到两种冲突情况：
- 多人在同一分支上修改了同一个地方的代码，导致冲突。
- 在合并分支时发生了冲突。
下面将详细回答如何处理这两种冲突。

【2】多人修改同一内容冲突

多人统一分支开发，修改了同样的代码

在多人协同开发中，如果多个人在同一分支上修改了相同位置的代码，会导致冲突。下面是具体的处理步骤：
- 其他人修改了文件1.txt的第四行并提交了更改。
- 本人也在此分支上修改了文件1.txt的第四行，并执行了以下操作
```
git add .
git commit -m ' 注释'
git pull origin master
```

执行上述操作后，会出现冲突标记：

<<<<<<< HEAD
- 我的代码
=======
- 别人的代码
>>>>>>>

处理冲突
- 选择要保留的代码。可以选择删除自己的代码、删除别人的代码，或者同时保留两部分代码。

完成代码冲突解决后，再次提交更改

git add .
git commit -m ' 解决冲突'
git pull origin master

大原则，多人同一分支开发，如果尽量避免冲突，要不停的拉去代码

在多人协同开发时，为了避免冲突，建议团队成员之间保持经常的代码拉取操作，及时更新本地代码到最新版本。

【3】分支合并冲突

当进行分支合并操作时，如果在不同分支上对相同位置的代码进行了修改，就会发生冲突。下面是处理分支合并冲突的具体步骤：
新建一个名为dev的分支，并切换到该分支：
```
git branch dev
git checkout dev
```
- 在dev分支上修改文件1.txt的最后一行，添加了内容
  - "我dev新增了一条消息"
```
git add .
git commit -m '注释'
```
切换回主分支操作：
```
git checkout master
```
- 在主分支上也对文件1.txt的最后一行进行修改，添加了内容
  - "我master新增了一条消息"
```
git add .
git commit -m '注释'
```
在进行分支合并操作时
- 由于两个分支对同一部分代码进行了修改，会引发冲突，类似于以下样式：
```
<<<<<<< master
我的代码
=======
别人的代码
>>>>>>> dev
```
解决冲突，选择要保留的代码。
- 根据需求，可以选择删除自己的代码、删除别人的代码，或者合并两者的代码。
完成冲突解决后，执行以下操作提交更改：
```
git add
git commit -m '解决冲突'
```

【4】思路分析和图解

在Git中，合并冲突指的是在尝试将两个不同的分支（通常是一个主分支和一个特性分支）合并时发生的冲突。

这种情况发生在两个分支的相同位置上修改了同一部分内容，Git无法确定应该选择哪个版本作为最终结果，因此需要手动解决这个冲突。

假设我们有一个主分支（master branch）和一个特性分支（feature branch）。
```
A --- B --- C          <- master
       \
        D --- E       <- feature
```
特性分支基于主分支创建，并独立进行开发，然后在某个时刻想要将特性分支的更改合并回主分支。
当执行以下命令时，Git会自动将特性分支的更改合并到主分支，并且如果没有冲突，整个过程非常平滑：
```
$ git checkout master
$ git merge feature
```
但假设在主分支 C 和特性分支 E 中都对同一个文件进行了修改，Git 将无法自动决定所需保留的更改。
当执行合并操作后，Git 将显示合并冲突的提示信息，并将冲突部分标记出来。这些标记表明了主分支和特性分支在同一处产生了冲突。
```
$ git merge feature
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.
```

您可以使用文本编辑器打开文件，查看冲突的部分。通常，合并冲突会显示为特殊标记，如：

<<<<<<< HEAD
//代码来自于当前所在分支（此处为主分支）
=======
//代码来自于合并的分支（此处为特性分支）
>>>>>>> feature

改变文件中的内容以解决冲突。您需要决定使用哪个版本或两者的组合，并且删除特殊标记后保存文件。
解决冲突后，使用以下命令告诉Git冲突已经解决：
```
$ git add file.txt
```

最后，提交您的更改：

$ git commit -m "Resolved merge conflict"

现在，您已成功解决合并冲突，并将特性分支的更改合并回主分支。

【十三】远程仓库回滚

远程仓库回滚是指将远程仓库中的代码版本退回到过去的某个状态。
在进行远程仓库回滚之前，我们首先需要将本地代码回滚到目标状态。
- 可以使用以下命令将本地代码回滚到最初状态：

git reset --hard 最初状态

其中，最初状态是要回滚到的代码版本号。

如果想要回滚到一个特定的提交版本，可以使用如下命令：

git reset --hard 88aa1e**fa288af495ab6c283b139b7f7f0a237a

其中，88aa1e**fa288af495ab6c283b139b7f7f0a237a是目标提交版本的哈希值。

完成本地代码回滚后，为了将回滚后的代码同步到远程仓库，需要使用强制推送（force push）的方式将修改后的本地代码强行推送到远程仓库。
- 执行以下命令即可：

git push origin master -f

这里的origin是远程仓库的别名，master是主分支的名称，-f 表示进行强制推送。

需要注意的是，在进行强制推送之前，请确保本地版本库的内容是最新的。
- 如果本地代码和远程仓库存在差异，可以先执行以下命令进行代码的拉取：

git pull

这样可以确保本地代码库和远程仓库保持同步。

总结：

远程仓库回滚的步骤包括将本地代码回滚到目标状态，强制推送修改后的本地代码到远程仓库，并确保本地版本库内容是最新的。

【十四】Gitee工作流

【1】介绍

Git工作流是指在使用Git进行版本控制时，团队成员共同协作、管理代码的一种方式。

【2】常见的Git工作流

常见的Git工作流包括Git Flow、Feature Branch、Forking Workflow等。
在这其中，Git Flow是一种非常流行的工作流模型，但我们并没有采用它。
Git Flow工作流以主分支（Master）和开发分支（Develop）为核心，通过创建不同的分支来完成不同的任务。
- 具体而言，Git Flow包含以下几个主要分支：
Master分支：
- 用于存放稳定版本的代码，部署到生产环境中的代码都来自于该分支。
Develop分支：
- 用于存放开发阶段的代码，开发人员在该分支上进行功能开发。
Feature分支：
- 基于Develop分支创建，用于开发新功能或解决某个问题，完成后会合并回Develop分支。
Release分支：
- 在开发完成后，将Develop分支上的代码合并到Release分支上进行预发布的准备工作，如进行测试、修复Bug、文档更新等。
Hotfix分支：
- 用于紧急修复线上问题，基于Master分支创建，修复后需要合并到Master分支和Develop分支。

【3】优缺点

上述Git Flow工作流的优点在于明确分工，能够有效管理各个阶段的开发与发布，并且稳定的Master分支可以保证生产环境的稳定性。
然而，对于我们团队而言，我们没有采用Git Flow工作流。
- 可能是因为我们存在不同的实际需求、团队规模、开发方式等综合因素所致。
- 在团队协作中，我们会根据具体情况来选择适合的分支方案和工作流程，以最大限度地提高效率和代码质量。

【十五】git pull和git fetch

git pull 从远程仓库拉取代码：从远程获取最新版本并merge到本地

git fetch 从远程仓库拉取代码：会将数据拉取到本地仓库 - 它并不会自动合并或修改当前的工作

git pull =git fetch +merge

【1】git pull

git pull 是一个 Git 命令，用于从远程仓库获取最新的代码并将其合并到本地仓库和当前分支。
- 它的操作可以简洁地概括为 "获取最新代码并合并"。具
- 体而言，git pull 的执行过程包含以下几个步骤：
首先，它会自动调用 git fetch 命令，从远程仓库下载最新的提交历史和分支数据至本地仓库。
然后，它会自动调用 git merge 命令，将远程分支的更新内容合并到当前所在分支。

【2】git fetch

git fetch 是一个 Git 命令，用于从远程仓库获取最新的代码更新并将其保存在本地仓库，但不会自动将其合并到当前分支。
- 它的操作可以简洁地概括为 "获取最新代码"。
- 具体而言，git fetch 的执行过程包含以下几个步骤：
首先，它会从远程仓库下载最新的提交历史和分支数据至本地仓库，但不会影响当前工作区或当前分支的内容。
下载完成后，你可以通过查看远程分支的更新情况或者切换到特定的分支来查看最新代码，但它不会自动对当前分支进行任何修改或合并。

【3】总结

综上所述，可以得出如下结论：
- git pull 是一个高级别的命令，它包含了 git fetch 和 git merge 的功能。执行 git pull 会自动从远程仓库获取最新代码，并将其合并到当前分支。
- git fetch 是一个低级别的命令，它只负责从远程仓库获取最新代码更新，并保存在本地仓库，不会自动对当前分支进行修改和合并。

【4】使用

在实际使用中，如果你想快速更新本地仓库并将更新内容自动合并到当前分支，可以使用 git pull 命令。
如果你只希望获取最新代码而不进行自动合并，或者想要查看远程仓库的更新情况后再决定是否进行合并，可以使用 git fetch 命令。
根据具体需求选择合适的命令可以更好地管理代码更新和分支合并。

【十六】变基(rebase)

1 多个提交记录整合成一个

2 解决多次合并分叉问题

【1】介绍

变基（rebase）是 Git 中常用的操作，用于将一个分支的提交历史整合到另一个分支上。

【2】主要作用：

多个提交记录整合成一个：
- 使用变基可以将多个连续的提交记录整合成一个更简洁的提交。
- 这样可以减少不必要的提交记录，保持提交历史的整洁性。
- 通过变基，我们可以在当前分支上应用其他分支的提交记录，并将它们合并为一个新的提交。
解决多次合并分叉问题：
- 在多人协作或者长时间开发过程中，经常会出现分支的提交历史出现多次合并分叉的情况。
- 这些分叉可能给代码的管理和维护带来一定的复杂性。
- 通过变基操作，我们可以将多个分叉的提交历史整理成单一的线性提交历史，从而清晰地表示代码的演进过程，减少分叉带来的混乱。

【3】执行变基的过程

首先，选择目标分支（一般是要合并到的分支）。
然后，选择源分支（一般是要整合的分支）。
执行变基命令（如 git rebase）来将源分支的提交记录逐个应用到目标分支上。
如果在应用提交记录的过程中发生冲突，需要手动解决冲突。
最后，源分支的提交记录会被移动到目标分支上，形成一个新的、整洁的提交历史。

【4】注意事项

需要注意的是，如果你在变基过程中修改了提交历史，并且这些提交已经推送到远程仓库，那么在执行 git push 后可能会遇到一些问题。
因此，在对公共分支（如 master 或 main）执行变基操作时需要谨慎，并且与团队进行充分的沟通和协商。

【5】总结

通过变基操作，我们可以将多个提交记录整合成一个，使提交历史更加简洁；同时，也可以解决多次合并分叉带来的问题，使分支的演进过程更加清晰易懂。
但在执行变基操作时，需谨慎处理可能引起冲突的情况，并避免对公共分支进行不恰当的变基操作。

【十七】Pycharm操作Gitee

安装并配置Git：首先，确保您已经安装了Git，并配置好您的Git全局设置（用户名和电子邮件地址）。
- 您可以在终端中使用以下命令来检查是否已经安装Git：
```
git --version
```
如果Git已经安装，则会输出Git的版本信息。
在Gitee上创建一个仓库：
- 打开Gitee的网站，并在账户界面上创建一个新的仓库，详细填写仓库的信息，如仓库名称、描述等。
在PyCharm中设置您的Gitee账户：
- 打开PyCharm，点击顶部菜单栏的"File"（文件）-> "Settings"（设置），在弹出的窗口中找到"Version Control"（版本控制），选择"Git"。在右侧的"Global settings"（全局设置）中，填写您的Gitee账户信息，包括用户名和密码。
将本地项目关联到Gitee仓库：
- 在PyCharm中，打开您要关联到Gitee的项目。然后，点击顶部菜单栏的"VCS"（版本控制）-> "Import into Version Control"（导入到版本控制），选择"Share project on GitHub"（在GitHub上共享项目）。
填写Gitee仓库信息：
- 在弹出的对话框中，选择"Git"作为版本控制系统，并填写您在Gitee上创建的仓库的URL，点击"Share"（共享）按钮。
提交更改到Gitee仓库：
- 在PyCharm的右下角状态栏中，可以看到当前项目的Git状态。您可以通过点击状态栏中的"Commit"（提交）按钮来提交更改。
- 在提交对话框中，选择要提交的文件或文件夹，并填写提交信息，然后点击"Commit & Push"（提交并推送）按钮将更改推送到Gitee仓库。
更新从Gitee仓库拉取代码：
- 在PyCharm的右下角状态栏中，点击"Update Project"（更新项目）按钮，以从远程Gitee仓库拉取最新的代码更改到本地。

【补充】为开源项目贡献代码

为开源项目贡献代码是一种积极参与开源社区的方式

[1]首先
- 我们需要在GitEE上找到一个开源项目
- 选择一个你感兴趣或熟悉的项目。
[2]在该开源项目的页面上
- 点击"Fork"按钮，将该项目的代码库复制一份到你的个人仓库中。
[3]在你的个人仓库中
- 可以使用以下命令将代码库克隆到本地：

git clone <你的个人仓库地址>

其中，<你的个人仓库地址>是你的个人仓库在GitEE上的地址。

[4]在本地克隆的代码库中，进行代码修改。
- 你可以根据你的需求或者发现的 bug 来进行相应的修改工作。
- 修改完成后，使用以下命令将修改后的代码提交到你的个人仓库：

git add .
git commit -m "提交说明"
git push origin <分支名>

其中，<分支名>是你想要提交代码的分支名称。

[5]在你的个人仓库中成功提交代码后
- 你可以创建一个 pull request（PR），将你的修改申请合并到原始项目的作者的仓库中的特定分支。
- 具体操作方式为，进入你的个人仓库的页面，在页面上找到"Pull Request"按钮，点击后创建一个新的 PR。
- 在 PR 中详细描述你的修改内容和目的。
[6]创建 PR 后，原始项目的作者将会收到通知。
- 作者会审查你的修改，并在确认没有问题后，将你的修改合并到原始项目的特定分支中。
[7]一旦作者审核通过并将你的修改合并到原始项目中
- 恭喜你成为了该开源项目的贡献者。
[8]总结：为开源项目贡献代码的步骤包括
- fork项目到个人仓库
- 在本地仓库进行代码修改
- 将修改后的代码提交到个人仓库
- 创建 PR 并提交到作者的仓库中
- 经过作者审核和合并后成为贡献者

【补充】Gitee的介绍与使用

【参考博客地址】

【一】Gitee的介绍

【1】使用Gitee的原因

【2】版本管理软件：主流就两个

【3】Git与SVN比较

【二】Gitee的安装

【三】git,github，gitee，gitlab

【1】git

【2】GitHub

【3】Gitee

【4】GitLab

【四】Gitee工作流程

【五】Gitee的3个区

【六】Gitee常用命令

【1】新建仓库文件夹

【2】初始化仓库

【3】查看仓库状态

【4】工作区提交到暂存区

【5】暂存区提交到版本库

【6】查看版本信息

【补充】配置用户(必要)

（1）全局配置

（2）局部配置

【七】Gitee其他命令

【1】将工作区变更回退

【2】将暂存区内容拉回工作区（由绿色变红色）

【3】从版本库拉回到暂存区（版本库内容回退，变绿色）

【4】将版本库退回到工作区（版本库内容回退，变红色）

【5】 将版本库直接完整回退到工作区

【6】回退到某个特定版本

【八】Gitee忽略文件

【九】Gitee分支操作

【1】查看分支

【2】创建分支

【3】切换分支

【4】删除分支

【5】本地合并分支

（1）主分支master初始化

（2）创建子分支 dev

（3）子分支dev添加自己的记录

（3）子分支 修改 主分支文件数据

（4）子分支与主分支对比

（5）将子分支dev合并到主分支master上

【6】线上合并分支

（1）前提

（2）创建并拉取分支

（3）操作数据

（4）远程分支合并

【十】Gitee远程仓库

简易的命令行入门教程:

【1】切换到指定仓库文件夹

【2】添加远程仓库链接

【3】查看已有远程仓库

【4】删除本地和远程仓库的关系

【5】推送本地仓库

【补充】使用SSH方式连接Gitee远程仓库

（1）生成公钥和私钥：

（2）将公钥配置到Gitee网站：

【补充】在公司使用GitLab的使用流程

【十一】Gitee协同开发

【1】仓库成员角色

【2】成为开发成员

【3】多人协同开发

【十二】Gitee仓库冲突问题

【1】问题引入

【2】多人修改同一内容冲突

【3】分支合并冲突

【4】思路分析和图解

【十三】远程仓库回滚

【十四】Gitee工作流

【1】介绍

【2】常见的Git工作流

【3】优缺点

【十五】git pull和git fetch

【1】git pull

【2】git fetch

【3】总结

【4】使用

【十六】变基(rebase)

【5】将版本库直接完整回退到工作区

（3）子分支修改主分支文件数据