使用git+github进行多人协同开发全过程详细步骤手把手教学！分支管理，合并分支从此不再迷惑~

工作区（Working Directory）：
- 这是你在本地仓库目录下直接可见的文件和文件夹，也就是你正常开发和修改代码的地方。
- Git 会监控这些文件和文件夹的状态，判断它们是未跟踪的、修改过的还是已暂存的。
暂存区（Staging Area/Index）：
- 是一个临时区域，用来记录你添加（git add）的文件更改，这些更改会在提交（git commit）时进入本地仓库的历史记录。
- 暂存区是虚拟的，它实际存储在 .git/index 文件中。
本地分支和提交历史（.git 文件夹）：
- .git 文件夹是 Git 的核心，包含了所有版本管理信息，例如分支、标签、提交历史、配置等。
- 本地分支就是 .git/refs/heads 文件夹中的记录，比如 .git/refs/heads/master 表示 master 分支的引用。

本地仓库和远程仓库的关系

本地仓库：是你机器上的文件和 .git 元数据的集合，它完全独立于远程仓库。
远程仓库：是托管在 Git 服务器上的仓库（例如 GitHub、GitLab 或你的公司内部服务器），通常通过 origin 这个默认名称来引用。

本地和远程仓库的文件、分支等是通过以下命令同步的：

从远程拉取（git fetch 或 git pull）：将远程的更新下载到本地。
推送到远程（git push）：将本地分支的更改上传到远程仓库。

你提到的文件夹

例如，你的路径是：xxx/xxx,就是你的本地 Git 仓库目录。在这个目录下，应该有：

.git 文件夹：存储版本管理数据。
其他项目相关的文件和文件夹：你在开发中修改的代码。

只有在这个路径中操作 Git 命令，它才会生效，因为 Git 需要依赖 .git 文件夹中的元数据。

总结

本地仓库 = 当前项目文件夹下的 .git 文件夹 + 工作区文件。

当你执行 Git 命令时（比如 git checkout 或 git branch），Git 实际上是在操作 .git 文件夹中的数据，确保工作区文件的状态与版本管理保持一致。

什么是暂存区？

暂存区 (staging area) 是 Git 用来存放将要提交的更改的地方。它是 Git 工作流程中很重要的一部分，主要用来控制哪些改动会被提交到仓库。以下是它的作用和与回退的关系：

暂存区的作用

选择性提交：
- 暂存区允许你精确选择要提交的文件或更改，而不是一次性提交所有改动。
- 比如，你修改了 a.cpp 和 b.cpp，但只想提交 a.cpp，你可以只把 a.cpp 暂存。
记录提交内容：
- 当你运行 git commit 时，Git 只会提交暂存区中的内容，工作目录中的其他改动不会被提交。
文件状态跟踪：
- Git 用暂存区跟踪文件从“修改”到“准备提交”的状态。

回退和暂存区的关系

暂存区可以配合回退操作，但它不是唯一的工具。Git 的回退机制主要涉及以下几个方面：

1. 撤销暂存区的内容（回退到工作区）

如果你已经把改动添加到暂存区，但想撤回（不提交），可以用：

git restore --staged <file>或git reset HEAD <file>

作用：让文件从“暂存区”回到“工作目录”，但文件的实际改动内容不会丢失。

2. 撤销工作区的内容（还原到上一次的版本）

如果想丢弃工作目录中的改动，让文件回到仓库中的最新版本：

git restore <file>

作用：直接覆盖工作区中的文件，慎用！

3. 回滚到某个提交

如果已经提交，但发现问题需要回滚，可以用：

git reset --hard <commit-hash>

作用：回滚到指定提交，并覆盖暂存区和工作区内容。

工作目录、暂存区、仓库的关系

工作目录：你实际操作的文件。修改代码时的内容存在这里。
暂存区：准备提交的地方，记录你挑选的改动。
本地仓库：你用 git commit 把暂存区的内容提交到这里。
远程仓库：通过 git push 把本地仓库的提交上传到远程。

总结

暂存区是提交的中间站，你可以选择哪些改动需要提交。
如果要回退，可以根据需要选择回退暂存区、工作目录，或者整个提交。
熟练使用 git restore 和 git reset，可以灵活控制代码版本和状态。🎯

git push

git push 后面需要加上目标远程仓库和分支名，具体的格式是：

git push <remote> <branch>

<remote>：指的是远程仓库的名字，通常是 origin（默认的远程仓库名）。
<branch>：指的是你要推送的本地分支名。

推送当前分支到远程仓库：如果你在本地的 test 分支上并且想要将该分支推送到远程仓库 origin，可以运行：
```
git push origin test
```
推送所有本地分支到远程仓库：如果你想要推送所有本地分支到远程仓库，可以使用：
```
git push --all origin
```
推送标签（tag）到远程仓库：如果你有标签需要推送，可以使用：
```
git push origin <tag-name>
```
推送并设置上游分支（首次推送）：如果这是你第一次将一个本地分支推送到远程仓库，且需要设置追踪信息（即将本地分支与远程分支关联），可以使用：
```
git push --set-upstream origin test
```

分支基本操作

1. 拉取并合并远程分支 (`git pull`)

git pull 会将远程仓库指定分支的更改拉取到本地，并尝试自动合并：

git pull origin <branch_name>

例如：

git pull origin master 会将远程仓库 origin 中的 master 分支拉取并与本地的 master 分支合并。

2. 只拉取远程更改，不合并 (`git fetch`)

git fetch 会将远程仓库的更改拉取下来，但不会自动合并，只是将远程分支更新到本地：

git fetch

然后，如果你需要合并某个分支到当前分支，可以使用：

git merge origin/<branch_name>

例如：

git merge origin/master 会将远程仓库 origin 中的 master 分支合并到当前本地分支。

3. 推送本地更改到远程 (`git push`)

如果你在本地进行了更改并希望将其推送到远程仓库：

git push origin <branch_name>

例如：

git push origin master 会将本地的 master 分支推送到远程仓库。

4. 查看当前本地分支与远程分支的状态 (`git status`)

在进行合并或者推送之前，可以使用 git status 来检查当前的工作状态，例如：

git status

这会显示你当前所在的分支、工作区的修改状态、以及是否有需要推送或者拉取的更改。

5. 查看所有远程分支 (`git branch -r`)

如果你想查看所有远程分支，可以使用：

git branch -r

新建本地分支并追踪远程分支

1. 从远程仓库拉取新分支并追踪

假设你在远程仓库 origin 中有一个分支（比如 feature），但本地没有该分支。你可以通过以下命令创建本地分支并设置追踪远程分支：

git checkout -b <local_branch_name> origin/<remote_branch_name>

2. 使用 `git fetch` 获取远程分支

如果你不确定远程仓库有哪些分支，可以先使用 git fetch 拉取所有远程分支的更新，但不合并到本地分支：

git fetch

执行 git fetch 后，你可以查看所有远程分支：

git branch -r

然后，你可以按照第一步的命令来新建并切换到本地分支。

3. 将本地分支与远程分支建立追踪关系

如果你已经在本地创建了一个分支，并且想让它追踪远程的某个分支，可以使用以下命令：

git branch --set-upstream-to=origin/<remote_branch_name> <local_branch_name>

例如，你在本地创建了 feature 分支，并想让它追踪远程 origin/feature 分支：

git branch --set-upstream-to=origin/feature feature

4. 创建一个本地分支并推送到远程仓库

如果你已经在本地创建了一个分支，并且希望将它推送到远程仓库，并且在推送时同时设置追踪关系，可以使用 -u 选项：

git push -u origin <local_branch_name>

这会将该本地分支推送到远程仓库 origin，同时设置追踪关系，以后你可以在该分支下直接使用 git push 和 git pull。

6. 查看本地和远程分支的差异 (`git log`)

你可以通过 git log 来查看本地分支和远程分支的提交差异。例如，查看本地 master 和远程 origin/master 之间的差异：

git log origin/master..master

7.切换 Git 分支时提示有未提交的更改

在切换 Git 分支时提示有未提交的更改，说明当前分支存在未提交的修改或新增文件。Git 不允许切换分支，以免未提交的更改导致数据丢失或冲突。以下是解决方法：

1. 检查未提交的更改

运行以下命令，查看具体有哪些修改：

git status

红色文件：表示未添加到暂存区的更改。
绿色文件：表示已添加到暂存区但未提交的更改。

2. 解决方法

根据需求选择以下操作之一：

方法 1：提交更改

将更改提交到当前分支：

git add . git commit -m "保存当前更改"

然后切换分支：

git checkout <目标分支>

方法 2：暂存更改（使用 Stash）

如果不想提交更改，可以将更改保存到 Git 的临时存储区（Stash）：

git stash

然后切换分支：

git checkout <目标分支>

切换回原分支后，可以恢复暂存的更改：

git stash pop

方法 3：放弃更改

如果确认更改不需要保存，可以直接放弃未提交的修改：

放弃工作区的所有更改：
```
git checkout . 
```
删除未跟踪的文件或目录：
```
git clean -fd 
```
然后切换分支：
```
git checkout <目标分支> 
```

方法 4：强制切换分支

如果不关心当前未提交的更改，可以强制切换分支，但这样会丢失未提交的内容：

git checkout -f <目标分支>

3. 注意事项

如果更改非常重要，建议备份或提交后再切换分支，以免数据丢失。
使用 git stash 时，可以创建多个存储记录，使用 git stash list 查看所有存储项。

本地文件的存储方式

单份工作区文件 Git 的所有分支共享一份工作区文件。每次切换分支时，Git 会根据分支的内容更新工作区中的文件。
- 你在本地文件夹中看到的文件，就是当前检出的分支对应的文件。
- 如果你切换到另一个分支，Git 会更新这些文件，变成新分支的状态。
Git 仓库的管理 Git 仓库实际上存储了项目的所有历史记录和所有分支的内容，但它们是以一种高效的方式压缩保存的（.git 文件夹中）。
- 本地分支的内容实际上都保存在 .git 文件夹中。
- 你只需要一个项目文件夹，Git 会在你切换分支时动态修改工作区文件，不需要为每个分支保存独立的文件夹。

实际工作中的文件情况

假设你的项目包含三个分支：master、feature-A 和 feature-B。

文件在分支间的共享机制
- 如果某个文件在所有分支中都相同，那么它不会被修改。
- 如果某个文件在分支间有差异，Git 会根据切换的分支动态更新工作区中的文件。
场景演示
- 在 master 分支：你看到的是 master 分支的文件内容。
- 切换到 feature-A 分支：
```
git checkout feature-A
```
  Git 会替换工作区中的文件，使之变为feature-A分支的内容。
- 切换回 master 分支：
```
git checkout master
```
  工作区文件再次恢复为master分支的内容。

是否需要多份文件？

答案：不需要。Git 的分支机制非常高效：

文件夹只需要一份，你无需为每个分支单独创建文件夹。
Git 会自动切换工作区的文件内容，你只需要专注于当前分支。

重要注意事项

未提交的更改 如果你修改了文件但尚未提交，切换分支可能会遇到问题，Git 会提示你“工作区中有未提交的更改”：
- 解决办法是先提交更改，或将更改暂存到“暂存区”：
```
bash复制代码git stash
git checkout <branch>
git stash pop
```
多个副本的极端情况 在少数情况下，如果你需要同时处理多个分支的文件，可以通过创建项目文件夹的副本来操作（如 Gem_master_v1 和 Gem_master_v2），但这通常不是必要的，Git 分支已经足够应对多数场景。

典型多人协作流程示例

团队远程仓库中有一个 master 分支，每个人都拉取 master 到本地。
每个人基于master创建自己的分支：
```
git checkout -b feature-branch master
```
在个人分支上开发并提交代码：
```
git commit -m "完成某功能"
```
推送到远程的个人分支：
```
git push origin feature-branch
```
提交合并申请，将个人分支的内容合并到 master。
代码审查通过后，项目管理员或开发者将其合并到远程的 master 分支。

实例演示：多人协作开发同一项目全过程

异常情况（需要手动处理）：

如果你遇到了 fatal: 'master' is not a commit，说明本地的 master 无效，解决方法如下：

确认本地没有有效的 master 分支：
- 查看本地分支：
```
git branch
```
  如果master不在列表中，说明本地没有master
同步远程分支到本地：
- 获取远程分支的所有更新：
```
git fetch origin
```
- 基于远程origin/master
  
  创建一个本地master分支：
```
git checkout -b master origin/master
```
  这会在本地创建一个与远程同步的master分支。
创建新分支：
- 在本地master基础上创建你的新分支：
```
git checkout -b new master
```

为什么正常情况下不需要手动创建本地 `master`？

因为 Git 的设计允许在创建分支时隐式使用远程分支作为基准。例如，git checkout -b new master 本质上会：

检查本地 master 是否存在。
如果本地不存在，就去远程仓库查找 origin/master 并拉取其内容。

但是当本地或远程配置出现异常时（如本地分支未跟踪远程分支、远程仓库不完整等），Git 无法完成上述隐式步骤，因此会报错。

在github上点击pull request提交

上面是在远程合并（一般都在远程合并），也可以从远程拉到本地再合并然后传回远程（多此一举）。

最后关于冲突，

分好工，大家在自己的branch，写分给自己的文件一般不会产生冲突。

在Git中，冲突通常发生在以下几种情况：

1. 合并不同分支时

不同分支有相同的文件改动：
- 当你尝试将 new 分支与 master 分支合并时，如果两个分支上对同一个文件做了不同的改动，Git就会提示你处理冲突。
- 例子：
  - master 分支对 config.txt 文件做了修改（增加一行内容），而 new 分支也对 config.txt 文件做了不同的修改（删除了一行内容）。
  - 在合并时，Git无法确定使用哪个版本，因而会产生冲突。

2. 推送本地分支到远程时

在远程已经有新提交的情况下推送：
- 如果你在 new 分支上工作，并且已经做了一些提交，但在推送到远程之前，其他开发者也在 new 分支上工作并做了新的提交，那么推送时会发生冲突。
- 例子：
  - 你在 new 分支上提交了一些改动后准备推送，但此时远程的 new 分支已经被其他开发者更新。
  - 当你推送时，Git会发现你的提交历史与远程的不同，无法自动合并，所以会提示你解决冲突。

3. 分支历史不一致时

使用 git pull 时：
- 当远程仓库和本地仓库有不同的提交历史，使用 git pull 就可能会产生冲突。
- 例子：
  - 你在 new 分支上做了一些工作，但在 master 分支上有新的提交。如果你 git pull origin master，Git会发现这两个分支历史之间不一致，并提示你解决冲突
  - 详细解释：
    1. 远程和本地历史不一致：
      - git pull 命令实际上是两个命令的组合：git fetch 和 git merge.
      - git fetch 会从远程仓库获取更新，但不会直接合并到本地。它只是将远程仓库的最新内容下载到本地。
      - git merge 将本地分支与远程分支合并。在这一步，Git会检查两者的历史提交，寻找共同的祖先。如果无法找到，则意味着两个分支的历史并没有关联，或者已经被重新初始化了。
    2. 发生冲突的情况：
      - 例子：假设你在 new 分支上工作了一段时间，做了一些提交（A、B、C），这时 new 分支的历史是独立的。与此同时， master 分支有一些新的提交（D、E、F）。
      - 当你在new分支上运行
        
        git pull origin master 时：
        
        Git 会将远程 master 分支的内容下载到本地。
        
        然后，它会尝试将本地 new 分支与远程 master 分支合并。
        
        因为这两个分支的历史没有交集（可能是由于不同的开发人员操作或某些历史变化），Git无法自动决定合并哪个版本。
        
        因此，它会提示你手动解决冲突，因为它无法直接合并两者。
    3. 解决冲突的步骤：
      - Git会标记有冲突的文件，并且会告诉你具体冲突在哪些文件中。你需要手动合并这些文件，处理冲突后，才能完成 git pull。
      - 解决冲突后，你需要确认合并：git commit 解决掉冲突，并将修改提交。

4. 合并分支与主分支时

分支历史不连贯或不一致：
- 如果你合并 new 分支到 master 分支时，两个分支的提交历史不连贯（例如 new 分支没有基于 master 创建），Git会产生冲突。
- 例子：
  - new 分支是从一个完全不同的历史创建的，合并到 master 时，Git发现无法直接合并，因为它们之间没有共同的祖先。

如何解决冲突？

手动解决冲突：
- Git会标记有冲突的文件，并提示你在工作目录中解决冲突。你需要手动修改文件，根据需求选择保留某个版本的改动或合并两者的差异。
使用 git mergetool：
- 如果遇到复杂冲突，使用 Git 自带的合并工具（如 vimdiff、meld）来帮助解决。
通过 git rebase 管理开发历史：
- 避免合并冲突的一种方式是使用 git rebase 而非 git merge，可以将提交整理在一起，确保历史线条更加清晰。
多人在同一个分支上合作

现在共同用一个分支，

在本地创建自己的分支（第一次加入分支工作）

1.创建好本地仓库连接上github仓库

2.git fetch，拉取远程分支到本地

3.git checkout -b master origin/master,创建本地分支关联远程分支

此时本地已经有我们的共同项目，用qt打开构建（第一次较慢），写自己的部分。 此后只需：

完成后上传（可以不用每次都上传，但顺手的事）

1.git add .,把本地文件加入暂存区

2.以防万一用git status检查下修改对不对

3.没问题用git commit -m "（你对本次修改注释）"，提交到本地git仓库

4.git push，推送到远程仓库。推送成功在github上就能看见你的提交了

下一次工作

1.git pull,拉取远程仓库最新的更新

2.coding自己的部分

3.重复 <完成后上传>

遇到的一些问题

1.大文件不能上传，如build文件夹

如果 build 文件夹已经被提交到 Git 仓库中怎么办？push会失败，提交不能覆盖，经过我艰难操作，什么lfs管理，.gitinore,.gitattributes啥的都别整，没办法补救。首先上传不需要把build文件夹提交，每个人本地上都有的，不要git add .然后不加思考就commit了，这不就悲剧了吗（push会失败，提交不能覆盖）。那已经提交了怎么办呢？包成功的办法是：

1.先把你的代码复制到另一个地方放着（不然一回退你还没提交到仓库的本地修改就没了或者会很混乱）

2.然后用git log，git reset --hard xxxx，回退到你把大文件提交到本地仓库的前一个状态

3.把你的代码复制回来覆盖，旧状态多余不需要的删掉，build文件夹不用移回来。这下再提交就只有这一个提交并且能成功。

4.最后把build文件夹移回来，里面有.exe项目一点秒跑。下次再提交，单独git add 文件名或者把build文件夹移出去再git add .，就不会出问题了。

没问题后就可以添加.gitnore啦

1. 在项目根目录创建 `.gitignore` 文件

通过命令行创建

touch .gitignore

如果你已经有 .gitignore 文件，直接编辑即可。
在文件管理器中手动创建：在项目的根目录中，右键选择 新建文件，命名为 .gitignore。（随便选个格式重命名改成.gitignore就行）

2. 编辑 `.gitignore` 文件

这是个默认的，主要是忽略build

# 忽略操作系统文件
.DS_Store
Thumbs.db

# 忽略日志文件
*.log

# 忽略构建目录
build/
dist/

# 忽略临时文件
*.tmp
*.swp

3. 添加到 Git 并提交

如果这是第一次添加 .gitignore 文件，按以下步骤操作：

将 .gitignore 文件添加到版本控制：

git add .gitignore
提交更改：

git commit -m "Add .gitignore file"

接下来再git add .的时候就不会把build也添加了，push到远程，其他小伙伴拉取下就都有了。

2.fatal: refusing to merge unrelated histories

这个错误是因为 Git 认为本地仓库和远程仓库的历史没有共同点（即它们的 commit 历史无关）。通常发生在以下情况：

本地仓库是新初始化的，但你没有从远程仓库 clone，而是直接 init 并尝试 pull。
远程仓库有历史，但你的本地仓库也是独立创建的，并且两者没有共同的 commit。

解决方案：

✅ 允许合并不相关历史（推荐）

运行以下命令：

git pull origin main --allow-unrelated-histories

🔹 这里的 main 需要替换为你的实际分支名称，比如 master。

✅ 强制让本地仓库与远程保持一致（⚠️ 会丢失本地修改）

如果你希望完全使用远程仓库的内容并覆盖本地:

git fetch --all git reset --hard origin/main # 替换 main 为你的分支

✅ 先添加远程再合并

如果你还没有关联远程仓库：

git remote add origin <远程仓库URL> git fetch origin git merge origin/main --allow-unrelated-histories # 解决不相关历史问题

⚠️ 注意：

--allow-unrelated-histories 只建议用于 合并两个独立的 Git 历史，正常情况下不应该使用。
reset --hard 会 丢失本地未提交的修改，请谨慎使用！

3.网络问题

前置知识：

git访问远程仓库的两种方式

SSH 和 HTTPS

	SSH 方式	HTTPS 方式
认证方式	SSH 密钥（`id_rsa.pub`）	用户名 + 访问令牌
是否需要输入密码	不需要（配置一次 SSH Key 后免密）	需要（除非使用凭据管理器缓存）
适合场景	长期使用 Git，比如开发、贡献代码	临时访问，比如克隆仓库或在防火墙环境下
安全性	较高，基于 SSH 密钥	较低，需要使用 Token 或密码
网络要求	需要 SSH 端口（22 或 443），部分网络可能会被封锁	无需特殊端口，一般不会被防火墙拦截

如何切换 SSH 和 HTTPS 访问

切换到 SSH 方式

git remote set-url origin git@github.com:your-username/your-repo.git
切换到 HTTPS 方式

git remote set-url origin https://github.com/your-username/your-repo.git

如果遇到网络问题

Failed to connect to github.com port 443 after 21112 ms: Could not connect to server

1.先在两种方式中切换，其中一种可能成功（一般http更容易遇到网络问题）

2.若ssh报错

说明网络限制了 SSH 端口 22，导致 GitHub 连接超时

测试 SSH 连接：

ssh -T git@github.com

如果显示：

ssh: connect to host github.com port 22: Connection timed out

说明端口 22 被封锁。

解决方案：

1.切换网络：尝试使用手机热点、VPN 或其他网络环境。

2. 修改 SSH 端口

GitHub 还提供了一个备用 SSH 端口（443），可以尝试使用：

ssh -T -p 443 git@ssh.github.com

这个提示是 SSH 在连接 GitHub 的备用 SSH 服务器（ssh.github.com 端口 443）时，检测到该主机的身份尚未被信任。你可以按照以下步骤处理：

确认连接安全
- 这个提示是正常的，SSH 需要你手动确认 GitHub 服务器的指纹。
- GitHub 官方文档提供的 ED25519 指纹：
  
  SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
  
  这和你的输出一致，所以可以放心继续。
输入 yes 并按回车

这样 SSH 会将 GitHub 的主机密钥添加到 ~/.ssh/known_hosts，下次就不会再询问。
如果连接成功，你会看到类似的消息

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

这意味着 SSH 连接 GitHub 成功。

如果还是无法 git pull

如果连接成功但 git pull 仍然失败：

修改 Git 远程仓库 URL 让 Git 使用 ssh.github.com 端口 443：

git remote set-url origin ssh://git@ssh.github.com:443/your-username/your-repo.git
然后再尝试：

git pull

问题解决！