分布式版本控制git学习笔记

分布式版本控制git学习笔记

git介绍

• 使用版本号区分（sha1 得出的hash值）
• 可浏览历史版本记录
• 可还原到历史指定版本
• 对比不同版本文件差异

SVN与GIT

1 SVN -集中式版本控制工具

缺点是远端服务器挂了就gg了，但优点就是容易操作

GIT – 分布式版本控制工具

远端有一个代码数据库，而在每个本地都有一个本地数据，每个机器都是分布式中的一个节点，两两机器之间也可以进行协作。所以 Git 支持离线工作，在本地可以进行很多操作，包括接下来将要重磅推出的分支功能。而 SVN 必须联网才能正常工作

git的缺点就是相对来说比较复杂

基本概念

在远端（Remote）创建裸仓库

裸仓库也就是不存放具体代码，即如果服务器泄漏了，入侵者也拿不到具体代码,方法如下

jyhlinux@ubuntu:~/mathlib$ git init --bare

同时，远端仓库别名为 origin

git中用到http 、ssh、git这三种协议。

其中ssh协议最重要，是一个验证授权的网络协议，并且通常使用ssh公钥放到git服务器上，每次登录用私钥来验证登录git服务器。

从远端克隆代码到本地仓库

在远端服务器（Ubuntu）和本地节点（Win）上都要要创建公私钥，方法是输入

ssh-keygen -t rsa

1. 在远端服务器（Ubuntu上）到 ~ 目录下，进入.ssh文件夹，创建authorized_keys文件：

touch ~/.ssh/authorized_keys

2. 将本地节点上的公钥拷贝到 远端服务器上的 ~/.ssh/authorized_keys,本地节点上的公钥在

C:\Users\Administrator\.ssh\id_rsa.pub

3. 然后在本地节点的某一你指定的位置打开git Bash，输入如下指令进行clone远端服务器上某个文件夹

git clone ssh://jyhlinux@192.168.200.153:/home/jyhlinux/mathlib

git clone ssh://主机名@IP地址:想要克隆的远端服器上的文件目录

最后结果: .git是隐藏文件夹

git中各阶段的示意图

注意到：svn中是没有暂存区（index）的

基本操作

• 暂存区：暂存多次修改，然后一次性提交到Repository。

git add 能把文件提交到暂存区，若没有提交到暂存区，则文件是未被追踪的状态（untracked）:

提交到暂存区之后，可以看到暂存区中待commit的文件：

git push

将Repository（本地仓库）的文件推送到Remote(远端服务器)；

其中远端服务器别名为 origin,分支默认为master：

git push origin master

git pull

将最新文件从Remote拉取到workspace中。

注意fetch和 pull区别，

• fetch只是把远端记录拉取到本地仓库（Repository）；
• 而pull则是直接把改变的文件直接拉取到本地工作区（workspace）
• pull = fetch + merge

HEAD -> master中的HEAD

HEAD是一个指针，指向分支提交序列上最新一次提交。

git fetch

该指令只是拉取最近提交的信息出来到Repository，

逆向操作

index -> workspace(暂存区->工作区)

例如： 将sub.cc这个文件从暂存区回退到工作区

git restore  -S sub.cc

结果：

本地仓库->暂存区（repository->index）或工作区（Workspace）或直接删除

注解：

• 从Repository退回到index，使用git reset--soft;
• 从Repository退回到workspace，使用git reset--mixed;
• 从Repository直接删除，使用git reset --hard;

例子

$ git reset --soft head^
#head表示最新的提交，^表示到上一次，上方代码表示回退到上一次commit的状态

#直接将repository中最新一次提交丢弃掉
$ git reset --hard head^

从本地工作区直接删除修改（workspace->null）

git checkout . #将当前目录下所有修改撤销，新添加的文件不会删除

本地仓库整理操作

复用上一次提交

下图表示本地分支高远端分支两个版本，我们在本地再次做了修改，想要合并到最上面的这个提交中去

本地修改之后git add，然后使用如下指令：

git commit --amend #进入文档中，x保存之后则完成复用最新提交

再次git log查看状态，可以发现提交的信息没变，但是commit的序号改变了。

整理多次提交为一次提交

我们此时需要修改之前提交的 sub func

按如下操作：

git rebase -i

进入文档修改：

将sub func所在行开头pick修改为e （edit），然后输入 : 再输入 x，保存退出。

vim中wq和x的区别：

在没有变更内容的时候，x不会修改文件最后修改时间，而wq会修改最后修改时间。

随后修改 sub.cc文件，并进行git add sub.cc 操作， 将修改添加到暂存区

然后输入git commit --amend ,我们复用feat:sub func 这次提交，故直接保存

然后再回到终端主界面，输入git rebase --continuegit rebase --continue,完成整理多次提交。

将两次提交合并为一次提交

输入：git rebase -i,将两次提交开头进行修改

保存之后，跳出另一个文档，让我们重新修改提交记录，修改为：

再使用git log 查看：

注意

只有当 【没有人基于你的分支进行开发的时候】，才能用git rebase操作，因为从变基节点开始往后所有节点的commit id都会变化，可能导致其他人冲突。

分支操作

查看分支 git branch

创建分支

1. git branch develop #只创建
2. git checkout -b develop #创建并切换

切换分支

1. git checkout #还有回退的功能
2. git switch #后面版本增加的命令

合并分支（难点）

采用git merge解决冲突

1. 解决冲突
2. git add .
3. git commit . -i -m “…”

有一个fix:merge master 这个提交，表明解决冲突

采用git rebase解决冲突(不推荐)

git rebase 用于没有其他分支依赖的情况下，进行 合并提交与 合并分支

1. 解决冲突
2. git add. 标记解决
3. git rebase --continue;

git rebase master #将当前分支变基到master分支最新的提交位置

没有解决冲突的提交信息，给用户一种错觉，最新的提交是依赖于 feat:lshift func这次提交，这不正确。

注意：如何选择merge还是rebase

是否有其他人依赖我当前的分支？没有依赖我当前分支：可以用git rebase
有依赖我：必须用 git merge，因为git rebase变基之后 commit id发生变化

心得体会

git只要有个概念就好了，这种东西不用感觉也很容易忘记。对基本操作（add、commit、push、fetch…）逆向操作（git reset）和分支操作（git rebase、git rebase）大概原理有个印象应该可以了，未来到工作中再用用应该就熟悉了。