旧版详细步骤： ， 直

在实际开发的时候，大家还是各有不同的问题用不好分支，这里给出低难度的在同一个分支上多人合作的步骤

(非常有效解决)

目录

使用场景：

1.在本地工作文件夹初始化本地Git仓库

2.克隆远程仓库到本地

使用场景：

遇到网络问题时：

1.查看远程仓库地址

2.修改远程地址（如切换 HTTPS/SSH）

使用场景：

需要回退版本时可查看提交历史，并进行回退

使用场景：

在本地测试分支上拉取远程他人分支进行测试

在本地初始化的git仓库第一次push时需要设置本地分支追踪远程分支

git push --set-upstream origin <分支名>

一套工作区文件，N 个分支的版本共存：只要切换分支，文件内容就变了，就像多次元平行世界一样，你只需专注一个版本，剩下的交给 Git。

核心：一切都存在 .git 文件夹（本地git仓库）里

git checkout <分支名> 只需一行命令，分支间的内容瞬间切换。

Git 还会帮你记录工作区的状态，不用担心切换分支时丢失更改。

假如 master 是主线，你的 feature-A 分支开发了新功能，只要 git merge feature-A，代码就合并了。

无论什么文件，改了多少次，Git 都能帮你保存下来。

用git log查看提交历史

在任意分支间无缝切换工作。

随时追踪修改、恢复误删、回滚历史。

快速合并代码，拥抱团队协作。

本地指的是 当前你的 Git 仓库所在的目录，即项目的文件夹。

当你在某个目录下初始化 Git 仓库时（通过 git init 建立本地仓库 或克隆远程仓库时 git clone），Git 会在该目录中生成一个隐藏的 .git 文件夹。这个 .git 文件夹包含了所有 Git 用来管理版本控制的元数据和对象。

以下是常见的本地 Git 仓库结构：

工作区（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）：将本地分支的更改上传到远程仓库。

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

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

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

选择性提交：

暂存区允许你精确选择要提交的文件或更改，而不是一次性提交所有改动。

比如，你修改了 a.cpp 和 b.cpp，但只想提交 a.cpp，你可以只把 a.cpp 暂存。使用git add 提交内容到暂存区

记录提交内容：

当你运行 git commit 时，Git 只会提交暂存区中的内容，工作目录中的其他改动不会被提交。

文件状态跟踪：

Git 用暂存区跟踪文件从“修改”到“准备提交”的状态。

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

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

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

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

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

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

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

工作目录：你实际操作的文件。修改代码时的内容存在这里。

暂存区：准备提交的地方，记录你挑选的改动。

本地仓库：你用 git commit 把暂存区的内容提交到这里。

远程仓库：通过 git push 把本地仓库的提交上传到远程。

暂存区是提交的中间站，你可以选择哪些改动需要提交。

如果要回退，可以根据需要选择回退暂存区、工作目录，或者整个提交。

熟练使用 git restore 和 git reset，可以灵活控制代码版本和状态。

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

<remote>：指的是远程仓库的名字，通常是 origin（默认的远程仓库名）。

<branch>：指的是你要推送的本地分支名。

推送当前分支到远程仓库： 如果你在本地的 test 分支上并且想要将该分支推送到远程仓库 origin，可以运行：

推送所有本地分支到远程仓库： 如果你想要推送所有本地分支到远程仓库，可以使用：

推送标签（tag）到远程仓库： 如果你有标签需要推送，可以使用：

推送并设置上游分支（首次推送）： 如果这是你第一次将一个本地分支推送到远程仓库，且需要设置追踪信息（即将本地分支与远程分支关联），可以使用：

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

例如：

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

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

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

例如：

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

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

例如：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

红色文件：表示未添加到暂存区的更改。

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

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

将更改提交到当前分支：

然后切换分支：

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

然后切换分支：

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

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

放弃工作区的所有更改： git checkout .

删除未跟踪的文件或目录： git clean -fd 然后切换分支： git checkout <目标分支>

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

git checkout -f <目标分支>

如果更改非常重要，建议备份或提交后再切换分支，以免数据丢失。

使用 git stash 时，可以创建多个存储记录，使用 git stash list 查看所有存储项。

单份工作区文件 Git 的所有分支共享一份工作区文件。每次切换分支时，Git 会根据分支的内容更新工作区中的文件。

你在本地文件夹中看到的文件，就是当前检出的分支对应的文件。

如果你切换到另一个分支，Git 会更新这些文件，变成新分支的状态。

Git 仓库的管理 Git 仓库实际上存储了项目的所有历史记录和所有分支的内容，但它们是以一种高效的方式压缩保存的（.git 文件夹中）。

本地分支的内容实际上都保存在 .git 文件夹中。

你只需要一个项目文件夹，Git 会在你切换分支时动态修改工作区文件，不需要为每个分支保存独立的文件夹。

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

文件在分支间的共享机制

如果某个文件在所有分支中都相同，那么它不会被修改。

如果某个文件在分支间有差异，Git 会根据切换的分支动态更新工作区中的文件。

场景演示

在 master 分支：你看到的是 master 分支的文件内容。

切换到 feature-A 分支：

Git 会替换工作区中的文件，使之变为feature-A分支的内容。

切换回 master 分支：

工作区文件再次恢复为master分支的内容。

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

文件夹只需要一份，你无需为每个分支单独创建文件夹。

Git 会自动切换工作区的文件内容，你只需要专注于当前分支。

未提交的更改 如果你修改了文件但尚未提交，切换分支可能会遇到问题，Git 会提示你“工作区中有未提交的更改”：

解决办法是先提交更改，或将更改暂存到“暂存区”：

多个副本的极端情况 在少数情况下，如果你需要同时处理多个分支的文件，可以通过创建项目文件夹的副本来操作（如 Gem_master_v1 和 Gem_master_v2），但这通常不是必要的，Git 分支已经足够应对多数场景。

团队远程仓库中有一个 master 分支，每个人都拉取 master 到本地。

每个人基于master创建自己的分支：

在个人分支上开发并提交代码：

推送到远程的个人分支：

在远程仓库pull request提交合并申请，将个人分支的内容合并到 master。

代码审查通过后，项目管理员将其合并到远程的 master 分支。

每个人在本地个人分支拉取最新远程master分支，在最新版本上进行个人分支更改

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

确认本地没有有效的 master 分支：

查看本地分支：

如果master不在列表中，说明本地没有master

同步远程分支到本地：

获取远程分支的所有更新：

基于远程origin/master

创建一个本地master分支：

这会在本地创建一个与远程同步的master分支。

创建新分支：

在本地master基础上创建你的新分支：

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

检查本地 master 是否存在。

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

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

在github上点击pull request提交

最后关于冲突，

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

不同分支有相同的文件改动：

当你尝试将 new 分支与 master 分支合并时，如果两个分支上对同一个文件做了不同的改动，Git就会提示你处理冲突。

例子：

master 分支对 config.txt 文件做了修改（增加一行内容），而 new 分支也对 config.txt 文件做了不同的修改（删除了一行内容）。

在合并时，Git无法确定使用哪个版本，因而会产生冲突。

在远程已经有新提交的情况下推送：

如果你在 new 分支上工作，并且已经做了一些提交，但在推送到远程之前，其他开发者也在 new 分支上工作并做了新的提交，那么推送时会发生冲突。

例子：

你在 new 分支上提交了一些改动后准备推送，但此时远程的 new 分支已经被其他开发者更新。

当你推送时，Git会发现你的提交历史与远程的不同，无法自动合并，所以会提示你解决冲突。

使用 git pull 时：

当远程仓库和本地仓库有不同的提交历史，使用 git pull 就可能会产生冲突。

例子：

你在 new 分支上做了一些工作，但在 master 分支上有新的提交。如果你 git pull origin master，Git会发现这两个分支历史之间不一致，并提示你解决冲突

详细解释：

远程和本地历史不一致：

git pull 命令实际上是两个命令的组合：git fetch 和 git merge.

git fetch 会从远程仓库获取更新，但不会直接合并到本地。它只是将远程仓库的最新内容下载到本地。

git merge 将本地分支与远程分支合并。在这一步，Git会检查两者的历史提交，寻找共同的祖先。如果无法找到，则意味着两个分支的历史并没有关联，或者已经被重新初始化了。

发生冲突的情况：

例子：假设你在 new 分支上工作了一段时间，做了一些提交（A、B、C），这时 new 分支的历史是独立的。与此同时， master 分支有一些新的提交（D、E、F）。

当你在new分支上运行

Git 会将远程 master 分支的内容下载到本地。

然后，它会尝试将本地 new 分支与远程 master 分支合并。

因为这两个分支的历史没有交集（可能是由于不同的开发人员操作或某些历史变化），Git无法自动决定合并哪个版本。

因此，它会提示你手动解决冲突，因为它无法直接合并两者。

解决冲突的步骤：

Git会标记有冲突的文件，并且会告诉你具体冲突在哪些文件中。你需要手动合并这些文件，处理冲突后，才能完成 git pull。

解决冲突后，你需要确认合并：git commit 解决掉冲突，并将修改提交。

分支历史不连贯或不一致：

如果你合并 new 分支到 master 分支时，两个分支的提交历史不连贯（例如 new 分支没有基于 master 创建），Git会产生冲突。

例子：

new 分支是从一个完全不同的历史创建的，合并到 master 时，Git发现无法直接合并，因为它们之间没有共同的祖先。

手动解决冲突：

Git会标记有冲突的文件，并提示你在工作目录中解决冲突。你需要手动修改文件，根据需求选择保留某个版本的改动或合并两者的差异。

在自己的分支上写代码，并适时提交到自己远程分支

git branch 看现在在哪个分支

git checkout -b <分支名> 转到自已的分支(仅第一次创建需要加-b)，随后切换分支只需要git checkout 分支名

在自己的分支工作后

git add . 把新写的文件加入缓存区

Git status (查看当前状态)

Git commit -m "注释 "（提交代码至本地仓库，一定要写清楚注释）

Git push （提交代码到远程仓库）第一次提交的话要使用git push -u origin <分支名> 将本地分支与远程创建好的分支关联（注意本地分支名要与远程分支名一致才能这样设置关联）

进入远程仓库，转到自己的分支看一下，是否提交成功

功能测试完确认没问题了在github上点create pull request提交合并申请，并添加对自己更改的描述

通过合并后，主分支得到更新

每次开始工作前，用git pull origin master，获取最新的主分支，始终在最新的主分支基础上在自己的本地分支写代码，查看自己目前所处的本地分支git branch，灵活使用git status确认仓库状态

git fetch：从远程仓库下载最新的分支信息和提交历史，但不会自动合并或修改本地工作区。这是获取远程分支最新状态的关键一步。

git checkout <本地分支名>：切换到要接收合并的本地分支。

git merge origin/<远程分支名>：将远程的特定分支合并到当前所在的本地分支。、

git fetch

git reset --hard origin/<分支名>

可能其它人会传一些bug，或者你们共同修改了同样的地方，一拉取下来就会造成冲突，最后导致程序运行不了，现给目前我用的解决办法：

！！！！在拉取之前一定要commit自己的代码！！！！commit是完成在本地git仓库的提交，这样修改就不会丢失（相当于复制备份了，以后能随时取出来），push后才会上传到远程仓库

这样通过下面的指令就可以再把代码变回未拉取前良好的状态，然后可以之后再尝试拉取，能够反复做冲突合并，以免改坏了回不去

现在共同用一个分支，

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

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.先在github创建远程仓库

2.使用git clone在本地克隆一份

3.然后在此基础上开发

查看本地仓库的内容：git ls-files

git rm 和 .gitignore 结合使用：

当文件已经被 Git 跟踪，但你现在决定它不应该被跟踪（例如，不小心提交了虚拟环境），并且希望它将来也不再被跟踪时，你就需要先将它添加到 .gitignore，然后用 git rm --cached 将其从跟踪中移除。

这一步是将虚拟环境目录从 Git 的索引（跟踪状态）中移除，但不会删除您本地的实际文件。

git rm -r --cached venv/ git rm -r --cached .venv/

git rm：用于从工作区和索引中删除文件。

-r：递归删除，用于删除目录及其内容。

--cached：关键参数！ 它告诉 Git 只从索引中删除文件（即不再跟踪），而保留工作目录中的实际文件。这样您的虚拟环境就不会被真正删除，只是 Git 不再管它了。

把本地所有的提交历史删掉，同步为远程仓库该分支的历史

git reset origin/远程分支名

如果 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啦

通过命令行创建

touch .gitignore

如果你已经有 .gitignore 文件，直接编辑即可。

在文件管理器中手动创建： 在项目的根目录中，右键选择 新建文件，命名为 .gitignore。（随便选个格式重命名改成.gitignore就行）

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

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

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

git add .gitignore

提交更改：

git commit -m "Add .gitignore file"

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

这个错误是因为 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 会 丢失本地未提交的修改，请谨慎使用！

前置知识：

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

SSH 和 HTTPS 

如何切换 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）时，检测到该主机的身份尚未被信任。你可以按照以下步骤处理：

确认连接安全

输入 yes 并按回车

这样 SSH 会将 GitHub 的主机密钥添加到 ~/.ssh/known_hosts，下次就不会再询问。

如果连接成功，你会看到类似的消息

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

这意味着 SSH 通过443连接 GitHub 成功，下面使用443端口操作：：

1.修改 Git 远程仓库 URL 让 Git 使用 ssh.github.com 端口 443(注意如果是第一次拉取远程仓库则还没有设置remote仓库名字，只能使用方法2直接指定)：

git remote set-url origin ssh://git@ssh.github.com:443/your-username/your-repo.git

然后再尝试：

git pull , git push , git clone 

2.或者直接指定端口：

        git pull git@ssh.github.com:your-username/your-repo.git

        git push git@ssh.github.com:your-username/your-repo.git

        git clone git@ssh.github.com:your-username/your-repo.git

问题解决！

在执行 git merge 操作时遇到了需要输入合并提交信息的情况。

当前情况分析：

你正在将远程分支 xxxx 合并到本地同名分支

Git 要求你为这次合并提交输入说明信息

界面中已经显示了最近的提交历史（05afbb3 是之前的提交）

你可以采取以下操作：

1. 直接接受默认合并信息（推荐）

直接按以下步骤操作：

保持文件内容不变（已经包含有用的上下文信息）

按 Esc 键

输入 :wq 然后按回车（保存并退出）

2. 如果想自定义合并信息：

删除以 # 开头的注释行

在第一行写上有意义的合并说明，例如：

复制

下载

然后按 Esc，输入 :wq 保存退出

3. 如果想取消合并：

直接删除所有内容（使文件为空）

按 Esc，输入 :wq 保存退出

Git 会中止合并操作

专业建议：

合并提交信息应该说明为什么需要这次合并

可以提及合并解决了哪些具体问题

保持信息简洁但要有足够上下文

如果是团队项目，可以加上相关issue或任务的编号