集中式版本控制系统，版本库是集中存放在中央服务器的，分工开发项目时，每个人都需要用自己电脑从中央服务器上拉取最新的版本，然后开始工作，等工作完了，再把自己写的功能提交到中央服务器。

中央服务器好比是一个图书馆，你要改其中的一本书，必须先要从图书馆里把书借出来，然后更改，改完之后，再放回图书馆。

集中式版本控制系统必须联网才能工作，所以对于网络环境比较差的情况使用集中式版本控制系统是很不方便的。
分布式版本控制系统没有中央服务器的概念，而是使用相关的客户端提取文件，这个文件是把代码仓库完整的镜像下来，即复制了一份，相当于每个人的电脑里都有一个完整的版本库，多人开发时，版本库出问题了，任何一个开发者都可以随时创建一个新的仓库然后同步就可，且不存在网络差的影响，因为版本库就在本地电脑上，可以离线工作。

比如说你修改了A文件，你的同事也修改了A文件。这个时候只要把自己修改的部分推给对方，对方就能够看到你的修改。

svn

文件管理集中管理，不会随意更改，可通过权限控制到具体的文件

git

代码的管理

Git

1、安装

Git官网地址：Git (傻瓜式安装即点下一步即可完成安装)

Standalone Installer 独立安装，即安装包

Portable ("thumbdrive edition") 便携式（驱动安装），即压缩包

注意：选择安装包，64位系统

点击普通程序安装

接受协议，点击next 下一步

选择安装目录，不要安装在C盘

保留默认勾选选项，点击next 下一步

选择git 编辑器，保留默认即可，点击next 下一步

选择git 初始化时创建的分支名，第一项默认master 第二项自定义分支名，保留默认设置，点击next 下一步

设置环境变量，即git 的使用范围，保留默认设置即可，点击next 下一步

选择ssh 连接工具，保留默认设置即可。点击next 下一步。

选择在加密连接时使用的证书，保留默认设置即可，点击next 下一步

配置换行符，unix和windows机制不一样，保留默认设置即可。

配置终端模拟器以与Git Bash一起使用，保留默认设置即可，点击next 下一步

使用git pull命令时默认的模式，保留默认设置即可。

是否启用登录管理助手，保留默认设置即可。

配置额外选项，保留默认设置即可，点击next 下一步

是否启用新功能，去掉勾选选项，点击install 安装

安装完成，点击finish。 view Release Notes 表示查看发行说明，点击完成后会跳到发行说明页。

检验是否安装成功：鼠标右击桌面，会出现git 操作图标即安装成功

操作图标如下：

git Bash Here 命令行模式 我们选择使用命令行模式打开

git GUI here 图形界面

在这里插入图片描述

提示：调整git 命令窗口大小 ctrl+ + / ctrl + - 放大/ 缩小

2、了解基本的Linux命令

电脑底部工具栏搜索cmd，选择打开，弹出命令行窗口。

cmd命令是一种命令提示符，CMD是command的缩写，也叫命令提示符，位于C:\Windows\System32的目录下。

D:   // 点击回车，进入盘符

mkdir 文件夹名称  //新建一个文件夹

cd 文件夹   //进入文件夹

cd ..   //返回上一级文件夹

rmdir 文件夹名称 // 删除文件夹

calc  // 调用window计算器

notepad // 打开记事本

ipconfig  // 查看电脑ip配置

使用cmd快速进入文件夹方法：

进入文件夹，点击文件夹目录url，直接输入cmd 即可调出命令行窗口且定位到当前目录

3、配置git 用户名和邮箱

每次Git提交都会使用该信息

git config --global user.name "zhang"

git config --global user.email "18295845421@qq.com"

以上命令中 –-global为可选项，代表全局配置，意思是只要向git 提交信息，将会使用该信息

如果你希望在不同的项目中使用不同的用户名和邮箱地址，可以在该项目中运行上面命令时不加–global选项

查看设置信息

git config -l   // 会显示配置信息  l 为list 简写形式

git config --list    // 输入wq  回车  返回到命令行

4、git 工作模式

git 工作区域

四个区域：工作区、暂存区和本地仓库，远程仓库

Workspace：工作区，存放项目代码的地方。只要文件发生了更改，会显示追踪与未追踪文件状态

Stage：暂存区，用于数据暂时存放的区域，事实上它是一个文件，保存即将提交的列表信息

local Repository : 本地仓库，是安全存放数据的位置，存放提交到所有版本的数据

Remote Repository：远程仓库，托管代码的服务器

以上几个工作区我们操作的只有工作区和远程仓库，暂存区和本地仓库我们需要通过命令操作。

在这里插入图片描述

git 工作流程

添加/修改文件 — 将工作区文件添加到暂存区 — 将暂存区文件提交到本地仓库 — 将本地仓库代码推送到远程仓库

git 关键字

HEAD 当前版本的指针，当切换本地版本的时候会快速指向指定版本文件

master git为我们创建主分支

origin 远程仓库的名称

git文件管理状态

三种状态：已修改（modified）,已暂存（staged）,已提交（committed）

5、git 项目管理

创建本地仓库（初始化本地库）

可以手动新建一个文件夹，专门用来git管理，执行以下命令

git init

或者用命令创建文件夹

mkdir test   // 新建一个目录  test

cd 目录名称  // 进入某一个目录

touch "a.html"  // 新建一个文件  或者直接把文件拉进 .git所在文件夹  

git init

用git 自带编辑器 vim 创建文件

 vim 1.txt   // 执行后进入编辑文件模式  
 
 按 insert开始写文件
 
 写好以后按ESC 停止，按:wq 回车 返回到命令行   // wq 代表写并且退出

执行命令后文件夹会多出了一个.git目录。

如果没有.git目录，默认隐藏，选择文件夹菜单栏—查看— 勾选显示隐藏文件选项

克隆远程仓库

git clone 远程仓库地址

多用于拉取别人的项目或者自己的远程仓库里的项目

例如：从gitee上克隆别人代码代码

git clone https://gitee.com/mjpclab/jquery-tab.git

查看文件状态

git status  // 查看所有文件状态

git status 文件名  // 查看特定文件状态

红色：表示当前处于工作区；绿色：表示当前处于暂存区

文件状态说明

版本控制就是对文件的版本控制，要对文件进行修改，提交等操作，首先要知道文件当前什么状态，可能会出现提交了不想提交的文件，或者要提交的文件没提交上的情况。

1、单词扩展：

Untracked 未跟踪的 Unmodify 未修改的，未调整的 Modified 已修改已调整的 Staged 已暂存的

2、以下是文件的四种状态

Untracked:未跟踪，此文件在文件夹中，但并没有加入到git仓库，不参与版本控制.通过git add 状态变为Staged.
Unmodify:文件已经入库，未修改(即与版本库中的文件内容完全一样)。这种类型的文件有两种去处，如果它被修改，而变为Modified，如果使用git rm 移出版本库，则成为Untracked未参与版本控制文件.
Modified:文件已修改，仅仅是修改，并没有进行其他的操作.这个文件也有两个去处，通过git add可进入暂存staged状态，使用git checkout，则丢弃修改过，返回unmodify状态，这个git checkout即从库中取出文件，覆盖当前修改！
Staged：暂存状态，执行git commit则将修改同步到库中，这时库中的文件和本地文件又变为一致，文件为Unmodify状态.执行git reset HEAD filename取消暂存，文件状态为Modified

添加文件到暂存区

添加单独文件放在暂存区
```
git add test.txt
```
添加多个文件
```
git add a.txt  b.txt c.txt
```
添加一个文件夹放在暂存区（暂存区不能放空文件夹）
```
 git add css/
```

添加所有文件到暂存区、

git add --all  //  工作区所有内容都添加到暂存区

git add .   // Stage  注意空格  暂存区的文件都是覆盖的

// 只要文件在 `Changes to be committed`这行下面的，就说明是已暂存状态。

注意：可能会发生以下警告，暂不处理

warning: in the working copy of 'b.txt', LF will be replaced by CRLF the next time Git touches it

// 这里意思是转换换行符成功
// Dos/Windows平台默认换行符：回车（CR）+换行（LF），即’\r\n’
// Mac/Linux平台默认换行符：换行（LF），即’\n’
// 使用git来生成一个工程后，文件中的换行符为LF， 当执行git add .时，系统则提示：LF 将被转换成 CRLF

删除暂存区文件

git rm --cached 文件  // 只表示将暂存区的file文件删除  add 错误时可删除暂存区，重新add新文件

撤销暂存区文件

通过git add命令从工作区将文件添加到暂存区之后，发现文件添加错误时，可撤销回工作区，撤回后状态变为未跟踪的 Untracked

git reset . // 撤销全部

git reset 文件  // 撤销某个文件

git restore --staged  文件   // 撤销add 命令

提交暂存区文件到本地仓库

git commit -m "提交的信息说明"  //记录每一次的修改内容，比如修改了图片文件等

查看提交（历史）记录

git log   // 方便查看回到哪个版本

回退提交版本

即撤销当前提交（commit），恢复到上次提交

git reset --hard HEAD^    // ^ 上个版本

git reset --hard HEAD~1  // ~1 上个版本

在Git中，用HEAD表示当前版本，也就是最新的提交。

上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上100个版本写成HEAD~100。

回到上一个版本，查看历史，发现当前版本没有了，但又想回到当前版本

查看命令历史

git reflog

根据命令历史显示的提交id ，确定回到哪个版本

git reset --hard commit_id

查看修改内容

git diff

撤销文件修改内容

本地文件修改后发现修改错误或者改乱了本地git管理文件夹某个文件的内容，回到更改之前

git checkout -- 文件

删除本地文件（非版本库）

rm 文件  // rm hello.txt

删除版本库（.git管理的）文件

git rm 文件  // 删除完再次提交 git commit

取消版本控制

git rm --cached

git 退出命令

保存并退出：

按 Esc 键退出编辑模式，英文模式下输入 :wq ，回车

按 Esc 键退出编辑模式，大写英文模式下输入 ZZ ，回车

不保存退出：

按 Esc 键退出编辑模式，英文模式下输入 :q! ，回车

　按 Esc 键退出编辑模式，英文模式下输入 :qa! ，回车

以上所有命令都是在本地仓库执行

命令练习

新建文件，查看文件状态
将文件添加到暂存区，查看文件状态
将暂存区文件提交到本地仓库，查看文件状态
修改文件，查看文件状态
改错了，撤销，查看文件状态
重新修改，提交，查看提交历史记录
发现提交后错误，撤销回退版本
删除本地文件和仓库文件并提交

克隆远程仓库

git clone 远程仓库地址

多用于拉取别人的项目或者自己的远程仓库里的项目

例如：从gitee上克隆别人代码代码

git clone https://gitee.com/mjpclab/jquery-tab.git

推送到远程仓库

git push

从远程仓库拉取数据

git pull

6、git 分支

分支的作用

假如准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你可以创建了一个属于你自己的分支，别人看不到且还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

扩展：

生产环境 ：线上环境基于域名线上的网址

开发环境：本地环境基本本地服务器，一般为后台电脑或者自己电脑

master 分支 ：master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性

dev分支 ：develop 为开发分支，始终保持最新完成以及bug修复后的代码

release分支：release 为预上线分支，发布提测阶段，会release分支代码为基准提测

以上术语在实际开发中很常见。

master分支

在版本回退里，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

创建分支

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

可以发现Git创建一个分支时，增加一个dev指针，修改了HEAD的指向，但工作区的文件没有任何变化。

但对文件的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变。

合并分支

当我们在dev上的工作完成了，就可以把dev合并到master上，即把master指向dev的当前提交，就完成了合并：

从图上看：Git合并分支需要改HEAD指针，工作区内容也没变。

合并完分支后，如果不需要可删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

git 分支命令

注意：要先commit之后才会真正建立master分支,此时才可以建立其它分支。

创建和切换分支( 2 种写法 )

git checkout -b 分支名   // git checkout -b dev  

git switch -c <name>   // 创建和切换分支

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch 分支名   // 创建分支    git branch dev
git checkout 分支名 // 切换分支    git checkout dev


git switch <name>   // 切换分支

查看当前分支
```
git branch
```
git branch命令会列出所有分支，当前分支前面会标一个*号。
提交文件到dev 分支
```
git add 文件  // git add dev
git commit -m "提交到dev分支了"
```
现在，dev分支的工作完成，我们就可以切换回master分支
切换分支
```
git checkout master
```
切换回master分支后，再查看工作区文件，发现文件内容变成原来没修改的样子了，因为那个提交是在dev分支上，而master分支此刻的提交点并没有变，所以文件也是master分支时的内容。
合并分支
```
git merge 分支名  // git merge dev  看不出来做过合并
```
git merge命令用于合并指定分支到当前分支。合并后，再查看本地修改过的内容，就可以看到，和dev分支的最新提交是完全一样的。

实际开发中，我们希望看到合并的历史有分支，即能看出来做过合并
```
git merge --no-ff -m "合并信息" 分支名  //   git merge --no-ff -m "合并dev了" dev
```
合并完成后，就可以放心地删除dev分支了。
删除分支
```
git branch -d 分支名 // git branch -d dev
```
删除后，查看分支，只剩master 分支了
```
git branch
```

合并冲突

场景：当你和同事在不同的分支修改同一个文件，然后一起合并到master 分支，此时会发生冲突。

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

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

这里以master 和新分支 newb 来演示：

1、新建并切换分支newb

git switch -c newb

2、修改工作区文件（本地文件）

3、提交到newb 分支

git add .
git commit -m "第一次提交到newb分支"

4、切换master分支，并修改文件

git switch master

5、在master 分支修改完，提交文件

git add .
git commit -m "第一次提交到master分支"

现在master分支和newb分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

6、合并master 和 newb

git merge newb

合并后，出现以下：

$ git merge newb
Auto-merging b.txt
CONFLICT (content): Merge conflict in b.txt
Automatic merge failed; fix conflicts and then commit the result.

Git告诉我们，b.txt文件存在冲突，必须手动解决冲突后再提交。

执行git status也可以查看冲突的地方：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

此时，我们去查看本地文件：

123
<<<<<<< HEAD
我是master 分支修改了
=======
现在我在newb我修改了
>>>>>>> newb

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改成正确代码后保存且提交：

git add b.txt 
git commit -m "解决冲突了"

现在，master分支和feature1分支变成了下图所示：

查看分支合并图

git log --graph

7、合并后，就可以删除newb分支了

git branch -d newb

查看分支

git branch

总结

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容后，再提交。

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

托管平台远程仓库

Git 远程仓库

计算机A 、B、C 将文件提交到一个地方，这个地方就是远程仓库

目的：备份代码，实现代码共享集中化管理

即在本地创建了一个Git仓库后，又创建一个远程Git仓库，并且让这两个仓库进行远程同步，这样，远程仓库既可以作为备份，又可以让其他人通过该仓库来协作，实现代码共享。

基于Git常见的代码托管中心

GitHub （国外的）作为开源代码库，目前仍然是最火的开源项目托管平台，GitHub 同时提供公共仓库和私有仓库，但如果使用私有仓库，是需要付费的。

GitLab （国外的）可以创建私人的免费仓库，且可搭建自己的私人服务器（即代码在自己家）

Gitee （国内的）即码云，是 oschina 免费给企业用的，不用自己搭建环境（即代码在别人家），可以建立私有仓库。

总结：

相比较 GitHub ，GitLab 让开发团队对他们的代码仓库拥有更多的控制，比如：可以设置获取到团队整体的改进进度，设置资源权限等

所以，从代码的私有性上来看，GitLab 是一个更好的选择。但是对于开源项目而言，GitHub 依然是代码托管的首选。而对于Gitee ，因为无私服，即不能保证代码的安全性，一般不用。

Gitee

使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况，所以个人可以使用国内的Git托管服务—Gitee

官网：Gitee - 企业级 DevOps 研发效能平台

一、注册gitee

二、创建项目远程git仓库

注意事项：

1、gitee 只支持先创建私有仓库，创建完成后可更改为公有。

2、Readme：项目仓库自述文档，通常包含有软件的描述或使用的注意事项。

三、关联本地仓库和远程仓库

git remote add origin git@gitee.com:zhangmei3322/test.git

注意修改成自己的用户名/项目名称—zhangmei3322/test.git

查看远程库信息

git remote -v

出现下面信息说明已经关联成功

git remote -v
origin	git@github.com:michaelliao/learngit.git (fetch)
origin	git@github.com:michaelliao/learngit.git (push)

四、生成密钥

桌面右键 Git Bash Here 打开git命令行
生成密钥文本 ssh-keygen -t rsa -C "git邮箱" （全部按enter，提前设置git邮箱）
```
ssh-keygen -t rsa -C "git邮箱"
```
自己的git邮箱查看：使用命令： git config --list --global
我的电脑找密钥文本 C:\Users\Administrator.ssh ，找到 .ssh文件夹，打开 id_rsa.pub 文件，复制里面的内容
回到gitee，找到设置 — 安全设置 — SSH公钥— 粘贴内容，验证即可，提前登录邮箱

验证密钥是否成功

ssh -T git@gitee.com

出现下面就成功了

$ ssh -T git@gitee.com
Hi 张同学! You've successfully authenticated, but GITEE.COM does not provide shell access.

五、把本地库的分支推送到远程库

默认master是本地库总分支，即将本地master分支推送到远端origin分支（远程仓库默认分支是origin）

git push -u origin master

如果要推送其它分支到远程origin分支，比如dev分支，则命令如下：

git push origin dev

注意：

第一次push推送，会有SSH警告:

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

输入yes即可

注意：创建项目时未勾选readme.md 文件，则会报错：

$ git push -u origin master
To gitee.com:zhangmei3322/test.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'gitee.com:zhangmei3322/test.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

出现错误的主要原因是gitee中的README.md文件不在本地代码目录中。

解决方法：

（1）可以通过如下命令进行代码合并【注：pull=fetch+merge】

git pull --rebase origin master

（2）再执行命令：

 git push -u origin master

出现下面即完成：

$ git push -u origin master
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
后面不管

推送成功后，可以立刻在Gitee页面中看到远程库的内容已经和本地一模一样：

从现在起，只要本地作了提交，就可以通过命令：git push origin master, 把本地内容最新修改推送至远程仓库Gitee

删除远程库

git remote remove origin

常见错误一

git push -u origin master
git@gitee.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

错误原因：没有在Gitee设置SSH keys

重新生成密钥，再次执行

常见错误二

fatal: 'origin' does not appear to be a git repository 
fatal: Could not read from remote repository. 
Please make sure you have the correct access rights and the repository exists.

错误原因：本地和远程连接断开了或者连接错误，找不到远程仓库

本地和远程连接断开的解决方案：

1、分别查看本地和远程分支

git branch    // 查看本地分支

git remote -v  //查看远程分支

分别执行以上命令，如果git没有自动出现回复

需要执行本地和远程连接命令

git remote add origin git@gitee.com:自己用户名/仓库名.git  // zhangmei3322/zz.git

再次查看远程仓库，git 回复如下则建立连接成功，成功后再去push

$ git remote -v
origin  git@gitee.com:zhangmei3322/zz.git (fetch)
origin  git@gitee.com:zhangmei3322/zz.git (push)

本地和远程连接错误的解决方案：

依次执行以下命令：

git remote -v  // 查看仓库信息是否正确

git remote remove orign  // 删除远程仓库

git remote add origin git@gitee.com:用户名/仓库名.git  // 重新添加远程仓库

git push -u origin master  // 推送信息到远程仓库

常见错误三

执行推送命令 git push -u origin master ，出现以下错误

出现原因：gitee上创建远程仓库的时候勾选了添加README.md文件

$  // 执行
To gitee.com:zhangmei3322/zz.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'gitee.com:zhangmei3322/zz.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

报错原因：是因为gitee中的README.md文件不在本地代码目录中。

gitee允许你本地仓库有的东西，远程仓库里没有，但不允许远程仓库有的东西，你本地仓库没有。

解决方法：

（1）在推送之前需要先拉取远程仓库代码和本地仓库代码合并【注：pull=fetch+merge】

git pull --rebase origin master

（2）再执行推送命令，即可完成代码上传到gitee。

git push -u origin master  // 远程和本地相关联 且 本地推送到远程

执行完（2）可能报错：

error: failed to push some refs to ‘http://xxx/backend.git’
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

重新执行：git pull --rebase origin master

fatal: It seems that there is already a rebase-merge directory, and
I wonder if you are in the middle of another rebase.  If that is the
case, please try
        git rebase (--continue | --abort | --skip)
If that is not the case, please
        rm -fr ".git/rebase-merge"
and run me again.  I am stopping in case you still have something
valuable there.

执行：git rebase --continue

再执行：git push -u origin master

六、远程推送冲突

在实际开发中，远程分支会有多个，基础的为：主分支，预上线分支，开发分支。

当你的小伙伴已经向某个远程分支提交了他的内容，而你也碰巧对相同的文件作了处理，并试图推送：

若出现如下信息，即推送失败

$ git push origin dev
To github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

解决办法：先用git pull把最新的代码提交从远程分支抓下来，然后，在本地合并，解决冲突，再推送：

拉取远程最新代码并合并到本地
```
git pull origin master  
```
发现文件会有冲突，需要手动解决。解决的方法和上面目录git分支中的合并冲突解决完全一样
解决冲突后，再次推送你的代码到远端
```
git push origin 分支名  
```

八、多人协作工作模式

首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令建立本地分支和远程分支的关联：git branch --set-upstream-to <branch-name> origin/<branch-name>。

九、将远程库拉取到本地库

上面是先有本地库，后有远程库的时候，即本地代码推送到远程库。

实际开发中，公司已经有远程库，因此第一时间需要你从远程库下载项目，进行项目熟悉。

克隆远程库

新建本地文件夹，初始化git

git clone 仓库地址

仓库地址在远程库中查看

$ git clone https://gitee.com/mjpclab/jquery-tab.git
Cloning into 'jquery-tab'...
remote: Enumerating objects: 3133, done.
remote: Total 3133 (delta 0), reused 0 (delta 0), pack-reused 3133
Receiving objects: 100% (3133/3133), 863.92 KiB | 341.00 KiB/s, done.
Resolving deltas: 100% (2098/2098), done.

当从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

查看远程库信息

git remote

或者

git remote -v

修改远程库，拉取远程库代码

git pull origin master

出现以下即成功拉取，已获取到最新代码，可查看本地文件夹

$ git pull origin master
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 1024 bytes | 73.00 KiB/s, done.
From gitee.com:zhangmei3322/test
 * branch            master     -> FETCH_HEAD
   74cb51e..7874407  master     -> origin/master
Updating 74cb51e..7874407
Fast-forward
 README.md | 34 ----------------------------------
 1 file changed, 34 deletions(-)

十、开源项目

1、 什么是开源

开源（open source），在互联网领域，可以简单理解为是“开放源代码”的简称。通常来说，指的是将软件项目的源代码向大众开放，允许大众获取、使用、修改和发行。

2、开源项目的基本组成

源代码
文档：使用文档、二次开发文档
开发环境：如何搭建、运行你的项目或者引用你的工具
允许他人贡献代码
问题（issues）：用户提问，维护者回答
问题列表和升级计划：TODO | INPROGRESS | DONE

3、Fork开源项目

watch 关注

star 收藏

Fork代表从别人的代码仓库中复制一份到自己的代码库，包含了别人库中的提交历史记录。经过fork后的代码库是完全独立的，由自己维护，可以进行任何修改。改完之后自己可以通过Pull Request向原来的库提交合并请求。

流程可以总结如下：

Fork别人的仓库：复制别人仓库（代码、文件、提交历史记录、issue等），复制后的仓库在自己的gitee账号中存着。
Clone远程仓库：将这个复制后的远程仓库克隆到本地。
在工作区对代码进行CRUD操作（增删改查）
将代码的更改提交暂存区（git add .）
将暂存区的文件提交到本地仓库（git commit -m '这是我修改了的'）
将本地仓库的代码推送到远程仓库（git push）
给别人的仓库发送Pull Request：如果原作者认为你的修改版本不错，就会将你代码中的修改合并到自己的库中。

4、fork 和克隆（克隆、下载、git clone）区别

fork是 gitee 操作，该操作会复制其它远程仓库到你自己的账号下面，和本地仓库无关

clone ,该操作是给gitee 发送了一条“请给我发一份我复制的该仓库的内容”到我本地仓库，跟gitee账号无关

关联多个远程库

以GitHub和Gitee 为例

使用GitHub和使用Gitee类似，我们在GitHub上注册账号并登录后，需要先上传自己的SSH公钥。登陆GitHub，打开“Account settings”，“SSH Keys”页面：点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，点“Add Key”，就应该看到已经添加的Key

GitHub/Gitee允许你添加多个Key。假定你有若干电脑，一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub/Gitee，就可以在每台电脑上往GitHub/Gitee推送了。

多个远程库关联

git给远程库起的默认名称是origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库。

删除已关联的远程库
```
git remote rm origin
```

先关联GitHub的远程库

git remote add github git@github.com:girl99/test.git  // girl99/test.git 用户名/仓库名

注意：远程库的名称叫github，不叫origin了。

再关联Gitee的远程库

git remote add gitee git@gitee.com:zhangmei3322/test.git  // zhangmei3322/test.git 用户名/仓库名

注意：远程库的名称叫gitee了

查看远程库信息

git remote -v

出现下面即关联成功

git remote -v
gitee	git@gitee.com:zhangmei3322/test.git (fetch)
gitee	git@gitee.com:zhangmei3322/test.git (push)
github	git@github.com:girl99/test.git (fetch)
github	git@github.com:girl99/test.git (push)

如果要把本地仓库推送到GitHub
```
git push github master
```
如果要把本地仓库推送到Gitee
```
git push gitee master
```

执行完以上，我们的本地库就可以同时与GitHub、Gitee远程库互相同步：

┌─────────┐ ┌─────────┐
│ GitHub  │ │  Gitee  │
└─────────┘ └─────────┘
     ▲           ▲
     └─────┬─────┘
           │
    ┌─────────────┐
    │ Local Repo  │
    └─────────────┘

Git服务器

GitHub、Gitee这些是免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。

如何创建Git 服务器这里不作说明。

在实际开发中，公司基本都是自己的Git服务器，避免源代码的泄漏，保护其隐私性。尤其是银行，事业单位等保密性强的公司。

所以当你使用任何一台电脑去看公司项目，都需要经过公司项目管理人员的授权才可可查看及下载。

Git GUI

Git GUI（图形化管理工具 / 可视化工具）

图形化管理工具中的“图形化”指的是操作界面，以图形显示和操作的管理工具就是图形化管理工具，图形化更直观也更简便上手，降低了操作难度。

Git 虽然作为一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，但在实际项目开发过程中，开发人员通常只会使用几个常见的命令进行协同工作，且有些命令由于不常使用，较难记忆。所以Git GUI 为用户提供了一个可视化的图形界面，允许开发者通过简单的点击便捷地使用Git，从而不需要手动输入繁多的命令，使开发者能够更高效、更便捷地进行项目版本管理。

常见的三种主流的 Git GUI 图形化工具，帮助开发者能更为轻松、高效的利用 Git 进行项目版本管理。

GitHub Desktop
TortoiseGit
Vscode Git

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家小花儿/article/detail/710286

Git版本控制_it seems that there is already a rebase-merge dire

版本控制

概念

为什么需要版本控制？

常见的版本控制工具

Git