week11_day05_Git

1回顾

1.1Tomcat
1, 安装和启动tomcat,
2, 部署java的war 包: 把打包好的war放到webapps下, 启动tomcat
3, 熟悉tomcat组成结构(逻辑):
4, 熟悉虚拟映射
Tomcat的某一个服务监听http协议的端口：

Tomcat的启动端口：

其实启动任何让软件都要占用端口的。
Tomcat就相当于一个学校的保安，保安占用一个端口（启动端口），保安要监听一个端口（监听端口）。

Host name=“localhost” appBase="webapps
Context docBase=“C:\Users\chen\Desktop\qq” >
docBase 和webapps 的关系 不清楚
host 的 appBase 指向的路径, 在这个路径之下的每一个文件夹, 都是一个项目(默认)
context的配置的虚拟映射, 就是把它所指向的地址所对应的项目, 放到(虚拟的映射)配置文件种所在的虚拟主机(host)之下
就相当于Tomcat把C:\Users\chen\Desktop\qq目录下的文件拿过来，放到webapps目录下。
虚拟映射
对非技术的, 操作性的东西, 多问一下为什么?

---

2Git

2.1Git: 版本控制
工作: 怎么开发一个项目的?
1-2年:
1年-半年: 比较常见的.
产品+程序员: 调研, 研究需求, 考虑可行性. 开会-考察-讨论-考察-讨论: 半个月-1,2个月
程序员(1,2,3): 搭建整体框架, 确定技术选型, 构建基础表（数据库表）, 1-2月不等

更多的程序员 (项目组): 具体开发业务
业务: 一个用户做了一个动作, 触发一个后台操作, 这个后台操作过程中的各种逻辑,
开发业务: 都是有任务周期, 版本
版本1.0: 有哪哪些功能: 1月
版本1.1: 有哪哪些功能: 1月

小版本1.0 : 每周给你分配的任务（周报）, 每天任务怎么样了

1-2: 熟悉业务(先明白要干啥), 写代码(5天), 2天测试, 提测(给测试人员测试)
提出bug, 修改bug, 自测, 提测, ……

大版本出来, ----部署发布-----反馈修改----进行下一个版本

2.2版本控制
版本控制(Revision control)是维护工程蓝图的标准做法，能追踪工程蓝图从诞生一直到定案的过程。是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。

追踪文件变化— 版本控制的核心
记录的是变化

2.3Git的基本逻辑
是一个分布式版本控制工具

多个服务 分布 在不同的电脑上, 这些服务通过某种途径, 可以相互关联(相互通信, 相互同步)

对于git的分布式

1, 在不同的电脑上都有代码, 然后这些代码可以通过git在不同的电脑上管理起来
2, 经过管理起来的代码, 都可以关联一个远程仓库
3, 多个人各自git管理起来的代码, 可以关联同一个远程仓库
4, 实现了, 不同人之间代码, git管理的代码之间的 间接关联

我们代码在我们电脑上,到底怎么被我们电脑安装的git管理起来的?
1, 本地仓库: 代码
我们修改代码, git记录修改的具体信息, 记录的是变化, 这些变化, 存储在本地仓库

2, 工作空间, 工作区:;
我们通过本地仓库记录的是变化, 但是我们又要具体写代码, 写代码这个地方, 叫工作空间
我们有一个事情要做, 当我们改变了代码(发生在工作空间), 要把代码的改变最终反馈给本地仓库: 所以我们要有一个把工作空间变化,反映到本地仓库的操作

3, 缓存区,
工作空间的变化, 是无法直接反馈给本地仓库, 要先提交变化给缓存区, 缓存区再提交变化给本地仓库

提交到远程仓库后，别人就可以下载你的改变，把你的改变下载到它的本地仓库中去，本地仓库的改变会直接影响到工作空间的改变，工作空间的文件立即会变化。
你的工作空间改的代码会通过这种途径最终在别人的代码中显示出变化来。

2.4安装Git客户端
如果在桌面右击，出现Git Bush Here，说明安装成功了。

通过命令行进行操作。

---

3Git的使用
3.1给你的电脑添加用户名和邮箱
Git config --global user.name ‘用户名’
Git config --global user.email ‘邮箱’

3.2创建远程仓库
第一种: 借用一些现成的能提供代码管理的第三方服务
Github, 码云
记住你的账号, 密码, 邮箱

第二种: 自己构建一个服务器(git服务器), 访问这个服务器

3.2.1创建远程仓库

3.3把远程仓库下载到本地和本地仓库关联
Git clone 地址

这个命令, 表示从远程仓库复制一份代码,到本地, 并且帮我们创建一个文件夹
这个文件夹, 就是git clone 这个命令下载远程仓库代码后, 同时帮我们创建的, 本地仓库+缓存区+工作空间

我们可以用一个A文件夹和一个B文件夹来模拟两个用户，从远程仓库clone到A文件夹和B文件夹。本地仓库就是.git文件，而且.git文件的作用域仅仅在此文件夹中，所以理所应当的就能用两个文件夹A和B来模拟两个用户。

3.4查看工作空间和缓存区
Git status: 用来查看工作空间和缓存区, 它们文件状态

这段话表示B.java是未被记录的。

3.5把工作空间的变化, 提交到缓存区
Git add 文件名
Git add . ‘.’表示所有
Git add *.java : 表示把所有以.java为后缀的文件提交到缓冲区 尽量不要使用(忽略文件无法追踪）

把***文件, 提交到缓存区

3.6把缓存区的变化添加到本地仓库
Git commit -m ‘描述’
把缓存区的所有变化提交到本地仓库
这个命令在从缓存区提交到本地仓库变化的同时, 还创建了一个全新的版本

3.7查看版本
Git log

你会发现Author是zs
C:\Users\Administrator.gitconfig文件下就有保存Author

3.8上传到远程仓库
Git push

3.9从远程仓库获取变化
Git pull

3.10版本回退和回退问题
3.10.1想回退工作空间的变化
还没有执行git add , 这个变化还停留在工作空间

Git checkout .
Git checkout 文件名
回退到版本之前的样子

3.10.2想回退缓存区的变化（缓冲区退到工作空间）
还没有提交到本地仓库, 缓存区有一些变化, git add 之后
Git reset 文件名
Git reset .

3.10.3已经提交到本地仓库,想回退
3.10.3.1想回退到工作空间
工作空间的修改要保存, 回退 commit add 这两个命令
Git reset --mixed HEAD^

用git log后，如果日志显示的够多的话，会出现这种情况：

Esc:q或q!，然后回车
3.10.3.2想回退到缓存区
保留add 操作 , 回退commit 操作
Git reset --soft HEAD^

3.10.3.3想直接回退所有
Commit add 工作空间的改变, 都不要了
Git reset --hard HEAD^

3.10.4已经提交到远程仓库
这种情况就比较复杂了，不是一个命令就能解决的问题，要根据情况具体分析。
而且从工作的角度来分析的话，不要轻易回退远程仓库的版本。很容易出现回退错误，万一你把别人的代码回退了，就完了。
如果发现远程仓库的代码错了，最好改一下再提交一份新的。
3.11分支问题
为什么要产生分支.
在原有代码的基础上, 复制一份开发, 开发完成(开发和测试), 再把代码合并会原有的代码。分支的存在的主要意义是为了防止主线出啥问题。

3.11.1查看分支
Master: 表示主线, 主干 主分支

Git branch -a

3.11.2创建分支命令
Git checkout -b 分支名: 创建一个分支并且切换到刚创建的这个分支
这个命令等价于两个命令
创建分支: git branch 分支名
切换分支: git checkout 分支名
3.11.3切换分支

3.11.4把本地创建的分支提交到远程仓库
Git push origin 分支名: 分支名
本地分支名: 远程仓库的分支名

3.11.5合并分支
切换到要合并分支的目的分支上, 再把要合并的分支,合并回来
Git merge 分支名

相当于你给你的master增加了一些代码，这些代码原本在dev1上的。

3.11.6删除分支
删除远程仓库分支
Git push origin -delete 分支名

删除本地分支(未合并的)
Git branch -D 分支名

删除本地仓库分支(以合并的)
Git branch -d 分支名

---

3.12冲突 当两个用户, 都创建的一个版本(同时修改了某一个文件), 并且这个版本是基于某一个历史版本的, 而且, 这两个新版本, 要面临合并. 那么就会冲突 每一个竖杆表示一个版本

此时，冲突就产生了。

也可能A、B所提交的版本并不是基于同一个历史版本。

第一个问题, 冲突经常产生么?
不经常, 因为都是分业务模块实现代码, 公共类容易产生冲突

第二个问题, 谁来解决冲突?
谁遇到, 谁解决

第三个问题, 什么时候提交代码push, 什么时候拉新代码pull,
要下班之前 刚来上班

不要逃避这个责任.

演示个例子：
E:\WangDao\Git_project\programmer_B\th22下修改A.java，然后提交到远程仓库。
将A.java改成这样：


现在programmer_B有一个新版本，远程仓库有一个新版本。

现在programmer_A也改E:\WangDao\Git_project\programmer_A\th22目录下的A.java
将A.java改成这个样子：

首先是一个能不能pull，不能。

然后programmer_A工作空间中的A.java就变成了这样：
这就是冲突。

有了冲突就和产生冲突的同事商量着解决，怎么重新修改A.java，修改完之后，

这就说最常见的冲突，有人说分支合并时，也会发生冲突。这是你的设计问题，既然设计了分支，为啥还要在主干上咔咔咔修改。

如果A文件是我自己写的，我自己修改了，然后push，这个算更新？
如果另一个人修改了，然后push，这算冲突？
这只取决于一个问题，别人有没有pull，如果先pull的再去修改，不会产生冲突。
如果别人没有pull，别人直接改了，他不知道你修改了，然后他push上去就会产生冲突

3.13注意:
3.13.1IDEA
一般的add、commit、push、pull

创建一个新的本地工作空间、本地仓库、缓冲区：

IDEA关于git的两个好处：
1.查看历史记录：Show history每个点就代表一个版本。

2.解决冲突很方便。修改之后可以直接push，不需要在add、commit等。

还可以手动创建分支：

3.13.2注意1:
Push: 之前就要习惯性 pull
如果有和同事不同的代码，会有冲突。

3.13.3注意2:
版本回退: HEAD^ 表示回退到前一个版本
HEAD^^^^ 表示回退到前四个版本

可以直接写版本号

比如可以用 5f78d5ef8a9aa8afad8f3c94ebf121c42e6dcb2b 替换 HEAD^^^

3.13.4注意3: 忽略文件
有些东西是是我们不想提交的.
Vue项目里的.gitignore 配置的文件, 都将会被git 忽略(不追踪)
注意这个文件要和 .git同级(放到工作空间里)

已经提交了, 已经追踪了某个文件的变化, 再忽略, 没用了。
如果想让远程仓库忽略，先把本地仓库的这个文件删了，再提交。

如.idea文件，是idea关于索引和加载配置的文件，别提交，你每次改完代码，这个文件也会变的，就得每次都提交。
还有Vue项目下的node.modules，这个也没必要提交，都是配置文件。

3.13.5注意:
本地有项目, 想直接提交到远程仓库
比如本地有个名字为Vue1的项目。先在远程仓库创建一个空的名为Vue1的项目，在把它clone下来，本地就有空的Vue1项目了。然后把原本的Vue1项目移到这个空的Vue1项目下。
但我不想这么麻烦，我想把本地的Vue1项目直接提交到远程仓库。Git init创建.git文件。但是还没和远程仓库关联起来，可以单击搞，不能push，要想和远程仓库关联起来：get
Remote add original 远程仓库地址。然后git pull，然后再push（如果远程仓库是空的，可以直接push）。

3.13.6注意:
输入账号和密码: 按提示输入

如果让你重复的输入账号和密码，执行下面这条语句就能不再提示让你重复输入账号密码
Git config --global credential.helper store

4重点
所有都是

5作业
创建一个远程仓库, 大家分别提交一些代码, 制造冲突, 解决冲突
1, 成员的图
2, idea 冲突图