git分布式版本控制系统

Posted 2021-12-08 wangjie-nf

版本管理工具（vcs）之git分布式版本控制系统

特点

分布式版本控制（成员的计算机上都有完整的版本库）

多人协调工作（强大的分支能力）

有效监听谁做的修改（提交、合并是添加信息）

本地及远程操作（个人计算机和公共服务器）

 

下载安装

https://git-scm.com/download/win

 

使用前的设置

git --version // 查看当前git版本

git config --global user.name ‘your name’ 　　// 全局设置自己的名字

git config --global user.email ‘email’　　　　 // 全局设置自己的邮箱名字

ssh-keygen -t rsa -C " your email " 　　　　// 创建SSK Key

 

常用命令

创建新的本地储存库

git init      　　// 创建新的本地存储库

　　添加

git add <file> 　　// 添加文件

git add . 　　　　// 添加所有文件

　　提交

git commit -m ‘notes’ 　　// 提交并添加注释

　　撤销

git checkout -- <file>　　　　 // 拉取暂存区的文件替换工作区的文件

git reset HEAD <file> 　　　　// 拉取版本库的文件替换暂存区的文件

git reset -- hard commit_id 　　// 版本切换

　　查看

git diff <file> 　　// 比较的是工作区文件和暂存区文件的区别（上一次 git add 的内容）

git diff -- cached <file> 　　// 比较的是暂存区的文件和仓库分支里的区别（上一次 git commit 后的内容）

git status 　　   // 查看目录中已更改的文件

git log 　　　　// 查看所有的提交日志

　　删除

git rm <file>　　 // 删除暂存区和工作区的文件

　　分支

git branch <name> 　　// 创建分支

git checkout <name> 　　// 切换分支

git checkout - b <name>　　 // 创建并切换到分支

git checkout -t origin/<name>　　 //基于远程创建本地分支（先克隆，-t：使用远程分支名为本地分支名）

git branch -vv　　　　 // 查看本地分支（输出列表中前门带*是当前所在分支）

git branch -a 　　　　// 查看所有分支

git merge <name> 　　　　// 合并分支，Fast forward方式

git merge --no-ff -m’zhushi’ <name> 　　// 合并分支，--no-ff模式

Bit branch - d <name> 　　　　　　// 删除分支（并没有删除记录）

git push origin --delete<name> 　　// 删除远程分支

　　远程

git push -u origin master 　　　// 推送到远程master 分支并且关联上

git pull 　　　　// 从远程仓库获取最新的版本然后和本地的合并

git clone url　　 // 从远程仓库拷贝数据

git remote -v 　　// 查看远程地址

 

工作区和暂存区

在一个文件夹中使用git init命令创建了一个本地储存库后，该文件夹就被称之为工作区，我们新建文件/文件夹、修改文件/文件夹，这些改动都是工作区的改动。

当文件改动后使用git add 添加命令时，其实就是将改动添加到了暂存区，git commit 提交命令也只是提交暂存区的改动。

也就是说，假设改动了a文件和b文件，但是只git add 了a文件并提交，版本库中的b文件虽然更新了，但是版本库中的a文件任然是以前的。

 

撤销操作

场景1： 当改动了工作区，但未使用git add添加时，可以使用git checkout -- <file>，撤销工作区的改动，其实是将暂存区的file保存给了工作区。

场景2： 当不仅改动了工作区，还使用了git add添加时，可以使用git reset HEAD file 回退到场景一，然后在使用git checkout -- file，撤销工作区的改动。

场景3：当提交了改动后，可以使用下面介绍的版本回退。

 

版本切换

使用的命令： git reset -- hard commit_id // 版本切换。

每提交一个新版本，实际上Git就会把它们自动串成一条时间线，并记录了唯一的commit_id。

版本切换前，使用git log查看提交历史，确定要切换到那个版本和对应的commit_id，如果记得是前几个版本，可以用HEAD~数字，代替commit_id。

当回退到之前的版本后，git log 将不能查到 在该提交历史之后的提交记录，所以要使用git feflog 查看命令的历史。

 

删除和找回

git rm <file> // 删除暂存区和工作区的文件。

如果在执行了git rm <file>的基础上再执行git commit，那么就会删除版本库中的文件。

至于找回，分下面三种情况。

1  如果用rm、del或者资源管理器删除文件，其实只是相当于删除了工作区的文件，可以使用git checkout -- <file>恢复。

2 如果用的是git rm删除文件，那么就是删除了工作区和暂存区的文件，此时用git checkout -- <file>，在暂存区是找不到该文件的，需要使用git reset HEAD <file>，该命令是拉取了版本库中的文件添加或替换到暂存区，接着你就可以使用git checkout -- <file>找回删除的文件了。

3 在git rm操作的基础上还执行了git commit，那么想找回文件智能先切换到最近的版本（上面介绍的版本切换），然后再按第二种的情况找回文件。

 

远程仓库

　　概念

在git中，远程仓库是一台公共的服务器，每个人都从这个服务器中克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。可以找一台电脑充当该服务器，也可以使用GitHub网站。GitHub网站为我们提供的服务有免费和付费，选择免费那么git仓库是公开的，别人可读不可写，还有付费的，别人不可读不可写。

设置SSH

由于GitHub要识别这个用户推送过来的提交是否要接收，不能随便什么用户都可以提交到该账号，而git支持SSH协议，所以GitHub只要知道用户的公匙，就可以确定该用户的提交可以接收。

执行ssh-keygen -t rsa -C  " your email "    // 创建SSK Key 以后，会在用户主目录下创建一个.ssh文件夹，里面有两个文件，分别是私匙id_rsa公匙id_rsa.puh，其中私匙不能告诉别人，公匙填到下图5中，Title可以随便填，最后点击保存。

 

　　添加ssh-keygun到环境变量

本人第一次操作的时候提示ssh-keygen不是内部或外部命令，原因是ssh-keygen没有加入path环境变量，解决方法：

复制ssh-keygen.exe所在目录，ssh-keygen.exe往往是在Git > usr > bin里面，然后右键我的电脑 > 属性 > 高级系统设置 > 环境变量 > 系统变量 > 选择path项、编辑 > End到最后，输入分号，粘贴复制来的ssh-keygen路径 > 保存。

创建远程仓库并同步

在本地创建了一个git仓库后，想其他人也能访问这个git仓库一起协作，那么就需要在GitHub中创建一个git仓库，并将本地的git仓库与之同步。

 

图1

 

 

图2

 

 

图3

首先需要关联远程仓库的地址，输入图3的1代码。

然后再输入图3第的2代码推送上去，然后刷新页面可以发现GitHub上的仓库和本地仓库的一样了。

第一次推送时，需要在git push的后加上“-u”这个参数，这个“-u”参数，可以是分支关联起来，以后再次推送该分支时就不需要了。

当你第一次使用git的clone 或者push命令连接GitHub时，会得到一个警告：

 　　

这是因为git使用SSH连接，而SSH连接第一验证GitHub服务器的Key时，需要你确认GitHub的Key指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

然后git还会输出一个警告，告诉你，已经把GitHub的Key添加到本机的一个信任列表里了。

 　　

 

分支

　　创建分支与合并分支

每次commit提交，Git都把提交串成一条时间线，这一条时间线就是一个分支。在Git里，这条初始的分支叫主分支或主线，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支，如下图　

　　

在分支中的增删不会影响主线。例如在主线中只有一个a.txt的空文件，然后新建并进入一个branch分支，在该分支中创建一个b.txt文件，并且在主线a.txt中的添加了内容，执行add 和commit操作后，切换回主线会发现，还是只有一个空的a.TXT文件。只有当把branch 合并到主线，主线中的a.txt才会有相应的内容，并且多了一个b.txt文件。

git merge合并分支后可以看到输出了Fast-forward信息，这是git告诉我们该合并模式是“快进模式”，合并完成后，就可以删除分支了。流程如下图

    

用Fast-forward模式合并分支后删除分支，会丢掉分支的信息，所以一般使用--no-ff方式的git merge。因为--no-ff方式合并要创建新的commit，所以要加上-m参数，把commit描述写进去推送分支

推送分支

git push的一般形式为 git push -u <远程主机名> <本地分支名>，注意这里的 -u 这可以让本地的当前分支和远程的对应的分支关联上，用git branch -vv 可以看到下图中使用带“-u”参数的推送 login 和master已经关联上，而不使用“-u”参数推送的 sup 则没有。

关联上分支后，再次推送分支时，只需要写git push，Git会就可以自动推送到关联的远程分支上了，非常的方便。

如果远程仓库没有该分支，则会在远程仓库中自动创建，

 　　

分支合并失败

当两条要合并的分支都发生提交时，往往就会合并失败，提示你合并发生冲突，那就需要手动解决冲突再提交

解决冲突就是把合并失败的文件手动编辑为我们希望的内容。比如下图，假如你在feature1分支中对空的index.js文件写入一段代码，然后提交了。而在你合并以前，同事先向主线合并了它的分支，他的分支也是在index.js文件中写入一段代码。那么当你合并时就会失败，提示你发生冲突，需要你手动去编辑index.js文件，假如两段代码是同一个功能那就确定最终的一段代码（正常的团队是不会出现这种情况的）；如果分别是两个功能，那就都保留

　　

用git log --graph命令可以看到分支合并图

分支管理策略

master主分支应该是非常稳定的，一般仅用来发布新版本，平时都是在master分支的下面工作

比如master分支的下面有一个dev分支，在dev分支的下面还有一个michael分支和bob分支，master是一个版本1.0.0

平时都是在dev分支上工作

具体到每个小伙伴都是在dev分支上干活，并且有自己在dev分支里的分支，时不时地往dev分支上合并，等dev分支完成了，那么就可以合并到master上发布新的版本了

 

 

 

突发任务处理

git stash   // 储存当前分支

git stash list    // 查看储存的分支

git stash pop //  恢复储存的分支

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来

当所在分支任务还没结束，又接到一个紧急任务时，可以使用git stash把当前的分支储存起来

处理完紧急任务后，在使用git stash pop 恢复储存的分支

 

多人协作

从本地推送分支，使用git push origin <name>

如果推送分支失败，往往是因为远程的分支有了新的推送，导致了冲突，方法是先Git pull 抓取下来手动合并，然后再推送

在git pull操作是如果提示 no tracking information，则说明本地分支和远程分支没有创建连接关系，使用命令 git branch --set-upstream-to <name> origin/<name>

 

拉取远程分支

使用git clone 从远程仓库拷贝数据，里面只有一个master分支，如果想克隆远程仓库的其它分支，如login分支，可以使用git checkout -t origin/login，既可以拷贝远程的分支，而且还关联上远程分支了

 

忽略一些不想上传的文件

在项目下创建一个文件 .gitignore，之后将不想上传的文件或者文件夹写 .gitignore配置文件中。

可以在.gitignore中使用以下语法

# // 表示注释

page.txt // 忽略page.txt文件

*.log // 忽略以.log结尾的文件

/vendor // 忽略vendor文件夹

.gitignore配置文件中是按行从上到下规则匹配的，也就是说，一行代表一条规则

创建.gitignore配置文件的时候建议使用命令行创建，因为win系统在资源管理器中不能创建文件名为空的文件

.gitignore 也需要放到版本库中，对其进行版本管理

 

创建README.md自述文件，

.README.md自述文件有助于对此存储库感兴趣的人了解您的项目，文件的内容将会在GitHub中展示