Java阶段五Day03

回顾git命令

本地版本控制

• git init
• git add
• git commit
• git log
• git status
• git tag
• git reflog
• git reset

分支管理

• git branch
• git branch b1
• git checkout b1
• git merge b1
• git rebase b1

Git远程仓库

远程仓库概念

git 分布式的版本控制软件，同时支持去中心化

为了方便版本的交换，通常会使用一个中心服务器，24小时连续运行，提供版本控制服务
这就有两种做法：
自己搭建中心服务器（公司内部搭建gitlab）
使用类似GitHub的代码托管网站（国内时gitee）       
目前我们更多使用代码托管的方式进行开发工作

登录gitee 如何将本地代码，推送到远程，关联到远程.

远程仓库分支操作

• 在托管平台准备一个空仓库

• 在当前本地项目中添加远程仓库关联

使用git remote命令来添加仓库

git remote -v

不携带参数执行，是查询本地仓库关联的远程仓库，可以关联很多个.

使用add子命令，来添加你的目标远程仓库

git remote add {自定义仓库名称} {仓库地址*.git}
git remote add gitee-repo https：//gitee.com/xiaolaoshi202
1/git-demo.git

• push 推送

和远程仓库关联之后，可以通过push推送. 可以先确保本地有提交的数据.

git push {仓库名称} {本地分支名称}

如果是第一次push或者fetch，本地要填写远程仓库用户名密码

• gitee添加团队成员

• 克隆远程仓库项目

团队其他成员，可以通过连接远程仓库，进行项目克隆

git clone {远程仓库地址} 目录名称
git clone https：//gitee.com/xiaolaoshi2021/git-demo.git ./git-demo-b

• 远程分支概念

刚刚克隆的项目，只有默认分支（master），同步到了本地分支

在当前项目由于关联的远程托管中心，分支分成了2批，第一批就是本地分支

第二批就是远程分支

可以像操作本地分支一样，部分命令可以操作远程分支.

• 查看并切换分支

git branch -a

查看当前仓库中所有的分支信息，包括远程分支.

注意：永远不可能在本地仓库对远程remotes分支进行修改.因为在本地看到的远程分支只是元数据（描述远程分支信息的数据，描述数据的数据）.

可以执行分支的切换命令

git checkout {分支名称}

这个命令缺少必要选项，导致切换远程分支，没有创建本地分支.

1. 查询对应选项，完成命令操作
2. 使用idea的按钮切换分支checkout

注意： 一般情况下，多分支开发时，个人只关心自己的分支，不关心其他人分支.

• 多人协作连接远程仓库开发-对同一个分支并行开发

特点：和本地同一个分支并行开发一样的情况.

• 处理同一个分支开发的push冲突

先pull在push，绝大部分问题，都不存在了，pull的同时，自动进行合并

有可能在pull的时候，处理冲突，没有冲突，自动合并

多人同时开发一个分支不合理，会造成推送 下来的不便

• 如果pull过程有文件冲突–同一个分支多人开发

只要在pull的时候有文件的冲突问题，和本地分支合并 文件冲突解决方法是一样的.

accept yours 保留本地分支版本文件

accept theris 保留远程其他分支版本文件

merge 手动处理冲突 出现以下画面

分支管理策略

企业开发过程中，总是满足一种比较规范的分支管理策略（所有分支操作，包括远程，都已经在上述的命令，案例中包括）

• gitflow： 最老版本，最规范的分支使用策略，满足版本发布特点
• githubflow： 满足持续发布
• gitlabflow： 既能满足版本发布，又能满足持续发布

版本发布： 游戏 v1.0.1 v1.1.0

持续发布： web网站

核心都是分开开发，定义分支的意义（gitflow定义分支的使用规范最全）

1. 永久分支：

   1. master： 保管的永远是稳定代码版本（几乎没有bug），什么时候代码测试的差不多了，才能合并到master
   2. develop： 开发分支，所有功能推进都基于develop进行

2. 临时分支

   1. eature-XX： 新功能分支，来自于develop，XX可以是人名，可以是功能名称，不同的开发人员开发维护不同feature分支，最终合并到develop，删除
   2. release分支： 保护分支，来自于develop，目的是测试develop不影响develop开发，如果测试有问题，修改bug，合并到deveop和master，在master做版本最终上线（合并到master意味着代码要上线），归宿一定是master，可能也会合并dev
   3. hot-fix： 热点修复，解决线上bug，来自于master，归宿一定是master和develop

   

一版情况下，根据公司的规模，仿照这个gitflow规范，定义公司分支的管理

大部分情况下：

1. 直接发布develop
2. 新功能也是基于·develop·实现的，不会使用master

单体架构(微服务理论基础)

• 什么叫做单体架构

开发一个web应用，将所有接口功能，都集中管理开发在一个项目中，这种项目叫做单体架构

• 有什么优点
  • 结构简单，开发成本低
  • 部署运维成本低
• 有什么缺点
  • 如果功能是不断扩展，项目代码，功能代码非常臃肿
  • 并发的木桶原则问题

随着业务增长，功能一定是在不断增长的。为了降低一个系统的业务成本，提供灵活可扩展的结构。单体架构，不在适用

• 纵向拆分

按照业务功能，将单体架构中的功能独立拆分开，单独部署，单独开发，单独维护，每一个拆分出来的项目相互不影响——纵向拆分

纵向拆分带来的最直接的一个问题——业务分布式系统，考虑负责的分布式环境下的各种问题，比如功能调用问题

假设使用socket进行通信代码编写，Aservice远程通信调用Bservice。Aservice，建立客户端连接socket，Bservice建立SocketServer

除了代码编写成本过高，目标ip:port如何获取.

实现上述问题的最终落地解决——微服务

附录 补充内容

idea运行多个springboot-web应用

• 启动一个springboot应用
• 修改启动配置项

• 修改覆盖源代码中的端口号