clone远程代码 在不同电脑上git_产出式学习Git(三)

写在前面

上篇我们学习了如何随意穿梭在不同版本的文件中,即版本切换。这里的版本切换是广义上的,也就是说操作对象既可以是本地的repo又可以是远程仓库。本次学习的内容主要是介绍远程仓库,以及新概念分支。开始新的学习之前,再把我们的全局图搬过来⬇️,本次内容会涉及到整个大的闭环。

[一]远程仓库

就像前面第一篇提到的,要是个人工作的话其实上面的本地小闭环已经可以满足需求了,但要对需要团队协作的大项目来说,Git就显示出它的优越性了。Git是分布式版本控制系统,即同一个Git仓库,可以分布到不同的机器上。

由以前提到的内容可以比较容易想到,我们找台Git服务器,24小时开机,其他人可以从服务器的仓库中克隆一份到本地,并且自己的提交从本地仓库推送到服务器仓库里,同时可以从服务器仓库中拉取别人的提交,这样理论上就可以实现分布式版本控制了。好在这样的服务器是已经存在的！就是著名的GitHub(知乎+GitHub简直科研利器),这个网站专门提供Git仓库托管服务,所以只要注册一个GitHub账号,就可以免费获得Git远程仓库啦。

因为Git仓库和GitHub的连接是通过SSH加密的,所以需要通过下面几步稍稍配置一下(为了简洁排版这里只列出几行命令,如果配置中有什么问题可以交流。)

1.创建SSH Key

p.s.可以先去自己的用户目录下.ssh/文件夹下是不是已经有id_rsa和id_rsa.pub两个文件了,如果有此步可以省略(记得以前配vscode+remote-ssh也要进行同样的操作)。

# 创建SSH Key 在用户根目录下输入⬇️(我猜这个邮箱要用GitHub关联的那个邮箱
$ ssh-keygen -t rsa -C "youremail@example.com"

然后一路回车(印象里是连敲三个回车),使用默认值即可。这时会在用户目录的.ssh/文件夹下看到id_rsa和id_rsa.pub两个文件在,其中id_rsa是私钥,id_rsa.pub是公钥,可以告诉任何人。这里注意同一个用户的不同repo和GitHub连接只要配一次就可以。

2.登陆GitHub,配置SSH

如果你有两台电脑,那么就要分别在两台主机生成两对密钥对,将两个公钥分别添加到SSH key中。这是因为GitHub需要识别出我们推送的提交确实是我们推送的,而非别人冒充,而Git支持SSH协议,所以GitHub只要知道了公钥,就可以确认只有我们才能推送。

3. 新建远程仓库(两种case)

# case1:命令行新建一个远程仓库
echo "# repo_name" >> README.md
# 这就是生成.git文件夹的命令
git init 
# 添加说明文件
git add README.md 
# commit提交
git commit -m "first commit"
git branch -M master
# 用来关联远程仓库
git remote add origin git@github.com:Cassieyy/repo_name.git 
# 第一次推送master分支的所有内容
git push -u origin master 
# 第一次以后,用以下命令推送最新修改到远程仓库
git push origin master

p.s.倒数第二行的origin就像是远程仓库的代号一样,默认它表示远程仓库。

# case2:将已有的本地repo推送到GitHub
# 建立联系
git remote add origin git@github.com:Cassieyy/repo_name.git
git branch -M master
# 第一次推送master的所有内容
git push -u origin master
# 第一次以后,用以下命令推送最新修改到远程仓库
git push origin master

好了,现在你有自己在GitHub上的远程仓库了,当然你也可以去clone其他人的开源项目。

知识补充1:GitHub上fork和clone的区别
fork:在github页面,点击fork按钮,将 别人的仓库复制一份到自己的 远程仓库.
clone:直接将GitHub中的仓库克隆到自己 本地电脑中.
知识补充2:pull request的作用
比如在仓库的主人(A)没有把我们添加为项目合作者(contributer)的前提下,我们将A的某个仓库名为A's_repo办法通过push将代码贡献到A's_repo中。
要想将你的代码贡献到A's_repo中,我们应该：
* 在A的仓库中fork项目A's_repo(此时我们自己的GiHub就有一个一模一样的仓库,但是URL不同）
* 将我们修改的代码push到自己GiHub中的仓A's_repo中
* 点击 pull request,主人就会收到请求,并决定要不要接受你的代码.

[二]分支管理

在多人协作开发过程中,大家各自开发自己的且大家工作量相当,谁都不想被另一方的代码“吞并”,这时候总得留个大管家来整合本项目所有的进展,这个“大管家”就是Git里主分支(master)的概念,而参与协作开发的个人,做法就是创建一个属于自己的分支,别人看不到,还继续在原来的分支上正常工作,直到开发完毕后,再一次性合并到大管家那里,既安全又不影响别人工作。

正式介绍之前,我们先明确两个概念：

HEAD指针指向当前所在分支,即可以通过知道HEAD指向谁来确定当前在哪个分支;

master指针指向最新的提交,指上传到远程仓库里最新的提交;

2.1创建与合并分支

HEAD和master之间的逻辑关系如下图所示:

比如我们新建一个分支Cassie,并切换到这个分支,上面的图就变成:

此后,我将在Cassie这条分支上在本地进行开发,上面的图进一步演化为:

如果我将Cassie分支上的改动提交到主分支,上面的图变为:

提交完成,master被更新之后,我们可以选择删掉Cassie分支,上面的图就演变成：

我们可以直观看到,p1和p5相比,多了新的提交,而这个提交是在分支上完成的哦~上面的几种演化,我们用代码行总结一下：

# 创建并切换到分支
$ git checkout -b Cassie

知识补充
# 上面一条命令相当于下面两条
$ git branch Cassie # 创建新分支Cassie
$ git checkout Cassie # 切换到Cassie分支

# 查看当前分支
$ git checkout

知识补充
上述命令会列出所有分支,当前分支前面会有一个*

# 用于合并指定分支的内容到当前分支
$ git merge Cassie

比如我当前分支是master或者我git checkout master,切到主分支,那么执行上述的代码行就把Cassie内容合并到主分支master上了。

# 过河拆桥之举——“删掉Cassie分支“
$ git branch -d Cassie

2.2解决冲突

有一种情况是,master和Cassie分支上都有了新的提交,产生冲突,这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来展示给用户,即Git的冲突解决只能通过手动解决冲突。

2.3分支管理

在实际开发中，我们应该按照几个基本原则进行分支管理：

1.master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;干活都在dev分支上,也就是说自己的分支是不稳定的。到某个时候,比如1.0版本发布时,再把分支合并到master上，在master分支发布1.0版本；

2.团队小伙伴们每个人都在dev分支上干活，每个人都有自己的分支,时不时地往dev分支上合并就可以了。

3.合并分支时,如果可能,Git会用Fast forward(快进式)模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

比如我们在Cassie上写完新的代码,现在想将其合并到master,合并前:

# 先切换回master
$ git checkout master
# 非--no-ff方式的git merge分支Cassie 
$ git merge -m "merge with no-ff" Cassie

解释：因为Cassie就在 master 的下游,所以直接移动了 master 的指针,master 和 Cassie指向相同,这样其实看不出有过合并。

# --no-ff方式的git merge分支Cassie   
$ git merge --no-ff -m "merge with no-ff" Cassie

即会保留分支信息。合并分支时加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并。

写在后面

产出式学习Git三篇先写到这里啦,因为有更重要且必须要做的事情,等以后想到什么再来补充完善吧～

参考文章：