如果一切顺利的话,可以在用户主目录里找到 .ssh 目录,里面有 id_rsa 和 id_rsa.pub 两个文件,这两个就是SSH Key的秘钥对, id_rsa 是私钥,不能泄露出去, id_rsa.pub 是公钥,可以放心地告诉任何人。
第2步:登录gitee,打开账号设置,从左边目录中找到ssh公钥:
2. HTTS协议
当然不配置公钥也可以使用HTTS协议。
3. 克隆
使用https协议
git clone https://gitee.com/zhao-yuchen_wanqui/learngit.git
使用ssh协议
git clone git@gitee.com:zhao-yuchen_wanqui/learngit.git
1.2 添加远程库
首先,登陆Gitee,然后,在右上角找到“新建仓库”按钮,创建一个新的仓库:
注意不要选择初始化仓库和模板,要创建一个空的仓库
点击创建会出现如下内容:
简易的命令行入门教程:
Git 全局设置:
git config --global user.name "xxx"
git config --global user.email "13191810+wanqui@user.noreply.gitee.com"
创建 git 仓库:
mkdir learngitq1
cd learngitq1
git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin git@gitee.com:xxxwanqui/learngitq1.git
git push -u origin "master"
已有仓库?
cd existing_git_repo
git remote add origin git@gitee.com:xxxwanqui/learngitq1.git
git push -u origin "master"
下一步,就可以把本地库的所有内容推送到远程库上:
$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
把本地库的内容推送到远程,用 git push 命令,实际上是把当前分支 master 推送到远程。由于远程库是空的,我们第一次推送 master 分支时,加上了 -u 参数,Git不但会把本地的 master分支内容推送的远程新的 master 分支,还会把本地的 master 分支和远程的 master 分支关联起来,在以后的推送或者拉取时就可以简化命令。
- git push 提交代码
- git pull 拉取代码
推送成功后,可以立刻在gitee页面中看到远程库的内容已经和本地一模一样:
从现在起,只要本地作了提交,就可以通过命令:
git push origin master
1.3从远程库克隆
打开另一个窗口模拟其他小伙伴下载远程库
1.4 分支管理
1.4.1 创建与合并分支
首先创建分支,我们刚开始都是只有个master分支,现在我需要创建一个dev1分支,然后对dev1分支中的内容进行更改,然后再将dev1与master合并。
- 当前这是我们的一条分支,也就是我们的主分支,master分支,我们的HEAD也是指向这我们的master。
- 当我们创建一个dev1分支,并切换到dev1分支,查看log,发现现在HEAD指向了dev1。dev1和master处于同一个版本中。
分支情况:
- 这个时候我们对文件进行操作还有进行提交就是对dev1的操作了,当我们进行了一次新的提交:
分支情况就变成这样了:
假如我们在 dev 上的工作完成了,就可以把 dev 合并到 master 上。Git怎么合并呢?最简单的方法,就是直接把 master 指向 dev 的当前提交,就完成了合并
- 我们切换回master,然后查看刚刚修改的文件,发现刚刚添加的东西消失不见了:
- 要想把刚刚对dev1的修改出现再master中,我们就需要进行合并,达成下面的样子:
Administrator@zyc MINGW64 /s/study/03git/learngit (master)
$ git merge dev1
Updating 8c94e5c64..37e774f05
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge 命令用于合并指定分支到当前分支。合并后,再查看 readme.txt 的内容,就可以看
到,和 dev 分支的最新提交是完全一样的。
合并完成后,就可以放心地删除 dev 分支了,删除后我们查看一下分支:
总结:
总结:
- git checkout
- git checkout – file:把版本库的文件重置到工作区(撤销工作区的修改)
- git checkout master:切换到master分支
- git checkout -b dev:创建dev分支,并且切换到dev分支
- git branch
- git branch:列表分支分支,有*当前的分支
- git branch dev:创建dev分支,如果切换需要git checkout dev
- git branch -d dev:删除分支
- git merge dev:合并分支
1.4.2 版本冲突
- 我们准备好新的分支,然后进行新的开发:
# 这里我们使用到了一个新的命令git checkout -b feature1
# 等同于:
git branch feature1 #创建分支
git checkout feature1 #切换分支
- 然后我们对readme.txt进行修改:
这里我对readme.txt进行了修改,在最后新增加的一行new feature1 simple 内容,并进行提交- 切换到 master 分支:
Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。- 这时,我们将master中的readme.txt最后添加一句 new master simple并提交:
这个时候我们可以想到现在的分支情况如下:
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:
果然冲突了!Git告诉我们, readme.txt 文件存在冲突,必须手动解决冲突后再提交。 git
status 也可以告诉我们冲突的文件
然后我们查看readme.txt的内容
Git用 <<<<<<< , ======= , >>>>>>> 标记出不同分支的内容,我们修改如下后保存:
new master and feature1 simple
再次提交:
现在, master 分支和 feature1 分支变成了下图所示:
用带参数的 git log 也可以看到分支的合并情况:
最后删除分支feature1,并查看log:
就会变成如下分支:
1.4.3 分支管理策略
- fast forward模式
通常,合并分支时,如果可能,Git会用 Fast forward 模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用 Fast forward 模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。下面我们实战一下 --no-ff 方式的 git merge :
首先,仍然创建并切换 dev 分支:
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件,并提交一个新的commit:
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+)
现在,我们切换回 master :
$ git checkout master
Switched to branch 'master
准备合并 dev 分支,请注意 --no-ff 参数,表示禁用 Fast forward :
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit,所以加上 -m 参数,把commit描述写进去。
合并后,我们用 git log 看看分支历史:
$ git log --oneline --graph
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...
可以看到,不使用 Fast forward 模式,merge后就像这样:
- 分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
- master 分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
- 那在哪干活呢?干活都在 dev 分支上,也就是说, dev 分支是不稳定的,到某个时候,比如1.0版本发布时,再把 dev 分支合并到 master 上,在 master 分支发布1.0版本;
- 你和你的小伙伴们每个人都在 dev 分支上干活,每个人都有自己的分支,时不时地往 dev 分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
我们执行以下操作进行练习:
#创建本地dev分支
git checkout -b dev
#提交dev给服务器
git push origin dev
#创建bob的本地分支
git checkout -b bob
#创建env.txt
touch env.txt
#提交
git add .
git commit -m "add env bob"
#回到dev,合并bob分支
git checkout dev
git merge bob
#上传dev到远程
git push origin dev
#注意,只下载master分支,其他分支不会被clone
git checkout -b dev
git branch --set-upstream-to=origin/dev dev
#等价于
git checkout -b dev origin/dev
#拉取dev分支
git pull origin dev
#创建mickey分支
git checkout -b mickey
#修改env.txt增加内容"mickey env"
vim env.txt
#提交
git add .
git commit -m "update env by mickey"
#合并到dev
git checkout dev
git merge mickey
# 上传
git push origin dev
合并到master分支
#拉取最新代码
git pull origin master
![img](https://img-blog.csdnimg.cn/img_convert/f608e2be4e9ab6d1cf382a5768e4d363.png)
![img](https://img-blog.csdnimg.cn/img_convert/8c887db17b9df82713786237af048825.png)
![img](https://img-blog.csdnimg.cn/img_convert/a42a093f76c8f9824187d0c27dd3f7c1.png)
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
gin/dev
#拉取dev分支
git pull origin dev
#创建mickey分支
git checkout -b mickey
#修改env.txt增加内容"mickey env"
vim env.txt
#提交
git add .
git commit -m "update env by mickey"
#合并到dev
git checkout dev
git merge mickey
# 上传
git push origin dev
合并到master分支
#拉取最新代码
git pull origin master
[外链图片转存中...(img-6C0zpQhr-4702043030686)]
[外链图片转存中...(img-S5XVJlLn-4702043030687)]
[外链图片转存中...(img-v2WPGIVr-4702043030687)]
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**