git连接gitee远程仓库及使用_git远程仓库怎么引入，非科班面试之旅

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

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 版本冲突

1. 我们准备好新的分支，然后进行新的开发：
   

# 这里我们使用到了一个新的命令git checkout -b feature1
# 等同于：
git branch feature1 #创建分支
git checkout feature1 #切换分支

2. 然后我们对readme.txt进行修改：
   
   这里我对readme.txt进行了修改，在最后新增加的一行new feature1 simple 内容，并进行提交
3. 切换到 master 分支：
   
   Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。
4. 这时，我们将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 分支管理策略

1. 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后就像这样：

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

• 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
git pull origin dev
git checkout master
git merge dev
#上传
git push origin master

到这里我们今天的学习就结束了，当然，我在学习中还和周围的小伙伴进行了更深入的测试，我们让其中一个人（A）负责使用dev对master进行版本更新，另外两个人（B）（C）克隆下载A的远程仓库learngit，然后并创建分支dev与远程仓库dev连接，并创建自己姓名的分支，对分支进行修改，然后B先再dev分支使用pull拉取最新的版本，然后和自己姓名的分支进行合并，然后使用push进行提交，这时候A从远程仓库使用pull拉取B最新提交的dev和远程仓库的master，然后在master合并dev并完成提交，实现对远程仓库master的版本更新。

有条件的朋友可以拉着自己的小伙伴进行测试。

1.4.4 分支实战

1. Bug分支
   软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

​

现在，用git status`查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要master分支上修复，就从master`创建临时分支：

现在修复bug并提交：

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！回到dev分支，查看status没有显示，然后使用git strah pop恢复：

当然还可以用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除，你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
​ 同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
​ 为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

2. Feature分支
   软件开发中，总有无穷无尽的新的功能要不断添加进来

当我们接到任务，需要给程序添加一个新功能，我们需要创建一个新的分支进行编写：

5分钟后，开发完毕：

切回dev，准备合并：

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。但是！就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：

销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。

强行删除：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。

强行删除：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）
[外链图片转存中…(img-LbkO7jrw-1713127860894)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！