目录
一、先了解一下
1、什么是Git
开源的分布式版本控制系统，主要用于管理代码和其他纯文本文件，如 txt、word 等。
版本控制系统：管理项目代码的工具，可以记录代码的历史变更，协助团队成员协作开发。
分布式版本控制系统：将代码库完整地分布在多个计算机上的版本控制系统。每个开发者都有一份完整的代码库，可以在本地进行代码管理和版本控制。
2、工作原理及工作流程
Git 的工作原理基于三个主要区域：工作区、暂存区和本地仓库。
- 工作区：在本地电脑上看到的目录和文件，所做的任何修改都是对工作区的修改。
- 暂存区：中间区域，用于存放即将被提交到仓库的修改，通过git add命令可以将工作区的修改添加到暂存区。
- 本地仓库/版本库：存储版本历史的地方，包含了项目的完整历史记录和所有版本的文件。
工作流程
在工作区做出修改，然后使用 git add 将修改添加到暂存区，最后使用 git commit 将暂存区的修改提交到本地仓库。
暂存区的作用
- 是一个缓存区，可以对要修改的文件精细化控制
- 对每个修改进行审查和确认，确保每次提交都是有意义和可靠的
- 帮助实现分支管理，可以分组或者分批提交
- 随时保持某一时刻的状态，代码没写完也可以保存，暂时不用保存代码提交的完整度
- 允许在提交之前撤销部分更改。（使用 git reset 或 git restore --staged 取消这些更改的暂存状态）
3、Git和SVN（Subversion）
1. 分布式 vs 集中式
Git 是分布式版本控制系统，每个工作副本都是一个完整的仓库，包含完整的历史记录和版本信息。这意味着在没有网络连接的情况下，可以继续工作、提交和查看历史记录。
SVN是集中式版本控制系统，所有的历史记录和版本信息都保存在中央服务器上。每次与服务器交互都需要网络连接，断网时无法进行版本控制操作。
2. 工作流程
在 Git 中，通常使用分支进行开发，每个开发者可以在本地创建和切换分支，然后合并到主分支或其他分支。
在 SVN 中，通常采用基于路径的分支（branch）和标签（tag）的模式，开发者需要在服务器上创建分支和标签，并且通常只能在主干（trunk）上进行开发。
3. 性能
Git 是分布式的，大部分操作都在本地完成，因此通常比 SVN 更快。
SVN 的性能通常受到服务器性能和网络延迟的影响，特别是在处理大型仓库或者在较慢的网络连接上。
4. 数据存储
Git 使用快照（snapshots）存储文件和目录状态，每次提交都是一个新的快照，这使得Git在处理大量文件和历史记录时非常高效。
SVN 存储的是文件的差异（delta），每次提交只存储修改的部分，这可能会导致仓库占用的磁盘空间增长较快，尤其是在频繁修改的文件中。
5. 分支与合并
Git 的分支操作非常轻量和灵活，合并通常很简单，因为Git能够自动检测并解决大部分的合并冲突。
SVN的分支和合并操作相对复杂，通常需要手动指定合并的目标路径，并且合并冲突的解决需要手动介入。
二、开始吧
右键 > 显示更多选项 > Open Git Bash Here
ls：查看工作区的内容
cat：查看文件的内容
vi：修改文件内容
cd：转向某文件
HEAD：指向分支的最新提交节点
HEAD~ 和 HEAD^：表示上一个版本
HEAD~2：表示之前的两个版本
git ls-files：查看暂存区内容
echo 111 > file.txt：添加内容为111的file.txt文件到当前目录下
git init：初始化Git仓库
git config --global user.name "Your Name"：设置用户名
git config --global user.email "your.email@example.com"：设置邮箱地址
git status：查看仓库状态
git add <file>：添加到暂存区
可使用通配符，例如：git add *.txt
也可以使用目录，例如：git add .
git commit：提交
只提交暂存区中的内容，不会提交工作区中的内容
git commit -m "Commit message" 将暂存区中的文件提交到仓库，并附加一条提交信息
git revert HEAD：撤销最近一次提交
git log：查看仓库提交历史记录
git log --oneline来查看简洁的提交记录
git log --graph --oneline查看分支之间的关系
git reflog：查看操作的历史记录
git branch：查看分支信息
git branch -a：列出所有本地和远程分支
git checkout <branch>：切换分支
git checkout -b <new-branch>：创建一个新的分支并立即切换到这个分支
git merge <branch>：将指定的分支合并到当前分支
git push <remote> <branch>：将本地的分支推送到远程仓库
<remote>通常是origin，表示默认的远程仓库
如，git push origin local-branch:remote-branch
git branch -d <branch>：删除指定的本地分支
git reset：回滚
- git reset --soft xxx（版本id）：回退到xxx版本，保留工作区和暂存区的所有修改内容
- git reset --hard xxx（版本id）：回退到xxx版本，丢弃工作区和暂存区的所有修改内容
- git reset --mixedxxx（版本id）：回退到xxx版本（默认） ，保留工作区的修改内容，丢弃暂存区的修改内容
xcopy /E /I repo repo-soft 复制repo目录到repo-soft上
git diff：默认比较工作区和暂存区的内容
git diff HEAD：显示工作区中与当前分支的最新提交（即HEAD指向的提交）之间的差异
git diff --cached：显示暂存区（staging area）与最近一次提交之间的差异
git rm：工作区和暂存区的文件同时删除
git rm --cached：只删除暂存区，保留工作区的文件
.gitignore：指定文件被忽略，这些文件不会被添加到暂存区
ssh-keygen -t rsa -b 4096：生成SSH Key
- 私钥文件：id_rsa
- 公钥文件：id_rsa.pub
git clone repo-address：克隆仓库
git push <remote><branch>：将本地分支推送到远程仓库
如，git push origin local-branch:remote-branch
git pull <remote>：从远程仓库拉取最新代码
如，git pull origin master
git merge：将代码合并到当前分支
如，git merge feature-branch
git tag：标记重要版本
如，git tag v1.0
添加远程仓库
1、git remote add <远程仓库别名><远程仓库地址>
2、git push -u <远程仓库名><分支名>
查看远程仓库：git remote -v
拉取远程仓库内容：git pull <远程仓库名><远程分支名>:<本地分支名>
（远程分支和本地分支如果相同可以省略“:<本地分支名>”）
三、补充
复刻fork，克隆clone，分支branch
- 复刻：在代码托管平台上创建远程仓库的副本，通常用于开源项目或协作项目
- 克隆：在本地计算机上创建远程仓库的副本，以便开发者进行本地开发和修改
- 分支：在Git仓库中创建一个新的开发线。允许开发者在不影响主线（通常是默认分支，如master或main）的情况下进行代码的开发和修改。分支通常用于实现新的功能、修复错误或进行其他独立的开发任务
Merge合并和Rebase变基
用于处理分支合并，区别：
-
Merge（合并）：
- merge将两个分支的提交历史合并成一个新的合并提交。
- 它保留了原始分支的提交顺序和历史。
- 适合多人协作开发的场景，因为可以追溯到历史的每一次提交。
- 生成的代码历史呈现网状结构，每个分支上都保留各自的代码记录，主分支只保留合并的历史记录。
-
Rebase（变基）：
- 命令rebase将两个分支的提交重新应用到目标分支上，生成一条线性的提交历史。
- 它始终将你最新的修改放到最前头，形成一条纯洁而干脆的线性历史。
- 更适合个人开发和整理分支的情况，保持提交历史的线性结构。
- 通常在自己的个人分支上使用，基于现有的主分支。
rebase更加稳定健壮，清晰直观；merge乱七八糟，不利于维护和理解
使用git上传文件到GitHub
1、git init // 将当前文件夹变成用git管理的文件夹
2、git add . // 将当前文件夹下的所有文件添加到缓存中
3、git commit -m "提交信息" // 将缓存中的内容提交到本地仓库
4、git remote add origin https://github.com/xxxxx/xxxxx.git
// 建立本地仓库和GitHub远程仓库的联系
5、git push -u origin master
// 将本地仓库中的代码推送到GitHub远程仓库，第一次推送加-u参数，之后推送就不用加-u参数
// 直接git push origin master
6、注意：你这里推送的是master，GitHub仓库可能主分支默认是main，推送能成功，但查看的时候注意自己在哪个分支使用git修改已提交到GitHub上的文件内容
1、在本地克隆项目：
git clone <项目的SSH或HTTPS地址>
2、修改文件内容：
使用文本编辑器（如VS Code、Sublime Text、Atom等）打开克隆下来的项目文件夹中的文件，并修改
3、查看文件状态：
在命令行中，导航到项目的根目录（即包含.git文件夹的目录），并运行以下命令来查看文件状态：
git status
这将显示哪些文件已被修改、新增或删除
4、将修改添加到暂存区：
git add .
git add <文件名>
5、提交修改：
git commit -m "修改了某个文件的内容"
6、将本地修改推送到GitHub：
确保已设置了远程仓库的别名（默认为origin），并且在正确的分支上（通常是main或master）：
git push origin main
如果推送时遇到冲突，可能需要先拉取远程仓库的最新更改并合并到本地分支，然后再推送：
git pull origin main
解决可能出现的合并冲突后，再次执行git add、git commit和git push命令
7、在GitHub上查看是否更改成功冲突
Git 在执行合并操作时会发生冲突。
冲突的发生是因为 Git 无法自动合并两个分支或提交的更改，而需要人工介入来解决。
以下是导致 Git 冲突的几种常见情况：
1. 同时修改了同一行代码：如果两个不同的分支或提交同时修改了同一行代码，Git 将无法确定应该保留哪个更改，从而导致冲突。
2. 删除了一个文件，而另一个分支修改了该文件：如果一个分支删除了某个文件，而另一个分支修改了同一个文件，则 Git 将无法自动合并这些更改。
3. 合并时指定了不同的基础版本：有时候在执行合并操作时，你可能会指定不同的基础版本，这可能会导致合并冲突。
4. 强制合并（--force）：如果使用 `git merge --force` 命令强制执行合并，而且两个分支有不兼容的更改，就会导致冲突。
5. Rebase 操作：在进行 rebase 操作时，如果发生了冲突，Git 会中止 rebase 进程，并让用户解决冲突后继续执行。
当发生冲突时，Git 会标记冲突的文件，并将冲突部分标记出来，需要手动编辑这些文件，解决冲突后再执行 `git add` 将文件标记为已解决，最后提交这些更改。
1128
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
