一、cmd命令拉取项目

>git clone http://git.repo.xxx.git

二、git版本控制拉取项目

Git下载地址
原文链接

1. Open Git GUI here
   含义：打开 Git 的图形化界面工具（Git GUI），且直接定位到当前文件夹。
   使用场景：如果你习惯用图形界面操作 Git（比如可视化提交、分支管理、查看历史等），可以选这个。点击后会弹出 Git GUI 窗口，所有操作都在图形界面中完成，适合不熟悉命令行的用户。
   
   
   ①Source Location
   含义：远程仓库的地址，即你要克隆的代码仓库的源路径。
   操作：需在此输入类似http://git.repo.guanyitec.com:8088/network-platform/tiktok/tiktok-front的 Git 仓库地址（对应你之前提到的内部项目地址）。
   ②Target Directory
   含义：本地存储仓库的目标文件夹路径，即克隆下来的代码要存放在你电脑的哪个位置。
   示例：图中路径po.guanyitec.com8088/network-platform/tiktok/tiktok-front是待设置的本地目录，可通过 “Browse” 按钮选择你想保存的文件夹。

2. Open Git Bash here
   含义：打开 Git 自带的命令行终端（Git Bash），且当前工作目录就是你右键点击的文件夹。
   使用场景：如果你习惯用命令行操作 Git（比如git clone、git commit、git push等命令），选这个最方便。打开后可以直接在终端中输入 Git 命令，无需再手动切换目录。

简单来说，喜欢图形界面就用第一个，习惯命令行就用第二个～

三、Webstorm使用Git

1、push代码显示未关联远程仓库

当前提示 “Define remote” 的意思是：
本地的frontEnd分支还没关联远程仓库（比如 GitHub/GitLab 上的仓库），所以无法直接推送代码。

具体解决步骤（对应你这个远程仓库）：

• 先复制远程仓库的地址：点击页面右上角的Clone按钮，复制仓库的
  URL（比如https://gitcode.com/weixin_46011290/Vue3PlusDemo.git）；
• 回到 IDE 的 “Push Commits” 窗口，点击frontEnd旁边的 “Define remote”；
• 在弹出的窗口里，远程名称填origin（Git 默认的远程仓库名），URL 粘贴刚才复制的仓库地址，确认保存；
• 配置完成后，就能选择把本地frontEnd分支推到远程仓库的对应分支了。
  
  关键信息：
• 分支关联成功：本地frontEnd的master分支，已经和远程仓库（origin）的master分支绑定好了（显示master →
  origin : master，右边还标了 “New”，说明远程是刚创建的新分支）。
• 待推送的提交：左边列出来要推的内容 ——“配置全局 less 样式”“初始化项目代码” 这两个提交。
• 待推送的文件：右边是这些提交对应的具体文件（比如src下的代码、public里的资源等）。
• 现在只要点击右下角的 **“Push” 按钮 **，就能把本地master分支的代码推到远程仓库的master分支啦～

注意：Push failed frontEnd: remote: <CH.00905401> HTTP Basic: Access denied. remote: The password-based authentication of Git has been removed. Please use your personal access token instead of the password. Request-id is IGvwQ3RlIY. Authentication failed for 'https://gitcode.com/weixin_46011290/Vue3PlusDemo.git/'
这个错误是Git 仓库的认证方式不支持密码登录了，具体原因：GitCode（类似 GitHub/GitLab）已经停用了 “账号密码” 的 Git 认证方式，要求用个人访问令牌（Personal Access Token，简称 PAT） 代替密码来登录。

简单说：
之前用账号密码尝试推送，但平台不让这么用了，得生成一个 “令牌”，把它当密码用才行。

解决步骤：
打开 GitCode 网站，登录账号；
进入 “设置”→“访问令牌”，生成一个令牌（需要勾选repo等权限：保证Repository:“读写”）；
回到 IDE 的推送窗口，当弹出登录提示时，用户名填你的 GitCode 账号，密码填刚生成的令牌。

如果报错：frontEnd: remote: <CH.00905401> HTTP Basic: Access denied. remote: The password-based authentication of Git has been removed. Please use your personal access token instead of the password. Request-id is R8wSGcnWb8. Authentication failed for 'https://gitcode.com/weixin_46011290/Vue3PlusDemo.git/'

是因为IDE 里还存着之前的密码缓存，没用上新生成的令牌，解决步骤很简单：

• 清除 IDE 的 Git 密码缓存
  以 WebStorm 为例：
  打开File → Settings → Appearance & Behavior → System Settings → Passwords；
  找到 “Git: gitcode.com” 对应的记录，删除它。
  这个界面是 WebStorm 的密码管理设置，当前用了KeePass工具来保存密码（包括之前的 Git 账号密码缓存）。现在要清除 Git 的旧密码，得换个更简单的方式：

直接操作：
先把当前的KeePass Database File窗口关掉（点Cancel）；
在Passwords设置页，选择 “Do not save, forget passwords after restart”（不保存密码，重启后忘记）；
点击OK保存设置，然后重启 WebStorm。

• 重新推送，输入令牌
  再次点击推送按钮，弹出登录窗口时：
  用户名：填你的 GitCode 账号；
  密码：填刚生成的访问令牌字符串（不是账号密码）。
  这样就能用新令牌完成认证，成功推送了。
  
  注意：令牌只在生成时显示一次，之后会隐藏

2、日志分析

Git 日志界面，能看到本地和远程仓库的分支、提交记录情况：

左侧（分支结构）

• Local（本地分支）：
  ①main (Vue3PlusDemo)：本地的main分支；和远程origin/main关联了（能看到远程提交记录），且本地main有新提交（“初始化项目代码”）；
  
  这个绿色小箭头是 Git 分支的 “超前提示”，意思是：本地main分支的提交记录，比远程origin/main分支多了新内容（也就是本地有未推送到远程的代码）。
  具体来说：你本地main分支有个 “初始化项目代码” 的新提交（看右侧记录），但远程origin/main还没同步到这个提交，所以用绿色箭头表示 “本地分支超前于远程分支”。

②master (frontEnd)：本地的master分支（对应你之前的frontEnd目录）；本地独立分支，有最新提交（“配置全局 less 样式”），但还没推到远程仓库（远程没有origin/master）。

• Remote（远程仓库）：
  
  ①origin：你配置好的远程仓库（就是之前的weixin_46011290/Vue3PlusDemo）
  ②origin/main：远程仓库的main分支；只有main分支（右边远程分支列表里只有origin/main）；

右侧（提交记录）

• 能看到所有提交的历史：比如 “配置全局 less 样式”“初始化页面代码” 等，每条记录对应了提交分支、提交人、时间（比如master分支刚提交了 “配置全局 less 样式”）。

现在问题：
本地master分支的代码还没同步到远程，所以之前 push 失败是因为远程没有对应的master分支，需要手动指定推送。

解决办法：
在 Git 日志界面，右键点击本地的master (frontEnd)分支 → 选择「Push…」→ 在弹出的窗口里，把 “Remote branch” 填成master（远程会自动创建这个分支）→ 点击 Push，就能把本地master的代码推到远程了。

3、为什么push成功仓库没有？

本地的 Git 仓库是 **frontEnd文件夹里的.git（看第一张图里的.git在frontEnd目录下），但远程仓库对应的是外层Vue3PlusDemo的仓库 **—— 相当于我把frontEnd当成独立 Git 仓库推了，但远程Vue3PlusDemo仓库里的frontEnd只是一个普通文件夹，两者不是同一个仓库。

简单说：
你本地有两个层级的 Git 仓库：
外层Vue3PlusDemo：是我最初克隆的仓库（但里面的.git可能没正确关联）；
内层frontEnd：是你单独初始化的 Git 仓库（我推送的是这个内层仓库的代码）。

解决：
如果要把frontEnd作为Vue3PlusDemo仓库里的文件夹推送：

• 删除frontEnd目录下的.git文件夹（取消它的独立 Git 仓库身份）；
• 回到外层Vue3PlusDemo目录（确保这里有.git，是关联远程的仓库）；
• 执行git add frontEnd → git commit -m “添加frontEnd文件夹” → git push origin master。

或者在 WebStorm 里完成 “添加frontEnd文件夹并推送”：

• 步骤 1：初始化外层Vue3PlusDemo为 Git 仓库
  打开 WebStorm 的终端（Terminal），执行：

# 确保终端路径是Vue3PlusDemo根目录（比如E:\test\Vue3PlusDemo）
git init
# 关联远程仓库
git remote add origin https://gitcode.com/weixin_46011290/Vue3PlusDemo.git

• 步骤 2：添加并提交frontEnd文件夹
  在终端继续执行：

git add frontEnd
git commit -m "添加frontEnd文件夹"

• 步骤 3：推送至远程
  终端执行：

git push origin main

四、Webstorm更新Git项目报错

安装Git拉取项目后，webstorm打开该项目CTRL+T更新项目发现报错： “Cannot Run Git: No such file: git.exe” 的错误。
原因：安装Git时改路径使用D盘。

（1）排查是否安装Git

git --version

（2）找到安装Git的实际路径

步骤 1：打开 WebStorm 的 Git 设置

点击顶部菜单栏 File → Settings（Windows/Linux）或 WebStorm → Settings（Mac）。
在设置界面中，展开 Version Control → Git。

步骤 2：手动指定 Git 可执行文件路径

在 “Path to Git executable” 选项中，点击右侧的浏览按钮（…）。
导航到 Git 的安装目录，找到git.exe文件。默认路径通常是 C:\Program Files\Git\cmd\git.exe（或类似路径，根据实际安装位置调整）。

步骤 3：测试并保存配置

点击 “Test” 按钮，若显示 Git 版本号（如git version 2.51.2.windows.1），说明路径配置成功。
点击 “OK” 保存设置，然后重启 WebStorm。
这样配置后，WebStorm 就能正确识别 Git 可执行文件，解决 “找不到 git.exe” 的报错问题。

四、手动标记Git根目录无法版本管理

报错：The directory E:\test\Vue3PlusDemo\frontEnd is registered as a Git root, but no Git repositories were found there.
E:\test\Vue3PlusDemo\frontEnd 这个目录被注册为 Git 根目录，但在该目录下未找到任何 Git 版本库。

• Git root：Git 根目录（IDE / 工具识别的 “应该是 Git 仓库根路径” 的目录）
• Git repositories：Git 版本库（包含 .git 隐藏文件夹的目录，是 Git 管理代码的核心目录）
• 
  识别到我把 E:\test\Vue3PlusDemo\frontEnd 标记为了 Git 根目录（比如手动设置、工具自动识别），但工具检查后发现：
  这个目录下并没有初始化 Git 仓库（即缺少 .git 隐藏文件夹），所以 Git 无法对该目录下的代码进行版本管理。

该目录未初始化 Git 仓库（最常见）
解决：打开终端，进入该目录执行初始化命令：

# 1. 切换到E盘的目标目录（加/d参数跨磁盘）
cd /d E:\test\Vue3PlusDemo\frontEnd

# 2. 初始化Git仓库（此时仓库会建在frontEnd目录下）
git init

提示 Initialized empty Git repository in E:\test\Vue3PlusDemo\frontEnd.git/，意思是：已经在E:\test\Vue3PlusDemo\frontEnd目录下初始化了一个空的 Git 仓库（.git文件夹已经创建在这个目录里）。

五、Webstorm提交Git项目（Unversioned Files）

完成上面根目录下初始化git仓库后，这些文件（Unversioned Files）才能被识别进行版本控制。

当前frontEnd目录的 Git 仓库里，有31 个未被 Git 跟踪的文件（Unversioned Files），现在处于 “提交代码” 的操作界面。

• 先勾选Unversioned Files旁边的复选框，选中这 31 个文件；
• 在下方输入框写提交说明（比如 “初始化项目代码”）；
• 点击Commit完成本地提交（如果需要推到远程，后续再用Push功能）。

六、Webstorm更新Git项目（Merge与Rebase）

这是Webstorm 的 “更新项目” 弹窗，是 Git 拉取远程代码时的选择界面。

如果是日常开发，直接点OK用默认的Merge方式就可以～

1、选项说明

• Merge incoming changes into the current branch（默认选中）
  → 把远程的新代码合并到本地当前分支（会生成一个新的 “合并提交”，保留双方的提交记录）。
  ✅ 优点：操作简单，适合新手 / 普通场景。
• Rebase the current branch on top of incoming changes
  → 把本地的提交 “接” 在远程新代码的后面（提交记录会变成线性，更整洁）。
  ⚠️ 注意：如果本地提交已经推到远程，不建议用这个（可能会冲突）。

2、场景假设

你和同事都基于「远程仓库的 V1 版本」开发，同事先推了 V2，你本地改了 V3（此时记录分叉）：

1. 用默认「Merge（合并）」的效果（分叉记录）

远程仓库：V1 → 同事的V2（已推）
你的本地：V1 → 你的V3（未推）
↓ Merge后本地记录：
V1 → 同事的V2 → 合并节点 → 你的V3
（❌ 记录分叉，多了一个“合并提交”节点，看起来乱）

2. 用「Rebase（变基）」的效果（线性记录）

远程仓库：V1 → 同事的V2（已推）
你的本地：V1 → 你的V3（未推）
↓ Rebase后本地记录：
V1 → 同事的V2 → 你的V3
（✅ 记录是一条直线，没有多余合并节点，整洁）

Rebase 的核心动作就像：

Rebase 的 “重建触发条件”（本地存在未推送到远程的提交，且该提交不在远程最新的祖先链中）

• 先 “暂停” 你本地的所有提交（比如你的 V3）；
• 把远程最新的代码（同事的 V2）“拉到” 你本地，让你本地先同步到 V2；
• 再把你暂停的提交（V3）“重新播放” 在 V2 后面；
• 最终你的提交就像 “紧跟在远程新代码之后开发的”，记录自然成直线。

但如果本地提交已经推到远程，不建议用Rebase （可能会冲突）

核心是：本地提交推到远程后再用 Rebase，会篡改公共提交记录，导致团队其他人的代码库和你的不一致，引发大面积冲突 / 混乱。

Git 的提交是 “带唯一指纹的快照”：每个 Git 提交都会生成一个唯一的哈希值（比如 a1b2c3d），相当于这个提交的 “身份证”：

• 你把本地提交推到远程后，这个 “身份证” 就同步到了团队共享的远程仓库，同事拉代码时会把这个 “身份证” 抄到自己本地；

3、第二天 rebase 不重建前一天已推节点

本质是第二天 rebase 时，本地提交的父节点已经和远程最新节点对齐了 —— Rebase 的 “重建触发条件”（父节点≠远程最新）消失了，自然不会再剥离重建。

（1）为什么 第一天 Rebase 重建已推节点？

假设团队远程仓库（origin/main）的提交链是：V1 → V2 → V5（V5 是同事推的最新节点）

而你本地的提交链是：V1 → V2 → V3 → V4（V3、V4 你昨天已经推过远程，但当时远程还没 V5）

此时你执行 git rebase origin/main：

• Rebase 检测到：「本地存在未推送（V3 与 V4）到远程的提交，且该提交不在远程最新的祖先链中（远程 V5 没有 V3 这个后代）」；
• 触发 “剥离→重建”：把 V3、V4 从 V2 上剥下来，重新拼到 V5 后面，生成新哈希的 V3’、V4’；
• 这时候你本地链变成：V1 → V2 → V5 → V3’ → V4’（旧 V3、V4 因为哈希变了，和远程的旧记录冲突）。

（2）为什么 第二天 Rebase 不重建？

第二天，假设远程又有新提交 V6（同事推的），此时远程链是：V1 → V2 → V5 → V3’ → V4’ → V6

你本地还是停在 V4’（没新提交），执行 git rebase origin/main：

• Rebase 检测到：本地最新节点 V4’ 的父节点是 V3’，而远程最新节点 V6 的直接祖先就是 V4’（本地提交的父节点链和远程最新节点的祖先链完全对齐）；
• 触发条件不满足（父节点链是远程最新的子集），Rebase 只会做 “快进（fast-forward）”：把本地 main 直接指向V6，不会重建任何提交；

哪怕你第二天本地新增了 V7（父节点是 V4’），执行 Rebase 时：

• 只会重建 V7（因为 V7 的父节点是 V4’，而远程最新是 V6），把 V7 拼到 V6 后面变成 V7’：V1 → V2 → V5 → V3’ → V4’ → V6→ V7’
• 但 V3’、V4’ 不会重建 —— 因为它们的父节点已经和远程的祖先链对齐了。

4、Rebase 使用场景

如果是想 “同步同事代码 + 保持记录整洁”，给你最安全的操作流程：

• 本地写代码，做 1~N 次提交（都不推远程）；
• 执行git pull --rebase同步同事代码（有冲突就改，改完继续）；
• 确认 Rebase 完成后，再执行git push推到远程。
• 这样既保证了记录线性，又不会影响团队～

🌰 实际操作详细示例（本地多次提交，依然安全）

假设远程主分支初始记录：V1（初始）→ V2（同事上周推的）

• 步骤 1：本地写代码，做 3 次提交（都不推远程）
  你本地分支记录变成：V1 → V2 → 你的V3（初始化组件）→ 你的V4（补全逻辑）→ 你的V5（修复bug）（此时 V3/V4/V5 都只在你本地，远程完全不知道）
• 步骤 2：同事推了新代码，你同步 + Rebase
  同事刚推了 V6 到远程（远程记录：V1→V2→V6），你执行：

git pull --rebase  # 同步远程V6，并Rebase你的本地提交

Git 会自动把你的 V3/V4/V5 “接” 在 V6 后面，本地记录变成：V1 → V2 → V6（同事新提交）→ 你的V3 → 你的V4 → 你的V5（全程线性，没有合并节点，哪怕有冲突，改完继续即可）

• 步骤 3：推远程，记录依然整洁
  执行git push后，远程记录会同步你的本地记录：V1 → V2 → V6 → 你的V3 → 你的V4 → 你的V5

✅ 既同步了同事的代码，又保留了你本地多次提交的细节，记录还是一条直线！

🚫 误区澄清：“多次提交”≠“必须推远程”
我以为 “只能提交一次”，其实是混淆了「本地提交」和「推远程」：

• 本地提交：是 Git 帮你 “保存本地修改快照”，可以无限次做（哪怕一天改 10 次，分 10 次提交），目的是方便你回溯、回滚；
• 推远程：是把本地的提交 “同步到团队共享仓库”，只要没推，这些提交就只属于你，怎么 Rebase 都不会影响别人。

✅ 核心原则（记这一句就够）
本地提交次数无限制，只要「推远程前」统一做一次 Rebase 同步远程代码，就能既保留本地多次提交的细节，又让最终远程记录整洁。

5、总结

1. Merge 的逻辑是「新增一个合并提交」，保留所有人的旧哈希，相当于 “在现有记录上加新节点”，团队记录始终一致；

# 如果你的提交已经推到远程，想同步同事代码：
# 同步远程最新代码（自动Merge，有冲突就改）
git pull 
# 改完冲突后，提交合并记录，再push
git add .
git commit -m "合并远程V4代码，解决xxx冲突"
git push

3. Rebase 的逻辑是「替换旧记录」，改的是 “已共享的历史”，相当于 “把团队所有人手里的旧身份证作废，换成新的”，必然乱套。
   ①日常开发：想到哪改到哪，本地随时提交（比如 “改完一个小功能就提交一次”），不用纠结 “要不要推”；
   ②每天下班 / 准备合代码前：执行git pull --rebase同步远程最新代码，解决冲突（如果有）；
   确认没问题后：执行git push把本地所有提交一次性推远程。

这样既不会因为 “怕记录乱而不敢本地提交”，也不会因为 “频繁推远程” 导致 Rebase 踩坑，是团队协作中 “整洁记录 + 安全同步” 的最优解～

七、解决Git冲突

原因：远程仓库修改了readme导致本地不是最新版本，push代码时失败；

步骤 1：解决README.md的冲突

打开README.md文件，找到冲突标记（类似👇）：

<<<<<<< HEAD
你本地的内容
=======
远程的新内容
>>>>>>> [远程提交ID]

保留需要的内容，删除冲突标记
保存文件

步骤 2：标记冲突已解决（关键）

git add README.md

步骤 3：完成合并提交

git commit -m "解决README.md新冲突，完成合并"

步骤 4：再次拉取（确保本地与远程一致）

git pull origin main

步骤 5：推送本地代码

git push origin main

注意：远程仓库的 “Git 钩子” 限制了文件大小（100MB），如果要推送的xxx-0.1-SNAPSHOT.jar文件超过了仓库的限制，远程会拒绝了推送。