思想：版本控制
实现：版本控制工具
集中式版本控制工具：CVS、SVN、VSS … 数据文件和历史版本信息存储在服务器端，客户端与其进行交互 缺点： 存在单点故障问题：如果服务器损坏或宕机，其中历史数据都会丢失 分布式版本控制工具：Git、Mercurial、Bazaar、Darcs … 在本地进行版本控制，每个开发人员的机器上存在历史完整数据，并且可以互相交互数据Git 能做到本地库之间互相传递数据，但常规不进行传递，还是需要远程库的支持目的：在本地创建某个项目的本地库，存放该项目的数据以及历史版本信息，进行版本控制
命令：git init
效果：在 D:/Git/workspaces 目录下，模拟创建 WeChat项目，进行本地库初始化操作，完成代码仓库创建
注意：
. git 目录中存放的是本地库相关的子目录和文件，不能删除，不能胡乱修改如果希望删除某个代码仓库，删除对应仓库的 .git 文件夹即可形式：
用户名：tomEmail地址：goodMorning@atguigu.com作用：区分不同开发人员的身份
辨析：这里设置的签名和登录远程库 ( GitHub代码托管中心 ) 的账号、密码没有任何关系
命令：
项目级别 / 仓库级别：仅在当前本地库范围内有效
git config user.name tom_progit config user.email goodMorning_pro@atguigu.com信息保存位置：项目 / .git / config 文件系统用户级别：登录当前操作系统的用户范围（默认设置）
git config –global user.name tom_glbgit config –global user.email goodMorning_glb@atguigu.com信息保存位置：~ / .gitconfig 文件级别优先级
就近原则：项目级别优先于系统用户级别，二者都存在时采用项目级别的签名 如果只有系统用户级别的签名，就以系统用户级别的签名为准二者都没有不允许进行操作命令：git log
多屏显示控制方式：
空格向下翻页b 向上翻页q 退出历史版本记录显示方式：
每条日志一行显示：git log --pretty=oneline
每条日志一行简洁显示：git log --oneline
online 显示基础上显示移动当前版本所需步数：git reflog使用 ^ 符号回退：git reset --hard HEAD^ – 注意：只能后退版本，一个^表示后退一步，n个表示后退n步
使用 ~符号回退：git reset --hard HEAD~n – 注意：只能后退版本，表示后退 n 步
前提：删除前，文件存在时的状态提交到了本地库
操作：git reset --hard [指针位置]
删除操作已经提交到本地库，指针位置指向历史提交记录找回文件 删除操作尚未提交到本地库，指针位置使用 HEAD 结论：提交新建文件和删除文件的记录都会保存，无法磨灭，可以回退到其版本git diff [本地库中历史版本] [文件名]：将工作区文件和本地库历史版本比较
不带文件名：比较多个文件
查看分支：git branch -v
切换分支：git checkout [分支名]
合并分支： 在修改的分支上进行文件修改，从工作区 add → commit 提交到本地库，分支状态改变 切换到接收修改的分支（增加新内容）上：git checkout [被合并分支名] 执行 merge命令：git merge [接收修改分支名]冲突解决： 编辑文件，删除特殊符号把文件修改到满意的程度，保存并退出 文件添加到暂存区：git add [ 文件名 ]文件提交到本地库：git commit -m "日志信息 "（注意：此时 commit 不能带具体文件名）
哈希是一个系列的加密算法，各个不同的哈希算法，虽然加密强度不同，但也有几个共同点
①不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定
②哈希算法确定，输入数据确定，输出数据能够保证不变
③哈希算法确定，输入数据有变化，输出数据一定有变化（变化很大！！！）
④哈希算法不可逆
Git 版本控制工具底层采用：SHA-1哈希算法
哈希算法作用：校验文件
原理：
Git 依赖这种机制，从根本上保证数据完整性
切换 HEAD指针指向：之前指向的是 master分支，现在指向 testing分支
注意：此时指向的其实是同一版本在 HEAD指针指向 testing分支时，提交新的内容，版本信息相对于旧版本会更新
当 HEAD指针切换指向回 master分支，效率极高，只是移动指针位置，不涉及文件的创建
当 HEAD指针指向 master分支，再次提交新内容，testing / master 分支指向不同版本，以 f30ab 为父对象
命令：git push [远程库地址别名] [分支名]：推送本地库文件到github的远程库
推送流程：
先登录github，建立连接 执行 push 推送命令，成功推送文件 → github的远程库问题：如果想把修改文件推送到远程库，还是不可以，因为新用户还未加入团队
邀请成员流程：
在 github 上的远程库的设置中，邀请团队成员进入团队 获取邀请链接，发送给被邀请成员（https://github.com/programmer-jjq/huashan/invitations） 被邀请成员登录 github账号，访问邀请链接，同意接受邀请 →进入团队 加入团队后，获取写权限，新用户就可以 push命令推送修改文件到远程库pull = fetch + merge （读操作，无需登录验证身份）
pull 命令分离优势： 当拉取操作复杂时，暂时不对本地库文件进行合并，等确定好远程库拉取下的文件后，再去合并git fetch [远程库地址别名] [远程分支名]
fetch抓取：将远程库内容下载到本地库，但并不修改合并本地库文件（保存到另一分支）git merge [远程库地址别名 / 远程分支名] 将远程拉取的master 合并到本地的 master分支
git pull [远程库地址别名] [远程分支名] – 当推送和拉取的内容简单，不可能存在冲突时，使用该方式团队协作：团队内两个用户同时修改本地库同一文件并推送远程库，会发生冲突
先推送的用户推送成功：后推送的用户推送失败：
解决思路：
后推送的用户：必须先拉取前推送用户推送的文件到本地（文件内部会有冲突，需要手动解决） 冲突解决后，再执行推送命令，即可推送成功问题：如果不是基于 GitHub 远程库的最新版本做出的修改，不能推送，必须先拉取解决冲突后在推送
解决：拉取下来后，如果进入冲突状态，按照 “分支冲突解决” 操作解决即可
复制 ybc 与 lhc 用户的远程库链接地址，登录 dfbb 的Github账户，访问该链接地址，点击 fork 按钮
dfbb 用户将远程库中内容 clone 到本地库，文件进行修改后，push命令推送到 dfbb 远程库
执行 Pull request 命令： 登录 ybq 的 github账户，接收 Pull requests，并且点击进入并且可以在 pull request 中，可以进行隔空对话： 在ybq 的 github上，进行审核代码： 如果审核不存在问题，点击【Merge pull request 】，合并代码。填写日志信息，代码合并完成
将远程库修改的内容拉取到本地，完成跨团队协作解决问题：
平时只操作一个 GitHub账号时，每次基于 Http地址 执行 Push推送命令都需要登录账号，过于繁琐
Window10系统的凭据管理器功能可以保存账号密码，执行推送时免登录其他系统解决方法：配置基于 SSH地址执行 Push推送命令的免密登录免密登录配置流程：
进入当前用户的系统根目录，删除 .ssh目录
复制 GitHub 邮箱，运行命令生成 .ssh 密钥目录（ssh -keygen -t rsa -C github邮箱）
进入 .ssh目录，查看文件列表，查看 id_rsa.pub 文件内容 复制 id_rsa.pub 文件内容 ，登录 GitHub ，点击头像→Settings→SSH and GPG keys 点击 New SSH Key ，输入复制的密钥信息 切换到项目本地库中，修改文件内容并提交到本地库，查看只有基于HTTP的远程仓库地址别名  需要创建新远程地址别名（SSH地址类型） 推送文件并测试Finish：
设置本地库级别的签名：
这些是 Eclipse为管理创建工程而维护的文件，和开发代码没有关系，不需要在 Git中追踪，需要忽略
.classpath 文件.project 文件.settings 目录下所有文件为什么要忽略 Eclipse 特定文件？
同一团队中开发人员使用IDE可能不同，IDE不同时，相关工程特定文件可能不同如果这些文件加上版本控制，开发时可能需要给这些文件解决冲突如何忽略特定文件？
GitHub 官网忽略样式文件
https://github.com/github/gitignorehttps://github.com/github/gitignore/blob/master/Java.gitignore编辑本地忽略配置文件：
在用户系统根目录下，创建并配置 Java.gitignore 忽略文件在 ~ / .gitconfig 文件中引用忽略文件：[core] excludesfile = C:/Users/jiao/Java.gitignore登录 GitHub，复制要克隆的远程库的 HTTP地址，填入相关信息，选择要克隆的分支
选择克隆的远程库的保存目录（保存在Eclipse的工作区）
克隆成功，选择导入工作区的方式（ 只能选择 Import as general project ），并且设置工程名
导入工作区后，目录结构混乱没法使用，需要让 Eclipse识别该项目转换为Eclipse工程
右键项目 → Configure → Cornvert to Maven Project克隆操作的最后效果：
冲突解决：
后推送的工程需要执行拉取操作，将先推送的文件拉取到本地，出现文件冲突冲突解决：右键冲突文件 → Team → Merge Tool 工具解决冲突修改完成
public class Happy { public static void main(String[] args) { System.out.print("right ...."); System.out.print("left ...."); } }正常进行：右击项目 → Team → Add To Index 添加修改文件到暂存区 → commit 提交到本地库
再将冲突解决后的修改文件推送到远程库，推送成功
在新分支 hot_fix 上修改文件，提交到本地库并推送到远程库
推送**新分支上的文件到远程库，远程库新建分支 → 存储推送的新文件 **
在 ybq 的工程上，先执行 pull 拉取操作，然后切换分支，审核代码
选择 【Check out as New Local Branch】，成功切换到远程库的hot_fix新分支上 在hot_fix 分支上进行测试修改直到满意后，主工程切换回 master分支 本地进行合并分支操作（master分支合并hot_fix分支） 合并分支结果 合并成功后，把 master 推送到远程库中完成