4、Git远程仓库
前面我们已经知道了Git中存在两种类型的仓库,即本地仓库和远程仓库。那么我们如何搭建Git远程仓库
呢?我们可以借助互联网上提供的一些代码托管服务来实现,其中比较常用的有GitHub、码云、GitLab等。
gitHub( 地址:https://github.com/ )是一个面向开源及私有软件项目的托管平台,因为只支持 Git 作为唯一的版本库格式进行托管,故名gitHub
码云(地址: https://gitee.com/ )是国内的一个代码托管平台,由于服务器在国内,所以相比于 GitHub,码云速度会更快
GitLab (地址: https://about.gitlab.com/ )是一个用于仓库管理系统的开源项目,使用Git作 为代码管理工具,并在此基础上搭建起来的web服务,一般用于在企业、学校等内部网络搭建git私服。
4.2、 注册码云
要想使用码云的相关服务,需要注册账号(地址: https://gitee.com/signup)
4.3、创建远程仓库
4.4、配置SSH公钥
作用:用于验证操作者的身份信息(相当于用户登录)。
4.4.1生成SSH公钥
-
ssh-keygen -t rsa
-
不断回车
如果公钥已经存在,则自动覆盖
4.4.2 Gitee设置账户共公钥
获取公钥
cat ~/.ssh/id_rsa.pub
设置公钥
-
标题随便写
-
将生成的公钥粘到下面的公钥框中
4.4.3验证是否配置成功
ssh -T gie@gitee.com
4.5、操作远程仓库
4.5.1、添加远程仓库
此操作是先初始化本地库,然后与已创建的远程库进行对接。
命令: git remote add <远端名称> <仓库路径>
远端名称,默认是origin,取决于远端服务器设置仓库路径,从远端服务器获取此URL
例如: git remote add origin https://gitee.com/xu_yu_bing/work.git
4.5.2、查看远程仓库
命令:git remote
4.5.3、推送到远程仓库
命令:git push [-f] [--set-upstream] [远端名称
如果远程分支名和本地分支名称相同,则可以只写本地分支
git push origin master
n -f 表示强制覆盖
n --set-upstream 推送到远端的同时并且建立起和远端分支的关联关系。
git push --set-upstream origin master:dev
注意:在push 之前 一定要先pull(拉取),获取最新代码之后,解决冲突后(如果有冲突的话),才能push成功!!!
如果当前分支已经和远端分支关联,则可以省略分支名和远端名。
git push 将master分支推送到已关联的远端分支。
4.5.4查询远程仓库
4.5.5本地分支与远程分支的关联关系
查看关联关系我们可以使用 git branch -vv 命令
4.5.6、从远程仓库克隆
如果已经有一个远端仓库,我们可以直接clone到本地。
命令: git clone <仓库路径> [本地目录]
本地目录可以省略,会自动生成一个目录
4.5.7、从远程仓库中抓取和拉取
远程分支和本地的分支一样,我们可以进行merge操作,只是需要先把远端仓库里的更新都下载到本地,再进行操作。
抓取 命令:git fetch [remote name] [branch name]
Ø *抓取指令就是将仓库里的更新都抓取到本地,不会进行合并*
Ø 如果不指定远端名称和分支名,则抓取所有分支。
Ø 拉取 命令:git pull [remote name] [branch name]
Ø git pull --rebase origin master(用在合并代码的时候其作用就是在一个随机创建的分支上处理冲突,避免了直接污染原来的分区)
例如:git pull origin dev
Ø 拉取指令就是将远端仓库的修改拉到本地并自动进行合并,等同于fetch+merge
Ø 如果不指定远端名称和分支名,则抓取所有并更新当前分支。
4.5.8 练习:远程仓库操作
##########################1-将本地仓库推送到远程仓库 # 完成4.1、4.2、4.3、4.4的操作 略 # [git_test01]添加远程仓库 git remote add origin git@gitee.com/**/**.git # [git_test01]将master分支推送到远程仓库,并与远程仓库的master分支绑定关联关系 git push --set-upstream origin master ###########################2-将远程仓库克隆到本地 # 将远程仓库克隆到本地git_test02目录下 git clone git@gitee.com/**/**.git git_test02 # [git_test02]以精简的方式显示提交记录 git-log ###########################3-将本地修改推送到远程仓库 # [git_test01]创建文件file03.txt 略 # [git_test01]将修改加入暂存区并提交到仓库,提交记录内容为:add file03 git add . git commit -m 'add file03' # [git_test01]将master分支的修改推送到远程仓库 git push origin master ###########################4-将远程仓库的修改更新到本地 # [git_test02]将远程仓库修改再拉取到本地 git pull # 以精简的方式显示提交记录 git-log # 查看文件变化(目录下也出现了file03.txt) 略
4.6. 开发工具 结合git
略,参看本套视频操作
Git 提交常见问题
-
husky > commit-msg (node v14.16.0)
⧗ input: 你的消息xxxx...
✖ subject may not be empty [subject-empty]
✖ type may not be empty [type-empty]
✖ found 2 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
原因:你提交的消息不符合规范
解决办法:,需要在前面加feat: 。如果是bug,则前面加bug: 。注意,冒号(英文)后面有空格
-
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.
原因分析:
是由于本地和远程仓库两者代码文件不同步,因此需要先pull,进行合并然后再进行push
解决方法:
1、先使用pull命令:
git pull --rebase origin master
2、再使用push命令:
git push -u origin master
4.7 git tag 打标签
tag是git版本库的一个标记,指向某个commit的指针。
tag主要用于发布版本的管理,一个版本发布之后,我们可以为git打上 v.1.0.1 v.1.0.2 ...这样的标签。
tag感觉跟branch有点相似,但是本质上和分工上是不同的:
tag 对应某次commit, 是一个点,是不可移动的。 branch 对应一系列commit,是很多点连成的一根线,有一个HEAD 指针,是可以依靠 HEAD 指针移动的。 所以,两者的区别决定了使用方式,改动代码用 branch ,不改动只查看用 tag。 tag 和 branch 的相互配合使用,有时候起到非常方便的效果,例如:已经发布了 v1.0 v2.0 v3.0 三个版本,这个时候,我突然想不改现有代码的前提下,在 v2.0 的基础上加个新功能,作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ,然后作为开发分支。
4.7.1 新建tag
$ git tag v1.6
v1.6 就是这个tag的名称,通常以版本号命名。注意:tag是打在最近的一次Commit记录上的,比如我最近一次提交记录的Commit ID是 7fd77215642fe36e73674f604ef49a0097d3c0d3,那么执行完 git tag v1.6命令后,tag就打在了这个Commit ID上。
还可以通过加上 -a 参数来创建一个带备注的tag, 备注信息由 -m 指定:
$ git tag -a v1.6 -m "publish v1.6 version"
4.7.2 列出已有的tag
$ git tag v1.0 v1.1 v1.2 v1.3 v1.3-bugfix v1.5 v1.6
还可以加上 -l 命令使用通配符来过滤tag, 这在tag列表比较多的时候很有用:
$ git tag -l "v1.3*" v1.3 v1.3-bugfix
4.7.3 同步tag到远程服务器
$ git push origin v1.6 Total 0 (delta 0), reused 0 (delta 0) To https://github.com/yongdaimi/AndroidApiTest.git * [new tag] v1.6 -> v1.6
和提交代码一样,tag默认创建是在本地的,需要进行推送才能到达远程服务器,如果要推送本地所有tag,可以使用:
$ git push origin --tags
4.7.4. 查看某个tag的详细信息
$ git show v1.6 commit 7fd77215642fe36e73674f604ef49a0097d3c0d3 (HEAD -> master, tag: v1.6, origin/master, origin/HEAD) Author: nisha_chen <nisha_chen@realsil.com.cn> Date: Fri Oct 25 14:33:05 2019 +0800 android: update current version to 1.6 diff --git a/app/build.gradle b/app/build.gradle index 55786a4..b100875 100644 --- a/app/build.gradle +++ b/app/build.gradle @@ -6,8 +6,8 @@ android { applicationId "com.yongdaimi.android.androidapitest" minSdkVersion 21 targetSdkVersion 28 - versionCode 5 - versionName "1.4" + versionCode 6 + versionName "1.6" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" } buildTypes {
使用git show 加上 tag名来查看指定tag的详细信息。
4.7.5. 为历史版本添加tag
$ git tag v1.1.1 03f98856b1a422b5604fc1337500b756513e785c
利用git log 查看结果:
commit 093dafc3e88d8708fa26ac94919d901024878209 (tag: v1.2) Author: nisha_chen <nisha_chen@realsil.com.cn> Date: Fri Oct 25 10:57:31 2019 +0800 android: update current version to v1.2 commit 03f98856b1a422b5604fc1337500b756513e785c (tag: v1.1.1) Author: nisha_chen <nisha_chen@realsil.com.cn> Date: Fri Oct 25 10:55:21 2019 +0800 android: update current version to V1.1 commit b16b7376506439d5dd649a8352e5ccb78b455000 (tag: v1.1) Author: nisha_chen <nisha_chen@realsil.com.cn> Date: Thu Oct 24 18:03:49 2019 +0800 Bluetooth: Add a interface about scan bluetooth device 也可以使用下列命令实现: $ git tag -a v1.2 9fceb02 -m "my tag"
9fc3b02 是某次Commit ID的前7位,Git不要求写全所有的Commit ID数字。
4.7.6 删除tag
$ git tag -d v1.6 Deleted tag 'v1.6' (was 03f9885)
这样只是把本地的tag删除掉了,如果要同时删除服务器上的tag,可以使用
$ git push origin :refs/tags/v1.6 To https://github.com/yongdaimi/AndroidApiTest.git - [deleted] v1.6
4.7.7 利用tag功能切换并修改某个历史版本
$ git tag v1.0 v1.1 v1.2 v1.3 v1.5
这里修改v1.3版本:
$ git checkout -b feature-bugfix-v1.3 v1.3 Switched to a new branch 'feature-bugfix-v1.3'
语法是:git checkout -b [branchName] [tagName], 在 feature-bugfix-v1.3 这个分支上修改完毕后切回 master分支并合并 bugfix 分支:
$ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. $ git merge feature-bugfix-v1.3 Merge made by the 'recursive' strategy. test.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 test.txt