git学习

一、推送到远程仓库

方法1、先将仓库clone到本地，修改后再push到 Gitee 的仓库

1、

git clone https://gitee.com/用户个性地址/HelloGitee.git #将远程仓库克隆到本地

如果仓库是一个私有仓库，会要求用户输入gitee的帐号和密码

2、用户也可以通过配置本地的git配置信息，执行git config命令预先配置好相关的用户信息，配置执行如下：

$ git config --global user.name "你的名字或昵称"
$ git config --global user.email "你的邮箱"

3、修改代码后，在仓库目录下执行下面命令

$ git add . #将当前目录所有文件添加到git暂存区
$ git commit -m "my first commit" #提交并备注提交信息
$ git push origin master #将本地提交推送到远程仓库

方法2、本地初始化一个仓库，设置远程仓库地址后再做push

1、和方法1的差别，在于先创建仓库。

$ git init 
$ git remote add origin https://gitee.com/用户个性地址/HelloGitee.git

这样就完成了版本的一次初始化。
2、接下去，进入你已经初始化好的或者克隆仓库的目录,然后执行：

拉取操作，抓取远程分支同时合并到当前分支
$ git pull origin master

3、修改/添加文件，否则与原文件相比就没有变动。

$ git add .
$ git commit -m "第一次提交"
$ git push origin master

在新建仓库时，如果在 Gitee 平台仓库上已经存在 readme 或其他文件，在提交时可能会存在冲突，这时用户需要选择的是保留线上的文件或者舍弃线上的文件，如果您舍弃线上的文件，则在推送时选择强制推送，强制推送需要执行下面的命令(默认不推荐该行为)：

强制推送
$ git push origin master -f
保留线上文件
$ git pull origin master

 

二、拉取远程仓库并合并与冲突解决方法

1、将远程仓库的代码拉取到本地

git clone <https://xxxx> [filename] # 使用 https
git clone git://xxxxxx [filename] # 使用 ssh

2、查看已经配置的远程仓库

# 查看远程仓库
git remote

# 查看远程仓库对应的简写和 URL
git remote -v

# 查看远程仓库的详细信息
git remote show <远程仓库 shortname>

$ git remote show https://github.com/tianqixin/runoob-git-test

3、添加、删除、重命名 远程仓库

使用场景：自己在本地初始化了一个 Git 仓库，想要推送到远程仓库，可以自己添加

# 格式：git remote add <shortname> <url>
$ git remote add pb <https://git.shefcompsci.org.uk/com61/team03/project.git>

删除

git remote remove <远程仓库 shortname>
$ git remote remove pb

重命名

git remote rename <远程仓库旧名字> <远程仓库新名字>
$ git remote rename pb tes

4、从远程仓库抓取和拉取并合并当前分支

抓取（fetch)

从远程仓库下载新分支与数据
git fetch <remote>    

从远端仓库提取数据并尝试合并到当前分支：
git merge

合并后进行查看，在本地解决冲突
git status

假设你配置好了一个远程仓库，并且你想要提取更新的数据，你可以首先执行 git fetch [alias] 告诉 Git 去获取它有你没有的数据，然后你可以执行 git merge [alias]/[branch] 以将服务器上的任何更新（假设有人这时候推送到服务器了）合并到你的当前分支。

 

例如

远端仓库修改后，要在本地更新修改，执行

zll@zll-device:~/testgit$ git fetch origin
Username for 'https://gitee.com': zhonglinlin
Password for 'https://zhonglinlin@gitee.com': 
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
展开对象中: 100% (3/3), 947 字节 | 473.00 KiB/s, 完成.
来自 https://gitee.com/zhonglinlin/face
   edd29b7..4ee3240  master     -> origin/master

说明 master 分支已被更新，我们可以使用以下命令将更新同步到本地：

$ git merge origin/master

 

拉取（pull）

当一个分支设置了跟踪远程分支，那么可以使用下面的命令自动抓取该远程分支同时合并到当前分支

更新操作
$ git pull
$ git pull origin

将远程主机 origin 的 master 分支拉取过来，与本地的 brantest 分支合并。
git pull origin master:brantest

如果远程分支是与当前分支合并，则冒号后面的部分可以省略。
git pull origin master

 

5、解决合并冲突

在不同分支更新相同文件时，此操作会导致合并冲突。

例如：

$ git branch
* master

$cat README.md
第一次修改内容

$ git checkout -b test        #创建test分支并切换
$ vim README.md            #修改README.md文件
$ cat README.md   
第一次修改内容
第二次修改内容
$ git commmit -am 'change the README.md'            #将修改内容提交到分支
[test edc59ba] change the README.md
 1 file changed, 2 insertions(+), 1 deletion(-)


$ git checkout master
$ cat README.md          #切换成master分支内容恢复到修改前的文件            
第一次修改内容
$ vim README.md　　　　　　#再次修改
$ cat README.md 
第一次修改内容
第三次修改内容
$ git diff               #比较文件的不同，暂留区与工作区的差异          
diff --git a/README.md b/README.md
index a14919e..d447dff 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
-第一次修改内容
\ No newline at end of file
+第一次修改内容
+第三次修改内容
$ git commit -am '修改代码'       #提交暂存区到本地仓库
[master b74fa32] 修改代码
 1 file changed, 2 insertions(+), 1 deletion(-)


$ git merge test　　　　　　　　　　#将test分支合并到master
自动合并 README.md
冲突（内容）：合并冲突于 README.md
自动合并失败，修正冲突然后提交修正的结果。
$ cat README.md 　　　　　　　　　　#查看冲突内容
第一次修改内容
<<<<<<< HEAD
第三次修改内容
=======
第二次修改内容
>>>>>>> test
$ vim README.md　　　　　　　　#手动修改冲突内容
$ cat README.md
第一次修改内容
第三次修改内容
第二次修改内容
$ git diff　　　　
diff --cc README.md
index d447dff,bc0750e..0000000
--- a/README.md
+++ b/README.md
@@@ -1,2 -1,2 +1,3 @@@
  第一次修改内容
 +第三次修改内容
+ 第二次修改内容
$ git status -s
UU README.md
$ git add README.md 　　　　　　#git add 告诉文件冲突已解决
$ git status -s
M  README.md
$ git commit 　　　　　　　　　　#提交
[master e6e6c1c] Merge branch 'test'

 

 

4、通过 https / ssh 协议推拉代码

Git 可以使用以下四种协议进行资料的传输：

• 本地协议（Local）
• HTTP/HTTPS 协议
• SSH（Secure Shell）协议
• git 协议

目前 Gitee 支持使用 HTTPS协议 和 ssh 协议 进行代码的推送/拉取。两种协议的差别仅在于同一个仓库使用不同协议时的地址不同，以及对应的授权实现不同。

以仓库 https://gitee.com/normalcoder/Gitee-Blog-Applets 为例，对应两种协议的远程仓库地址(remote)如下：

https协议：https://gitee.com/normalcoder/Gitee-Blog-Applets.git

ssh协议：git@gitee.com:normalcoder/Gitee-Blog-Applets.git

https 协议 和 ssh 协议在使用上的差别

使用 https 协议 克隆 对初学者来说会比较方便 ，复制 https url 然后到 git Bash 里面直接用 clone 命令克隆到本地就好了，但是 每次fetch和push代码都需要输入账号和密码 ，这也是 https 协议 的麻烦之处。

而使用 SSH 协议 克隆需要在克隆之前先配置和添加好 SSH key，因此， 如果用户想要使用 SSH url 克隆的话，必须是这个仓库的拥有者 。另外，使用 SSH 协议 默认是每次 fetch 和 push 代码都不需要输入账号和密码。

 

 三、本地与远端分支的管理

1、查看分支

列出所有分支
git branch -a

列出远程分支
git branch -r

列出本地分支
git branch

2、创建分支

git branch 'name'

裸仓库不能使用git branch -b 创建分支，但带有工作区的仓库可以使用

git checkout -b

我们使用branch创建一个分支 是不会切换到新分支上，还停留在原理的分支上，而是用checkout -b 创建完分支后并且会自动切换到新的分支上
当我们创建新的分支时，你在哪个分支上创建的新分支，就会把当前分支上的复制到新的分支上
不论在哪个分支的工作区中新增文件，其它分支都能看到，但是一旦提交了，就属于自己分支的内容了，其它 分支就看不到了，如果其它分支想看到，就需要合并分支

3、切换分支

git checkout 'branchname'

4、删除分支

删除远程分支
git push origin --delete 'branchname'

删除本地分支
git branch -d 'branchname'

注意：在删除分支的时候，是不能停留在要删除的分支上的

 

四、本地与远端提交的回退方法

1、本地版本回退,但保存自该版本起的修改

Git reset commit_id(可用 git log –oneline 查看)

2、回退到当前版本，放弃所有修改

git reset --hard commit_id

3、放弃某个文件的修改

git checkout sample.txt

4、远程版本回退

git push origin HEAD --force #远程提交回退

5、回退到和远程版本一样

git reset --hard origin/master // origin代表你远程仓库的名字，master代表分支名

 

五、提交消息的规范格式

 1、git commit

 
Commit Message 格式
 
<type>(<scope>): <short summary>
<空行>
<body>
<空行>
<footer>

可以看出分为三个部分，头部，主体，底部；

1. 首先是头部，<type>(<scope>):<short summary>
   包括了三个节点：

   • type 类型，修改的类型级别

     • feat：新功能（feature）
     • fix：修补bug
     • docs：文档（documentation）
     • style： 格式（不影响代码运行的变动）
     • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
     • test：增加测试
     • perf:提高性能的代码更改
     • build:影响构建系统或外部依赖项的更改（例如范围：gulp、brocoli、npm）
     • ci：对CI配置文件和脚本的更改（例如：CircleCi、SauceLabs）
   • scope 修改范围
     主要是这次修改涉及到的部分，最好简单的概括
   • <short summary> 修改的副标题
     主要是具体修改的加点
2. body，修改的主体标注，就像在总结中一样，使用祈使句，现在时：“fix”不是“fixed”，也不是“fixs”。
   解释提交消息正文中更改的动机。此提交消息应解释您进行更改的原因。您可以将以前的行为与新行为进行比较，以说明更改的影响。
3. footer里的主要放置不兼容变更和Issue关闭的信息，
   这些东西由于我们书写代码本身就会经常性的提交，所以如果每次都这样书写的确是挺烦人的，所以我目前建议自己采用相同的但是更加简单的方式来完成，

例如：
feat(docs-infra): add @developerPreview tag for APIs in developer preview (#46050)
 
This commit adds a tag processor for `@developerPreview`. Adding this tag to
an exported symbol or to a decorator parameter causes an API status tag to
be shown for the API which links to the Developer Preview documentation.
 
PR Close #46050

 

参考博客：https://www.runoob.com/git/git-basic-operations.html

　　　　　https://zhuanlan.zhihu.com/p/418947255

　　　　　https://gitee.com/help/articles/4122

　　　　　https://git-scm.com/book/zh/v2

　　　　  https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit