git大全

一、版本控制

1.1 版本控制介绍

就是版本迭代，新的版本！版本管理器

版本控制(Reversion Control)是一种在开发的过程中用于管理我们对文件、目录或工程等内容的的历史修改，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

实现跨区域多人协同开发
追踪和记载一个或者多个文件的历史记录
组织和保护你的源代码和文档
统计工足量
并行开发、提高开发效率
跟踪记录整个软件的开发过程
减轻开发人员的负担，节省时间、同时降低人为错误

简单说就是用于管理多人协同开发项目的技术。

没有进行版本控制或者版本控制本身缺乏正确正确的流程管理，在软件开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事务性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。

无论是工作还是学习，或者是自己做笔记，都经历过这样一个阶段！我们就迫切需要一个版本控制工具！
多人开发就必须要使用版本控制，否则代价会比较大（多人的代码存在多个版本，有的版本没有这个，有的没有这个）

1.2 常见的版本控制工具

主流版本控制器有如下这些：

Git
SVN（Subversion）
CVS（Concurrent Versions System）
VSS（Microsoft Visual SourceSafe）
TFS （Team Foundation Server）
Visual Studio Online

1.3 版本控制分类

1.3.1 本地版本控制

记录文件每次的更新，放在本地，可以对每个版本做一个快照，或者是记录补丁文件，适合个人用，如RCS

1.3.2 集中版本控制

所有版本数据保存在中央服务器上，协同开发者从服务器上同步更新或上传自己的修改。每个人都拥有全量的代码，这样当然也有安全隐患。

所有的版本数据都存在服务器上，用户的本地只有自己以前所同步的版本（没有历史版本）。

如果不联网的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。
而且，所有数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份。代表产品：SVN、CVS、VSS。

1.3.3 分布式版本控制

所有版本信息仓库全部同步到本地的每个用户电脑上。

这样就可以在本地查看所有版本历史，
可以离线在本地提交，只需在联网时push到相应的服务器或其他用户那里。
由于每个用户那里保存的都是所有的版本数据。只要有一个用户的设备没有问题就可以恢复所有的数据。
但这里增加本地存储空间的占用。

1.3.4 git和SVN的区别

SVN	Git
SVN是`集中`式版本控制系统，版本库是集中放在中央服务器的。	Git是`分布式`版本控制系统，没有中央服务器，每个人的电脑就是一个完整的版本库。
工作的时候都用的是自己的电脑，所有首先要从中央服务器得到最新的版本，然后工作后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是`必须联网`才能工作，对网络带宽要求较高	工作的时候不需要联网了，因为版本都在自己的电脑上。协同的方法是这样的，比如自己在电脑上修改了文件A，其他人也在电脑上修改了文件A，这是，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

git是目前世界上最先进的分布式版本控制系统。

二、Git的历史

同生活中的许多伟大事物一样，Git诞生于一个极富纷争、大局创新的年代。

Linux内核开源项目有着为数众多的参与者，绝大多数的Linux内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991-2002年间）。到2002年，整个项目组开始应用一个专有的分布式版本控制系统Bitkeeper来管理和维护代码。

到了2005年，并发Bitkeeper的商业公司同Linux内核开源社区的合作关系结束，他们收回了Linux内核社区免费使用Bitkeeper的权利。这就迫使Linux开源社区（特别是Linux的缔造者Linus Torvalds）基于BitKeeper时经验教训，并发出自己的版本系统。也就是后来的Git！

Git是免费、开源的，最初Git是为辅助Linux内核开发的，来替代BitKeeper！

三、Git的配置

3.1 Git下载

到git官网下载

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

如果下载慢的话也可以去找镜像下载！

官网下载太慢，我们可以使用淘宝镜像下载：

https://registry.npmmirror.com/binary.html?path=git-for-windows/

Git Bash	Git CMD	Git GUI
Unix与`Linux风格的命令行`，使用最多，推荐最多	WIndows风格的命令行	`图形界面`的GIt，不建议初学者使用，尽量先熟悉常用命令
如命令：clear	cls

3.2 基本的Linux命令学习

命令	说明
cd	改变目录
cd ..	回退到上一个目录，直接cd进入默认目录
pwd	显示当前所在的目录路径
ls（ll）	都是列出当前目录中的所有文件，只不过ll列出内容更为详细
touch	新建一个文件如touch index.js就会在当前目录下先建一个index.js文件
rm	删除一个文件，rm index.js 就会把index.js文件删除
mkdir	新建一个目录，就是新建一个文件夹
rm -r	删除一个文件夹，rm -r src删除src目录
mv	移动文件，mv index.html src index.html 是我们要移动的文件，src是目标文件夹，当然这些文件夹必须在同一目录下。
reset	伺候你信初始化终端/清屏
clear	清屏
history	查看命令历史
help	帮助
exit	退出
#	表示注释

3.3 git基本命令

3.3.1 git config 配置用户信息

查看配置 git config -l

查看本地系统配置（排除用户配置） git config --system --list

查看用户配置（全局） git config --global --list

这个用户是必须要配置的！！向git服务器表明你是谁，要不对方都不知道是谁提交了！

当你安装Git后，首先要做的事情就是设置你的用户名称和email地址，这是非常重要的，因为每次git提交都会使用该信息。它会被永远的嵌入到了你的提交中：

pcuser@LAPTOP-EDRJVBHA MINGW64 /d/data/gitcode
$ git config --global user.name "happycarpediem"

pcuser@LAPTOP-EDRJVBHA MINGW64 /d/data/gitcode
$ git config --global user.email 103098723@qq.com

如图，添加后，执行git config --global 会有用户配置了

所有的配置文件，其实都保存在本地本地。

(一)查看system基本配置文件位置

如下图：system的配置在etc/gitconfig文件中

(二)查看用户配置文件位置

在用户目录下/.gitconfig文件

四、Git的基本理论

4.1 git的4个工作区域

工作区域共4个

git本地有3个工作区域：工作目录（Working Directory）、暂存区（Stage/Index）、资源库(Repository)，如果在加上远程git仓库（Remote Directory）就可以分为4个工作区域。文件在这个区域之间的转换关系如下：

工作区（workspace）：平时存放代码的地方
暂存区（Index/Stage）：临时存放你的改动，事实上它只是一个文件，保存你即将提交的文件信息
仓库区（或本地仓库）：就是安全存放数据的位置，这里面有你新提交的所有版本的数据。其中HEAD指向最新放入仓库的版本。
远程仓库（Remote）：托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换。

其实真正平时需要管理的就是工作区和远程仓库区，其他两个基本就是几条命令（不需要管理）;

本地的三个区域确切的说应该是git仓库中HEAD指向的版本：

4.2 git的工作流程

git的工作流程一般是如下：

在工作目录中添加、修改文件（也可以用eclipse、idea、notepad等）

将需要进行版本管理的文件放入暂存区;

将暂存区域的文件提交到本地git仓库;

将本地git仓库push到远程仓库

因此，git管理的文件对应有4种状态：已修改（modified）、已暂存（staged）、已提交（commited），在加上一个pushed到远程仓库。

五、Git项目搭建

创建工作目录与常用指令：

工作目录（Workspace），一般就是你希望git帮助你管理的文件夹，可以是你项目的目录，也可以是一个空目录，建议不要有中文。日常使用主要记住下图6个命令：

5.1 本地仓库搭建

创建本地仓库的方法有两种：

一种是创建全新的仓库。
另一种是克隆远程仓库。

5.1.1 创建全新的仓库

创建全新的仓库，到需要用git管理的项目的根目录执行：

pcuser@LAPTOP-EDRJVBHA MINGW64 /d/data/gitcode
$  git init

初始化后，目录下会对应生成一个隐藏文件夹.git

5.1.2 克隆远程仓库

另一种方式就是克隆远程目录，由于是将远程服务器上的仓库完全镜像一份至本地！执行后其实克隆了一个项目和它的整个代码历史（版本信息）！
```
git clone [url] 
git clone https://gitee.com/happycarpediem/blog-image.git
```
去gitee或者github克隆一个测试！

六、Git的文件操作

6.1 git文件的4种状态

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

Untracked：未跟踪，此文件在git初始化过的文件夹中，但没有加入到git库，多为新添加文件，此时为untracked，不参与版本控制。通过git add状态变为staged。

上图新创建文件为untracked文件

注意：上图changes to be commited即为staged状态
Unmodified：文件已经入库，未修改，即版本库中的文件快照内容与文件夹中完全一致，这种类型的文件有两种去处，如果它被修改，而变为Modified。如果使用git rm移除版本库，则成为Untracked文件。

Modified：文件已修改，仅仅是修改，并没有进行其他的操作，这个文件也有两个去处。通过git add可进入暂存staged状态，使用git checkout则丢弃修改过，返回unmodify状态，这个git checkout即从库中取出文件，覆盖当前修改。
Staged：暂存状态，执行git commit即将修改同步到库中，这是库中的文件和本地文件又变为一致，文件为unmodify状态，执行git reset HEAD filename取消暂存，文件状态为modified

如上图，提交后，库中的文件和本地文件又变为一致，文件为unmodify

6.2 git文件操作命令总结

$ git add .
$ git commit -m "firt commit"
#git push 以后有远程仓库执行

git add . 将所有文件提交到暂存区

git commit 将文件提交到本地仓库。

git push 以后有远程仓库执行

6.3 git提交文件忽略排除

有些时候我们不想把某些文件纳入版本控制中，比如数据库文件、临时文件、设计文件等在主目录下建立".gitignore"文件，此文件有如下规则：

忽略文件中的空行或以#号开始的行将会被忽略
可以使用linux通配符。例如星号（*）代表任意多个字符，问号（？）代表一个字符，方括号（[abc]）代表可选字符范围，大括号（{string1，string2...}）代表可选的字符串等。
如果名称的最前面有一个感叹号（！），表示例外规则，将不被忽略
如果名称的最前面是一个路径分隔符（/），表示要忽略的文件夹在此目录上，而子目录中的文件不忽略
如果名称的最后面是一个路径分隔符（/），表示要忽略的此目录下该名称的子目录，而非文件（默认文件或目录被忽略）

.gitignore文件，如下示例：

七、使用码云

github是有墙的，比较慢。
在国内一般使用gitee。
在公司一般搭建自己的gitlab服务器。

7.1 注册并装修维护门面

7.2 设置SSH公钥

设置本机绑定SSH公钥，实现免密码登陆！（这一部分很重要，码云是远程仓库，平时我们工作是本地仓库）

执行一下语句，生成一对密钥

 ssh-keygen -t rsa

把其中的公钥注册到码云上面就OK了

7.3 使用码云创建一个自己的仓库

7.4 克隆到本地

八、Idea 集成Git

8.1 新建项目，绑定git

将我们远程项目的.git目录拷贝到我们Idea的项目中即可

拷贝后，idea多出了git图标

已经变红，证明git文件已经绑定成功。

8.2 修改文件，使用idea提交

add . 添加到暂存区

commit 到本地仓库

push 到远程仓库

如上图，点击左下脚按钮

查看git日志

最后提交到远程仓库，可以通过命令行：

git push

8.3 提交测试

九、Git分支

9.1 git分支概念

分支在git中相对较难，分支就是科幻电影里面的平行宇宙，如果两个平行宇宙互不打扰，那对现在的你也没有啥影响，不过，在某个时间点，两个平行宇宙合并了，我们就需要处理一些问题了!

就好比两个平行世界A和B

如果只有一个世界有你或者都没有你，那两个平行世界合并的时候不会产生冲突。

如果两个世界都有你，但两个世界你的状态一致，对于你这个人的合并，也不会产生冲突。

但如果两个世界都有你，在A世界你是总统，B世界你是码农，在合并的时候就会产生冲突，问你是想当总统还是码农了！

1.理想是：岁月静好，互不打扰

2.现实是：天天打扰

注意：这里强调一点，主分支一般只对外发布重要稳定版本用，而不直接作为工作分支在上面开发，一般新建一个工作分支。

9.2 git分支的作用

同事并行推进多个功能开发，提高开发效率

各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响，彼此是独立的，甚至某个分支完全失败删除了也没关系

9.3 git分支使用场景模拟

主要要模拟两个不同团队（人）A、B分别负责分支master和hot_fix

A团队：使用idea模拟A团队，负责合并其他分支，使用master分支

B团队：使用git_bash模拟B团队，负责hot_fix ，使用hot_fix分支

9.3.1 从master分支checkout一只新分支

并push到远程仓库， git push -u origin hot_fix，注意-u参数，保持track

PS D:\data\java project\happymock> git branch -v
  develop b72c689 Initial commit
* master  4d1a574 commit by gaoxing
PS D:\data\java project\happymock> git checkout -b hot_fix
Switched to a new branch 'hot_fix'
PS D:\data\java project\happymock> git branch
  develop
* hot_fix
  master
PS D:\data\java project\happymock> git push -u origin hot_fix
Enumerating objects: 196, done.
Counting objects: 100% (196/196), done.
Delta compression using up to 8 threads
Compressing objects: 100% (179/179), done.
Writing objects: 100% (196/196), 55.10 KiB | 1.57 MiB/s, done.
Total 196 (delta 93), reused 4 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (93/93), done.
remote: Powered by GITEE.COM [GNK-6.3]
remote: Create a pull request for 'hot_fix' on Gitee by visiting:
remote:     https://gitee.com/happycarpediem/happyMock/pull/new/happycarpediem:hot_fixx                                 remote:     https://gitee.com/happycarpediem/happyremote:     remote:     https://gitee.com/happycarpediem/happyMock/pull/new/happycarpediem:hot_fi
x...happycarpediem:master
To https://gitee.com/happycarpediem/happyMock.git
 * [new branch]      hot_fix -> hot_fix
branch 'hot_fix' set up to track 'origin/hot_fix'.
PS D:\data\java project\happymock> git branch -v
  develop b72c689 Initial commit
* hot_fix 4d1a574 commit by gaoxing
  master  4d1a574 commit by gaoxing

注意上面提交节点号hot_fix和master一样，即目前还是为一个提交。

9.3.2 团队在新建分支上开发任务

现在B团队发现了一个bug，我们模拟开始执行任务，新增文件fix.txt，并修改如下。

9.3.3 分支团队对开发任务完成后，提交本地仓库和远程仓库

可以通过git add .和git commit，但这里分支团队通过idea图形界面提交，如下

注意上图，提交后，发现提交节点号不一样了，且注释也不一样了。但后面有一个ahead1，表示本地仓库节点号比远程仓库前。

提示需要提交到远程仓库。（也可以用idea一步提交到仓库）

9.3.4 需要把hot_fix分支merge into 到master分支

首先切换到主分支，再merge

git checkout [被动接收合并分支]

注意这里必须是接收修改的分支(被合并，被动接收修改的分支)，即必须站在master分支上执行git merge hot_fix

git merge [主动修改分支]

git branch -v

merge后，再执行git branch -v，发现主分支和hot_fix已经一致，即已经合并。

9.3.5 合并分支遇到冲突解决冲突

如果没有冲突，自然合并没有问题，但更多的时候，team A和B独立开发，时常有修改同一个文件的需要，如下面场景，hot_fix

修改了bug，而business团队也自己解决了bug，在将business合并到master的时候，git会提示冲突，需要解决后才能合并。

现在来模拟在master连续提交两次节点，修改fix.txt。

第一次提交修改。

第二次提交修改。

可以看到两次提交都有记录

另外一个fix team，先pull最新的远程仓库，再在本地修改，后续再提交，是不会有任何问题的。以下git _bash是模拟fix team执行任务

另外一个hot_fix team，可以看到master分支上的所有的历史提交

使用git log

现在开始真正制造冲突，hot_fix team，用git_bash 修改fix文件，进行第三次修改

git push到远程仓库，使得远程仓库的hot_fix更新

现在进入merge 工作，需要切换到被merge的master分支上

在master分支上，执行git merge操作，果然报错。因为master分支和hot_fix在同一个文件上内容不一样，需要解决冲突才能合并。

这时，vi 冲突的文件fix.txt。发现git已经修改了该文件，并做了对比。HEAD代表当前分支，即master。下面hot_fix代表hot_fix分支的修改。我们可以选择其中的一些修改进行保留。

保留如下：

修改保存后，再次git merge hot_fix 提交merge

直接merge是不行的，要将修改的fix.txt文件再add和提交后，再merge就可以了

注意上面master分支生成了新的提交节点号，既没有用hot_fix也不会用原来master分支的

最后再 push到远程仓库

git push

9.4 git分支常用命令

#列出所有本地分支

git branch

#列出所有远程分支

git branch -r

#列出所有分支

git branch -a

#创建一个新的分支，但依然停留在当前分支

git branch [branch-name]

#创建一个新的分支，并切换到新分支

git checkout -b [branch-name]

#切换分支

git checkout [branch-name]

#合并指定分支到`当前分支`

git merge [branch-name]

#删除分支

git branch -d [branch-name]

#删除远程分支

git push origin --delete  [branch-name]

git branch -dr [remote/branch]

9.4 git分支的合并产生冲突

多个分支如果并行执行，就会导致我们代码不冲突，也就是同时存在多个版本！场景如下：

A组：web-api -A组主要负责Happy.java的编写

B组：web-admin -B组调用了A代码（Happy.java），并修改了A的代码

C组：web-app -C组调用了A和B的代码。

如果几个分支都修改了同一个文件，将来几个分支又要合并，就需要merge，而merge的时候，git系统以为检测到Happy.java程序两个分支都有修改，就会提示有冲突，需要解决。

如果同一个文件在合并分支时都被修改了则会引起冲突。解决办法是：我们可以修改冲突文件后重新提交！既需要协商即可，选择要保留他的代码还是你的代码！（想当总统还是码农！）

Master主分支应该非常稳定，只用来对外发布新版本，一般情况下不允许在上面工作。

工作一般情况在新建的dev分支上工作，工作完后，比如要发布，或者说dev分支代码稳定后可以合并到主分支master上来。

9.5 Idea上操作git分支

选择branch后弹出以下界面：

PS D:\data\java project\happymock> git branch

* master
  PS D:\data\java project\happymock> git branch -r
  origin/HEAD -> origin/master
  origin/develop
  origin/master
  PS D:\data\java project\happymock> git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master
  PS D:\data\java project\happymock> git branch -r
  origin/HEAD -> origin/master
  origin/develop
  origin/master
  PS D:\data\java project\happymock> git branch v1.0
  PS D:\data\java project\happymock> git branch
* master
  v1.0
  PS D:\data\java project\happymock> git checkout -b v1.0
  fatal: a branch named 'v1.0' already exists
  PS D:\data\java project\happymock> git branch
  master
* v1.0
  PS D:\data\java project\happymock> git branch -d v1.0
  Deleted branch v1.0 (was 4d1a574).
  PS D:\data\java project\happymock> git push origin -d v1.0
  remote: Powered by GITEE.COM [GNK-6.3]
  To https://gitee.com/happycarpediem/happyMock.git

 - [deleted]         v1.0
   PS D:\data\java project\happymock>

十、Git重要命令总结

1 git push

在使用git commit命令将修改从暂存区提交到本地版本库后，只剩下最后一步使用git push将本地版本库的分支推送到远程服务器上对应的分支了。git push的一般形式为：

git push <远程主机名> <本地分支名> <远程分支名>

例如： git push origin master：refs/for/master ，即是将本地的master分支推送到远程主机origin上的对应master分支， origin 是远程主机名，

第一个master是本地分支名，第二个master是远程分支名。

1.1 git push origin [本地分支名] 推送分支到远程主机origin

git push origin master
git push origin a
#这里master可以为任意本地分支名

如果远程分支被省略，如上，则表示将本地分支推送到与之存在追踪关系的远程分支（通常两者同名），如果该远程分支不存在（而本地存在这个分支），则会被新建。

1.2 git push origin :[远程分支名] 删除远程主机origin的分支

git push origin :a
git push origin --delete master
#这里a为分支名

如果省略本地分支名（分号：前为空），则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支，等同于 git push origin --delete master，（删除本地分支git branch -d a）

1.3 git push origin 将当前分支推送到origin主机的对应分支

git push origin

　　如果当前分支与远程分支存在追踪关系，则本地分支和远程分支都可以省略，将当前分支推送到origin主机的对应分支。（不存在追踪关系，见上至少需要显示指定一个分支）

但有时候会报错，提示本地分支和远程分支没有建立对应关系（常常是因为本地分支是通过git branch [分支名]或git checkout -b 手动创建，而不是直接从git上直接clone或checkout下来），如下图：

处理方法见1.5和1.6，使用git push -u origin master方法

1.4 git push

　　如果当前分支只有一个远程分支，那么主机名都可以省略，形如 git push，可以使用git branch -r ，查看远程的分支名

1.5 git push -u origin [本地分支名] 推送分支到远程主机origin并关联

建立本地和远程分支关联，方法一：

只需要在输入 git push -u origin dev(远程分支名)，因为本身我就在本地的dev分支上面，所以可以直接 push，不在dev 分支的话需要 git checkout dev切换到dev分支，注意这里执行命令：强制本地分支与远程分支命名一致。

1.6 git push --set-upstream origin [本地分支名]

建立本地和远程分支关联，方法二：

按照git的提示，执行以下命令：

 git push --set-upstream origin dev

将远程 dev 分支和本地 dev 分支相关联。之后再执行 git push 即可。一般新建的分支在push的时候都需要执行这个命令和远端相关联。

1.7 git push 的其他命令

　　这几个常见的用法已足以满足我们日常开发的使用了，还有几个扩展的用法，如下：

　　　　（1） git push --all origin 当遇到这种情况就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要 -all 选项

　　　　（2） git push --force origin git push的时候需要本地先git pull更新到跟服务器版本一致，如果本地版本库比远程服务器上的低，那么一般会提示你git pull更新，如果一定要提交，那么可以使用这个命令。

　　　　（3） git push origin --tags //git push 的时候不会推送分支，如果一定要推送标签的话那么可以使用这个命令

1.8 关于 refs/for

　　/refs/for 的意义在于我们提交代码到服务器之后是需要经过code review 之后才能进行merge的，而refs/heads 不需要

2. git remote

2.1 git remote -v 获取远程仓库版本

第一步,查看当前git的远程仓库版本，一般clone下来的都有远程信息

$ git remote -v

此时若什么都没有显示说明，git无远程仓库。

正常如下：

可以跳过第2步。

2.2 git remote add origin [远程url]

第二步，添加ssh协议的远程仓库：

$ git remote add origin git@github.com:unlimitbladeworks/Data-Struts-Learning.git

再次查看

$ git remote -v
origin  git@github.com:unlimitbladeworks/Data-Struts-Learning.git (fetch)
origin  git@github.com:unlimitbladeworks/Data-Struts-Learning.git (push)

当前，我本机就是用的这种方式连接的github，好处是每次提交代码时，不需要重复来回输入用户名和密码。

第三步：使用公司网合并前一天晚上更新到github上的代码时，报出如下错误：

$ git pull origin master
ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.

得知第一种协议被禁掉后，只能换一种连接进行合并本地仓库了。继续往下看另一种协议。

切换成 HTTPS协议连接GITHUB

依然是先查看当前远程仓库使用的那种协议连接：

$ git remote -v
origin  git@github.com:unlimitbladeworks/Data-Struts-Learning.git (fetch)
origin  git@github.com:unlimitbladeworks/Data-Struts-Learning.git (push)
1234

2.3 git remote rm origin 移除掉远程仓库的配置

$ git remote rm origin

删除后，重新添加新的远程仓库，以https的形式：

git remote add origin https://github.com/unlimitbladeworks/Data-Struts-Learning.git

再次查看:

$ git remote -v
origin  https://github.com/unlimitbladeworks/Data-Struts-Learning.git (fetch)
origin  https://github.com/unlimitbladeworks/Data-Struts-Learning.git (push)

https的地址其实就是github上项目对应的地址，如下图：这里写图片描述

完事以上切换操作，其实问题就已经解决了。

最终结果

再次尝试pull代码，可以看到已经成功。

$ git pull origin master
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (8/8), done.
Unpacking objects: 100% (21/21), done.
remote: Total 21 (delta 5), reused 21 (delta 5), pack-reused 0
From https://github.com/unlimitbladeworks/Data-Struts-Learning
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master

2.4 git remote show origin 查看所有远程分支

查看所有的分支，并且使用

git remote show origin

2.5 git remote prune origin 干掉本地保留的其实远程仓库已经删除的远程分支

会通过显示命令发现一些分支以及取消了云端了的，但本地任然拥有，可以prune掉他，于是执行

git remote prune origin

3. git merge

Git的git merge是在Git中频繁使用的一个命令，很多人都觉得git合并是一个非常麻烦的事情，一不小心就会遇到丢失代码的问题，从而对git望而却步，而git merge使用不当确实会有交叉合并带来代码遗失问题

git merge命令是用于将两个或两个以上的开发历史合并在一起的操作

4. git rebase

5. git fetch

5.1 git fetch --all 更新远程仓库代码到本地仓库

6. git pull

在本地仓库文件夹中右键，开的Git Bash，输入下面代码：

git fetch --all
git reset --hard origin/master
git pull
git fetch --all && git reset --hard origin/master && git pull

7. git log 查看历史提交

使用git log

8. git reset 回退本地版本

git pull的时候出现如下的错误：

错误：无法提取，因为您有未合并的文件。

解决方案一（不推荐）：本地的push和merge会形成MERGE-HEAD(FETCH-HEAD), HEAD（PUSH-HEAD）这样的引用。HEAD代表本地最近成功push后形成的引用。MERGE-HEAD表示成功pull后形成的引用。可以通过MERGE-HEAD或者HEAD来实现类型与svn revet的效果。将本地的冲突文件冲掉，不仅需要reset到MERGE-HEAD或者HEAD,还需要–hard。没有后面的hard，不会冲掉本地工作区。只会冲掉stage区

git reset --hard FETCH_HEAD
#或者回退到上一个版本
git reset --hard "HEAD^"

git pull 上面的解决方法非常非常的霸道，是可以解决这个错误，但是它会回到初始的节点，假如我有修改本地代码但是没有提交，那么使用reset初始，可能会丢失这些修改的代码，慎用！

十一、Git使用的场景

1. 复制旧branch到新的branch

方法一：使用checkout

git checkout [old_branch]
#再git checkout -b [new_branch]，这样切换目录变相在本地实现复制了branch
git checkout -b [new_branch]
#此时，远程还没有new_branch，需要同步关联本地和远程branch
git push -u origin [new_branch]
#或者使用git推荐的 git push --set-upstream origin develop 也可以关联

方法二：使用merge

#到新的branch下
git checkout -b [new_branch]
#使用merge
git merge [old_branch] [new_branch]

posted @ 2022-04-04 00:12 高兴518 阅读(130) 评论(0) 编辑收藏举报

刷新页面返回顶部

happycarpediem

git大全

git大全

一、版本控制

1.1 版本控制介绍

1.2 常见的版本控制工具

1.3 版本控制分类

1.3.1 本地版本控制

1.3.2 集中版本控制

1.3.3 分布式版本控制

1.3.4 git和SVN的区别

二、Git的历史

三、Git的配置

3.1 Git下载

3.2 基本的Linux命令学习

3.3 git基本命令

3.3.1 git config 配置用户信息

(一)查看system基本配置文件位置

(二)查看用户配置文件位置

四、Git的基本理论

4.1 git的4个工作区域

4.2 git的工作流程

五、Git项目搭建

5.1 本地仓库搭建

5.1.1 创建全新的仓库

5.1.2 克隆远程仓库

六、Git的文件操作

6.1 git文件的4种状态

6.2 git文件操作命令总结

6.3 git提交文件忽略排除

七、使用码云

7.1 注册并装修维护门面

7.2 设置SSH公钥

7.3 使用码云创建一个自己的仓库

7.4 克隆到本地

八、Idea 集成Git

8.1 新建项目，绑定git

8.2 修改文件，使用idea提交

8.3 提交测试

九、Git分支

9.1 git分支概念

9.2 git分支的作用

9.3 git分支使用场景模拟

9.3.1 从master分支checkout一只新分支

9.3.2 团队在新建分支上开发任务

9.3.3 分支团队对开发任务完成后，提交本地仓库和远程仓库

9.3.4 需要把hot_fix分支merge into 到master分支

git checkout [被动接收合并分支]

git merge [主动修改分支]

git branch -v

9.3.5 合并分支遇到冲突解决冲突

9.4 git分支常用命令

9.4 git分支的合并产生冲突

9.5 Idea上操作git分支

十、Git重要命令总结

1 git push

1.1 git push origin [本地分支名] 推送分支到远程主机origin

1.2 git push origin :[远程分支名] 删除远程主机origin的分支

1.3 git push origin 将当前分支推送到origin主机的对应分支

1.4 git push

1.5 git push -u origin [本地分支名] 推送分支到远程主机origin并关联

1.6 git push --set-upstream origin [本地分支名]

1.7 git push 的其他命令

1.8 关于 refs/for

2. git remote

2.1 git remote -v 获取远程仓库版本

2.2 git remote add origin [远程url]

2.3 git remote rm origin 移除掉远程仓库的配置

2.4 git remote show origin 查看所有远程分支

2.5 git remote prune origin 干掉本地保留的其实远程仓库已经删除的远程分支

3. git merge

4. git rebase

5. git fetch

5.1 git fetch --all 更新远程仓库代码到本地仓库

6. git pull

7. git log 查看历史提交

8. git reset 回退本地版本

十一、Git使用的场景

1. 复制旧branch到新的branch

公告