文章目录
Git 介绍
GIt历史
Git 安装
环境配置
-
git config --list 查看信息
-
git config --global user.name “your name” // 设置username
git config --global user.name "yourname" -
git config --global user.email “your_email@youremail.com” // 设置邮箱
-
git config user.name 查看username
工作区、缓存区和仓库区（版本库）
工作区(工作目录)
就是你在电脑里能看到的目录。 对于添加、修改、删除文件的操作，都发生在工作区中。包含.git文件夹的目录就是工作目录，主要用于存放开发的代码
暂存区
暂存区指将工作区中的操作完成小阶段的存储，是版本库的一部分
仓库区
工作区有一个隐藏目录.git,这个不是工作区，而是git的版本库，版本库中存储了很多配置信息、日志信息和文件版本信息等，其中最重要的就是称为stage(或者叫index)的暂存区，仓库区中记录的各版本是可以查看并回退的，但是在暂存区的版本一旦提交就再也没有了。
因为我们创建git版本库时，git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区【计算机的缓存区】，然后，一次性提交暂存区的所有修改，创建一个版本，放到master分支中。HEAD永远指向Master分支中的最新版本的。
git工作目录下文件的装填
Git工作目录下的文件存在两种状态：
- untracked 未跟踪（未被纳入版本控制）
比如说新建了个文件，没有git add。 - tracked 已跟踪的三种状态（被纳入版本控制）
- Unmodified 未修改状态
- Modified 已修改状态
- Staged 已暂存状态
Git 生成公钥及添加到gitlab或Gerrit上
通过SSH拉取代码时，实际上是通过公钥的验证机制来实现身份认证。具体过程如下：
1. 在本地电脑上，使用命令ssh-keygen生成一对公钥和私钥，将公钥保存在本地电脑的一个文件中（例如~/.ssh/id_rsa.pub）。
2. 将公钥（即上一步生成的文件中的内容）复制到服务器上。
3. 当你使用SSH协议从本地电脑连接到服务器并进行代码拉取或推送时，Git会自动查找本地电脑上的私钥，然后使用该私钥对身份进行验证，以确认是本地电脑所有者访问服务器。
4. 如果公钥与私钥匹配，服务器将接受身份验证并允许你访问代码库。
总之，通过SSH拉取代码时，需要确保本地电脑上的公钥已经添加到服务器中，以便在进行身份验证时可以让服务器确认你的身份。
- 进入ssh目录
cd ~/.ssh - 查看是否生成公钥
ls
2.1 若存在，则目录下会有后缀为.pub的文件，如果不存在就自己生成公钥
2.2 如果不存在，生成公钥
先通过git config --list查看自己的邮箱
再通过ssh-keygen -t rsa -C"你的邮箱"命令生成公钥 - 查看公钥
cat id_rsa.pub
- 复制公钥分别添加到gitlab和Gerrit上
git lab添加公钥如下：
gerrit添加和gitlab步骤一样。
Git常用命令
git stauts
查看文件状态
git statu -s
输出更简洁的文件状态。
git add
git add 命令可将该文件添加到暂存区。
-
git add 【file】【file2】…
添加一个或多个文件到暂存区
-
git add 【dir】
添加指定目录到暂存区，包括子目录
-
git add .
添加当前目录及子孙下的所有文件到暂存区。不在当前及子孙的目录没有添加到暂存区中。
-
git add -u
是把所有（不受当前目录）tracked文件（修改和删除）添加到暂存区。 -
git add -A （git add --all 的简写形式）
它会将当前整个工作区中所有的文件改动提交至暂存区，包括新增、修改和被删除的文件，不受当前所在目录限制。相当于
git add .和git add -u的结合 -
git add *.c
提交以.c结尾的文件。
git commit
git commit 命令一次性将暂存区所有内容添加到本地仓库中，并创建一个版本。
-
git commit -m [message]
提交暂存区到本地仓库中。 [message] 是备注消息
-
git commit [file1] [file2] … -m [message]
提交暂存区的指定文件到仓库区。
-
git commit -a 或者 git commit -am [message]
如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步，直接来提交。-a命令针对是tracked的文件（即已经放入仓库中的文件）。
-
git commit --amend
在上一个commitID上继续提交，不新增新的提交，默认打开VIM编辑器，是否要修改commit信息 -
git commit --amend --no-edit
可以不修改commit信息直接进行提交如果你没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。 如果 Git 在你对它的配置中找不到相关信息，默认会打开 vim。
注： 在 Linux 系统中，commit 信息使用单引号 '，Windows 系统，commit 信息使用双引号 "。所以在 git bash 中 git commit -m ‘提交说明’ 这样是可以的，在 Windows 命令行中就要使用双引号 git commit -m “提交说明”。
-
git commit编辑好了log。但是不想提交了，此时通过
q!退出就好了
q!和wq的区别就是
q!是强制退出，而不保存修改。
wq是保存修改并退出编辑器。
git reset
只执行git reset, 取消之前的git add操作，将已经add后的文件的暂存区状态恢复到工作区。
1. git reset --hard
后面不跟版本号，清除暂存区和工作区中tracked的改动。不会清除untracked的改动
其中HEAD表示当前分支最新版本【请记死】
HEAD^ 表示当前版本的前一个版本，
git reset --hard HEAD^
HEAD^^表示当前版本的前前个版本，也可以使用HEAD~1表示当前版本的前一个版本，HEAD~100表示当前版本的前100版本。
提示：这种都表示回退操作
git reset --hrad 版本号
回到指定的版本，这个存在两种情况。
这种情况需要注意：git reset --hard <commit> 这会将HEAD指向指定的提交并丢弃之后的所有提交。
- git reset --hard commit_id
commit_id 是完整的。并且是git log 能够查到的 否则会报错unknown revision or path not in the working tree. - git reset --hard (通过 git reflog 查到的)
为什么有两种情况呢，存在这种场景，比方说我们分别提交了两个版本1 和 版本2 ，提交顺序：版本1在前，版本2在后，当前Head指向版本2，现在执行git reset --hard HEAD^ 回退了一下，git log 看到的只有版本1的情况。即使你知道版本2的完整的commit_id ，执行git reset --hard commit_id 报错，只能通过
git reset --hard b79613 切换到版本2。
git reset --hrad origin/《分支名》
回退到某个远程分支某个commit。
有这样的场景，我们和远程分支相同的内容下，又做了修改，但是又想回退到和远程分支相同的情况，就可以执行这个。
2. git reset HEAD
撤销暂存区中的修改，从暂存区回到了工作区，既提交了，想撤回。但是本地的修改并不会消失(工作区的内容不会改变)。
-
git reset HEAD …
撤销指定文件的add
也可以指定不同版本的file -
git reset HEAD *
撤销本地add的所有文件
-
git reset HEAD *.txt
3. git reset <file>
撤销一个文件的git add操作。从暂存区返回至工作区状态。
git checkout -- <file> 是恢复到最新的一次提交的状态，相当于是撤回工作的去的修改。
4. git reset --soft HEAD^
撤销上一次提交，用于将当前分支的HEAD指向父节点，（即上一次提交），保留工作区和暂存区的更改。意思就撤销上一次commit。
git reflog
可以查看所有版本的历史信息
git reflog命令中保留了从clone仓库开始，用户所有在本地库中的操作。
参考：https://www.jianshu.com/p/7e4cef3863e7
git log
git log 命令只可以查看到HEAD指针及其之前的版本信息，如果版本发生过回退操作，则可能会出现，HEAD指针之后仍存在历史提交版本的情况，而这些提交版本信息通过git log命令是看不到的。
git log filename
git log filename 可以看到fileNmae相关的提交记录
git log -p filename
可以显示文件每次提交的diff
git log --graph
以图形化的方式显示提交历史的分支合并情况。可以了解某个人创建的分支是基于哪个分支创建的。
git show
git show filename
只看某次提交中的某个文件的变化。
git checkout
git checkout – “”
-
git checkout -- <文件> <文件> ...git checkout -- <文件>来丢弃工作区指定文件的改动, 恢复到最后一次提交的状态。即add后，还没有commit可以用这个。
2. git checkout *
丢弃工作区中所有文件的改动
git checkout -- *.txt
git diff
对比两个版本的差异
-
git diff
对比的是工作区修改之前和修改之后的差异。
-
git diff 版本1 版本2
对比的是版本1 和版本2 之间的差异
git diff HEAD HEAD^ -
git diff 分支1 分支2
-
git diff 文件
git stash
场景： 当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支bug-001来修复它，但是，等等，当前分支正在上进行的工作还没有提交：
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug,怎么办？
git stash ：git还提供了一个stash功能，可以把当前工作现场“储藏“起来，等以后恢复现场后继续工作。即缓存起来。
-
git stash save "save message"
执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。 -
git stash list
查看stash了哪些存储 -
git stash show
显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个git stash show stash@{1}
-
git stash apply
应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num}， 比如第二个：git stash apply stash@{1} -
git stash pop
命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num}，比如应用并删除第二个：git stash pop stash@{1} -
git stash drop stash@{$num}
丢弃stash@{$num}存储，从列表中删除这个存储 -
git stash clear
删除所有缓存的stash -
注意 untracked的文件，执行stash是不会被存储的。
新建了一个e.txt，e.txt并没有被加入到版本控制，git add 把文件加入到版本控制之后才行。
git rebase
参考：
https://blog.csdn.net/weixin_42310154/article/details/119004977
https://blog.csdn.net/qq_39512532/article/details/110260369
git branch
后面什么都不写，列出所有本地分支
-
git branch -r
列出所有远程分支
-
git branch -a
列出所有本地分支和远程分支
-
git branch <分支名>
创建分支
-
git checkoout -b <分支名>
创建并切换分支
-
git checkout -b 本地分支名x origin/远程分支名x
使用该方式会在本地新建分支x，并自动切换到该本地分支x。采用此种方法建立的本地分支会和远程分支建立映射关系（跟踪远程分支）。
-
git checkout <分支名>
切换分支
-
git merge <分支名>
合并分支到当前分支
-
git branch -d <分支名>
删除分支
-
git branch -m <旧分支名字> <新分支名字>
git branch -m master main
把master分支名字，改为新分支名字。
git clean
-
git clean -f
删除当前目录下所有untracked的文件. 它不会删除.gitignore文件里面指定 的文件夹和文件, 不管这些文件有没有被track过
-
git clean -df
删除当前目录下没有untracked的文件和文件夹
和git reset --hard 是一对好基友，结合使用他们能让你的工作目录完全回退到最近一次commit的时候
git remote
如果想查看已经配置的远程仓库服务器，可以运行 git remote 命令。 它会列出指定的每一个远程服务器的简写。 如果已经克隆了远程仓库，那么至少应该能看到 origin ，这是 Git 克隆的仓库服务器的默认名字
-
git remote
-
git remote -v
-
git remote add 添加一个新的远程 Git 仓库，同时指定一个可以引用的简写
这个使用场景式：我本地已经创建了git仓库，但是我想和远程仓库建立联系。即通过git remote add <shortname> <url>添加远程仓库。
-
git remote rm
如果因为一些原因想要移除一个远程仓库 ，可以使用 git remote rm
注意：此命令只是从本地移除远程仓库的记录，并不会真正影响到远程仓库
git fetch
git fetch 是从远程仓库获取最新版本到本地仓库，不会自动merge
git pull
git pull 是从远程仓库获取最新版本并merge到本地仓库
如果当前本地仓库不是从远程仓库克隆，而是本地创建的仓库，并且仓库中存在文件，此时再从远程仓库拉取文件的时候会报错（fatal: refusing to merge unrelated histories ），解决此问题可以在git pull命令后加入参数**–allow-unrelated-histories**
git push
当你想分享你的代码时，可以将其推送到远程仓库。 命令形式：git push [remote-name] [branch-name]
远程仓库 master分支多了 hello.txt文件。
git push <远程主机名> <本地分支名> : <远程分支名>
git push origin HEAD:refs/for/master
git push 肯定是推送
origin : 是远程的库的名字
HEAD: 是一个特别的指针，它是一个指向你正在工作的本地分支的指针，
可以把它当做本地分支的别名，git这样就可以知道你工作在哪个分支
refs/for :这个不是git的规则，而是gerrit的规则， 意义在于我们提交代码到服务器之后是需要经过 code review 之后才能进行merge的
refs/heads： 不需要
简单来说： refs/for/mybranch需要经过code review之后才可以提交；refs/heads/mybranch不需要code review
代码上传拿到git lab步骤
git blame
git blame用来追溯一个指定文件的历史修改记录
git blame用来追溯一个指定文件的历史修改记录。它是显示任何文件中每行最后一次修改的提交记录。 所以，如果你在代码中看到有一个bug，你可以使用 git blame 标注这个文件，查看哪一次提交引入了这行。
命令用法：
git blame filename
可以使用 -L 指定文件的行数范围：
git blame -L n1,n2 filename
举例
git blame -L 69,82 Makefile 查看Makefile这个文件第69--82行最近一次的修改记录
git 常用举例
git log输出格式
git log --pretty是指定Git log命令的输出格式。
git log --pretty=oneline // 将每个commit 以一行显示。包括了commit的SHA-1值和提交信息的第一行
查看一个文件提交的提交记录
查看一个文件的提交记录
git log filename // git log 直接与文件相关的提交记录
git log --pretty=oneline filename
查看单个文件提交记录及内容
git log -p filename
查看某次提交中的某个文件变化
git show commitId filename //使用git show命令 后跟commitId和文件名
显示每次提交的diff
git log -p filename
其他问题
- 克隆http和ssh有什么区别？
http不管你是谁，都可以下载【克隆】/提交项目代码。每次提交代码需要你输入用户名和密码；
SSH，如果你的电脑需要与github上的仓库交互，那么就要把你的电脑的ssh公钥添加到这个github账户上。
比如工作中你是ZXC这个项目组的成员，拥有者，你把你每天的代码——本地电脑跟github上公司项目交互，你得是这个项目的成员或者拥有者才能提交代码，这个方式就不需要输入用户名和密码提交代码，直接提交。工作中，你的老大会找你要你的github账号，邀请你到项目组，你是小组成员，为了方便提交代码，此时用SSH方式，工作中都是这种方式。SSH方式有一个条件要记住:你是项目的拥有者或组成员才可以使用此方法。知道这些就够了。
分支管理
(1)一开始的时候，master分支是一条线，git用master指向最新的提交，再用HEAD指向master,就能确定当前分支，以及当前分支的提交点：
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长
（2）当我们创建新的分支，例如dev时，git新建了一个指针叫dev,指向master相同的提交，再把HEAD指向dev,就表示当前分支在dev上：
git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件都没有任何变化。
3)不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
(4)假如我们在dev上的工作完成了，就可以把dev合并到master上。git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
git合并分支也很快，就改改指针，工作区内容也不变。
（5）合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
合并模式
- Fast-forward信息，Git告诉我们，这次合并是“快进模式“，也就是直接把master指向dev的当前提交，仅仅是更新了分支的指针，不会产生合并提交，所以合并速度非常快。默认的合并行为。
- 合并冲突，遇到合并冲突的时候，需要处理冲突内容，然后再add、commit提交。
- 但是有些快速合并不能成功而且合并时没有冲突，这个时候git会帮我们在合并之后做一次新的提交，但这种模式下，删除分支后，会丢掉分支信息。使用的命令是
git merge --no-ff <分支名称>不使用默认快速合并。
合并冲突
在master分支和dev分支对code.text文件有相同的位置修改了内容。合并两个分支的时候就会有冲突。
git用<<<<<<<<,========,>>>>>>>>标记不同分支的内容，我们修改如下后保存：
手动解决的方法就是删除箭头所指。然后再提交。
git 打补丁
参考：Git 补丁 —— diff 和 patch 使用详解
注意事项
- 跨系统拷贝git的代码，（比方说，你在Linux上拉取的代码，直接复制到Windows上去执行git操作），由于文件的属性变了（可能还有文件的权限），所以git操作会出现一些问题。如果想要在Windows上操作，尽量跨系拷贝，直接拉取代码即可。
333
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
