之前我们使用的都是本地git仓库来进行管理文件的。但git其实是一个分布式版本控制器,我们之前只使用了git的版本控制功能,却没有体现出分布式!
同一个git仓库,可以克隆到不同的机器上,并且每一个机器上都是一个完整的git仓库,如果两个开发人员对代码进行了修改,想要其他人看见,只需要将自己的修改提交,并推送到远程,让另一方重新拉取最新的代码即可。
一.新建远程仓库
gitee就是一个代码托管平台,我们可以将其作为我们的远程仓库。
我们可以看到,我们在创建远程仓库时并没有选择分支模型,这里默认就是master单分支模型
二.克隆远程仓库到本地
克隆时,我们可以选择https协议克隆,也可以选择ssh协议克隆。
https克隆适用于临时克隆仓库使用,https每一次推送的时候需要输入密码,但克隆仓库简单。
ssh克隆仓库需要配置公钥,适用于长期开发。并且ssh配置之后,每一次push无需输入密码。
下面以ssh克隆远程仓库为例:
ssh克隆远程仓库必须要配置公钥,如果没有公钥直接克隆服务器会拒绝我们的访问请求。
1.在家目录下,看.ssh的隐藏目录中有没有id_rsa和id_rsa.pub这两个文件,如果没有则需要创建ssh key(如果有,则直接跳到下一步)
因为我这里已经有了公钥,所以会提示我是否要覆盖,没有公钥的,直接一路回车即可。
然后.ssh就会有那个文件,我们打印.pub文件,这就是公钥,我们将其全部复制。
然后在gitee设置中,添加公钥即可
2.克隆远程仓库到本地
克隆完成后,就会在当前目录下,生成一个与远程仓库同名的目录
进入该目录内部,就会有我们初始化时选择的readme文件,以及.git和.gitee隐藏目录 .git就是git仓库,而.gitee则是我们选择模板时的issue和pull requset模板
当我们clone之后,git会默认将本地的master分支和远程的master关联起来,远程仓库默认叫做origin
git remote -v看到有fetch和push权限
3.克隆之后,我们要使用git config 来配置我们的git仓库
其实在clone命令的下面,gitee就给了我们提示,我们直接运行这个命令即可
三.向远程推送内容
我们创建一个file.txt文件,并进行提交,此时查看仓库状态,提示我们领先于远程的master,要进行push
这一步就是将我们本地的修改推送到远程,让远程与我们进行同步,git push的选项如下:
git push <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果本地分⽀名与远程分⽀名相同,则可以省略冒号:
git push <远程主机名> <本地分⽀名>
此时我们在gitee上查看我们的仓库,就会多了一个file.txt文件
四.拉取远程仓库内容
我们在远程仓库上直接对file.txt进行修改,让远程仓库的版本领先于本地(这种行为严重错误,不要在远程仓库上直接修改,这里是便于测试)此时本地仓库比远程仓库落后,为了与远程一致,我们要拉取远程仓库的内容到本地,拉去操作如下:
git pull <远程主机名> <远程分⽀名>:<本地分⽀名>
# 如果远程分⽀是与当前分⽀合并,则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>
五.配置Git
配置忽略文件——.gitignore
在创建仓库时,初始化仓库有一个.gitignore忽略模板,这个隐藏文件的功能其实就是为了屏蔽一些文件的干扰,比如我们写了很多.c/.cpp的源文件,我们同时也写了很多的txt文件,但是我们上传的时候只想push源文件,而不想push txt文件。
如果没有.gitignore,我们就得一个一个的push,很麻烦。而有了该文件,我们可以给里面写上我们不想要push的文件,此时我们就可以大胆放心的push,不会将.gitignore中的满足要求的文件push到远程。
如下测试所示:我们设置*.so和*.a表示以.so和.a结尾的文件都不会push,但是我们又设置了!b.so,表示该文件要push。
还有一个细节,那就是我们这里直接使用了git push而没有使用 git push origin master,这是因为我们远端的master分支已经和我们本地的master建立了联系,此后就可以直接使用git push来推送,拉取也是一样。
给命令起别名
git config --global alias.xx 原命令
比如,我们当是使用git查看带分支的日志时,命令非常长
git log --graph --pretty=oneline --abbrev-commit
我们就可以使用alias来为该命令创建一个别名:
六.标签管理
1.理解标签
标签 tag ,可以简单的理解为是对某次commit 的⼀个标识,相当于起了⼀个别名。例如,在项⽬ 发布某个版本的时候,针对最后⼀次commit 起⼀个v1.0 这样的标签来标识⾥程碑的意义。
这有什么⽤呢?相较于难以记住的 commit id , tag 很好的解决这个问题,因为 tag ⼀定要给⼀ 个让⼈容易记住,且有意义的名字。当我们需要回退到某个重要版本时,直接使⽤标签就能很快定位 到。
2.标签操作
使用git tag xx创建标签,默认会给当前分支的最新一次commit打上标签。
使用git show可以查看标签
如果想要给指定的commit id打上标签,则需要指定commit id 使用git show [tag]可以查看该标签的内容
使用git tag -d删除标签
如果要将某个标签推送到远程,则需要git push origin <tagname>
如果你有多个标签,想要一次性推送,可以使用
git push origin --tags
如果要想删除已经同步到远程的标签,需要先删除本地的,然后同步要远程:
七.多人协作
在日常开发过程中,往往都是很多人同时进行开发。并且为了保证远程master分支的稳定性,我们一般不直接对master分支进行push操作,而是在远程创建新分支,每一个分支对应一个新功能,开发人员在本地对新建分支进行操作。开发完毕也将修改提交到新分支上,然后提交pull request表单,来申请将功能合并到主分支,这样就可以避免直接合并代码而导致出bug的问题。
1.在Windows下克隆该仓库
2.创建远程分支
2.使用git pull将dev分支拉去到本地
拉取之后,我们新建一个本地的dev分支,并于远程dev分支产生关联,这样我们push/pull的时候,就不用带origin参数了
windows也一样
3.开发
我们在Linux上,和Windows上,同时对file.txt这个文件进行修改。
此时查看码云上的dev分支,它比master分支领先 此时我们继续让Windows下对file.txt进行开发
但是我们对dev分支进行推送的时候,就会发送请求被拒绝了。这是因为发送了冲突。对于Windows来说,远程的dev分支,比本地的dev分支领先,此时推送的时候,git不知道怎么合并,所以我们此时需要手动解决
先从远程拉取最新内容 然后选择如何进行合并,并且重新进行提交
此时再看码云,就可以看到最新的两个人的开发内容了: 但此时内容仍在dev分支上,master分支依旧看不到:
4.将dev分支合并到master分支
在本地,我们合并时为了避免冲突,先让dev合并master,然后master合并dev。然后再远程仓库,我们合并dev,需要申请pull request。
当审查和测试通过后,我们就可以进行合并了 因为合并后dev分支就没有用了,此时我们直接删除dev分支即可。
合并之后,我们在master分支就可以看到dev分支上开发的内容了,并且dev分支也被删除了
5.删除本地的dev分支
远程分支dev已经删除了,但是我们依旧可以查到,可以使用git remote prune orgin删除那些远程不存在的分支
然而再真正的开发过程中,往往都是一个功能对应一个分支,不会同时在一个分支上实现多个功能。 但只要我们遵守以上的原则,就不会出现什么大问题了。