Why Git?
绝大多数公司都是基于Git进行代码管理
绝大多数开源社区都是Git维护的
本地版本控制RCS
本地复制文件夹，不能团队协作。所以才有集中式版本控制
集中版本控制SVN
远端服务来保存文件，所有用户的提交都要提交到远端服务器。但是可能存在冲突。
适合大文件，美术团队。但是本地又不存储版本管理了，远端服务器故障容易导致历史版本的丢失。
分布式版本控制Git
每个库都有完整的提交历史，可以本地代码提交。每次都是快照提交而不是记录增量。分支管理强大。校验和机制可以保证完整性。分布式开发。但是比SVN复杂一些。它的作者就是Linus，因为BitKeeper不让他用了，团队用了两周写了个Git。Github代码托管，Gitlab开源代码托管，Gerrit是google开发的，Android托管在Gerrit。
Git基本命令
先做个初始化：
mkdir gitlearn
cd gitlearn
git init
配置一下吧：
global system local
git config --global user.name "jyh"
git config --global user.email jyh@jyh.com
查看remote 得先加上ssh和http
git remote -v
git remote add origin_ssh git@github.com:git/git.git
git remote add origin_http https://github.com/git/git.git
效果如下：
然后config下面也会有remote配置
再加一个origin吧
git remote add origin git@github.com:git/git.git
git remote set-url --add --push origin git@github.com:my_repo/git.git
git remote -v
下面是http remote的介绍
下面是SSH remote配置
然后可以ls发现有个y.pub cat y.pub一下
但是最终还是要代码提交的 提交有不同的提交方式如下：
Git Add(把文件加入暂存区） 执行git add .就可以
Git Commit(真正的提交到git的目录） 执行git commit -m"add readme"，此时objects目录中多了两个文件。
Git Clone & Pull & Fetch
- Clone
拉取完整的仓库代码到本地目录，可以指定分支，深度。
- Fetch（不清楚远端情况）
将远端的某些分支最新代码拉取到本地，不会执行merge操作，会修改refs。remote内的分支信息，如果需要和本地代码合并需要手动操作。
- Pull（清楚远端情况）
拉取远端分支，并和本地代码进行合并，操作等同于git fetch + git merge，也可以通过git pull --rebase 完成 git fetch + git rebase操作。可能存在冲突，需要解决。
Git Push
常用命令：
一般使用 git push origin master 命令。
冲突问题：
-
本地的commit 记录和远端 commit 不一致，会产生冲突，如
git commit --amendorgit rebase命令都有可能导致这个问题。 -
如果该分支只有自己使用，或者团队内确认可以修改历史，则可以通过
git push origin master -f来完成强制推送，一般不推荐主干分支执行该操作，正常都应该解决冲突后再进行推送。
集中式工作流vs分支管理工作流
集中式只依托于master分支进行研发（Gerrit 每个change通过review才能合并 强制代码评审 更丰富的权限功能 master是很整洁清晰的 但是容易冲突 多分支的支持有问题）
分支管理还有Git Flow/Github Flow/Gitlab Flow三种模式，第一种是早期的-分支很多。第二种是很不错的，只有主干和开发分支。规则简单，基于Pull Request 往主干分支中提交代码。下面有实操：
先选择团队的合作方式：
- owner 创建好仓库之后，其他用户通过
Fork的方式创建自己的仓库，并在fork的仓库上进行开发。 - owner 创建好仓库之后，统一给团队内成员
分配权限，直接在同一个仓库内进行开发。（内部）
注意想用git clone必须得
想要push上去：必须三板斧：(这是main分支）
vim readme.md
git add .
git commit -m "add readme"
git push origin main
想加个新分支：用：
git checkout -b feature
修改readme.md然后还是三板斧push上去 但是是update push到feature
然后这个feature分支就上去了 如下图所示：
但是此时的main分支：也即是现在GitDemo的主页面的代码 是并没有更改的 因为我们并没有把feature分支的代码merge进来，那么去哪里merge呢？找到pull requests：然后new一个
我们就可以看到下面的界面 可以讨论 可以merge 可以加入代码审查 可以查看更改内容，非常方便了
最后全弄完之后，你发现这个feature是可以merge的 就可以merge了，成功后是基佬紫色如下：
然后之后也可以保护分支一下。就可以了。
讲一下gitlab flow
