Github
Shadowsocks翻墙神器
仓库（Repository）
仓库即你的项目，想在github上开源一个项目就必须新建一个Repository，如果开源的项目多了，就有了多个Repository
复制克隆项目（Fork）
李四fork张三仓库，则克隆一个一模一样的张三的项目，且该fork项目是独立存在的
发起请求（pull request）
如果李四更新一个a1.php文件，同时发送请求给张三。张三查看后觉得不错会合并到原仓库中
关注（watch）
关注一个项目，只要这个项目有任何更新都会第一时间收到这个项目的通知提醒
事务卡片（issue）
发现bug需要讨论
github说明图
搭建个人网站
点击new repository，名称必须是用户名+github.io
创建一个index.html文件，即可有个人主页
项目站点
https://用户名.github.io/仓库名
Git
Git Repository（Git仓库）（提交区）
最终确定的文件保存到仓库，成为一个新版本，并对别人可见
暂存区
暂存已经修改的文件最后统一提交到git仓库中
工作区（工作目录）
添加、编辑、修改文件等动作
基本信息设置
git config --list查看所有配置信息
初始化仓库
git init ——生成.git文件
向仓库中添加文件
touch a1.java——创建一个文件
git add a1.java——添加文件到暂存区，添加所有文件git add .
git commit -m ‘add a1.java’——提交文件到仓库
配置忽略文件
如果调用 git add .则会添加所有文件，可以配置.gitignore配忽略匹配文件
修改仓库
vi a1.java——修改文件
cat a1.java——查看文件
git status——查看状态
git add a1.java——修改文件到暂存区
git commit -m ‘提交修改的项目’——提交到仓库
删除文件
git rm --cached——仅从暂存区删除
git rm a1.java——从暂存区与工作目录中删除文件
git commit -m ‘通过git删除仓库文件’——提交
查看历史信息
git log——查看提交信息
git log --online——简化信息
显示版本差异
git diff
将文件内容从暂存区复制到工作目录
git checkout – file
撤销暂存区内容
撤销全部改动
总结一下
Git克隆操作
将远程仓库中的项目复制到本地
git clone 仓库地址 —— 仓库地址
克隆之后同样是add到暂存，然后commit提交到仓库，最后push到远程仓库:
Git推送
git push
实际项目开发中分支的概念和用法
如果线上发现bug，则创建hotfix分支进行修复，并合并回development分支
分支操作
git checkout 分支切换
假设场景下的各步命令（连续的步骤，关键看head在谁的上面，箭头是指针）：
注意下图git commit是从c4006ec到5751363
回到master分支
*是当前所属分支
此时分支没有任何变化
git reset 回退分支
git reset --mixed e39d0b3，该命令会将数据恢复到暂存区
git reset --hard e39d0b3，该命令会将数据恢复到暂存区和工作区
git reset --soft e39d0b3，该命令不会将数据恢复到暂存区和工作区，那1f2f476分支就丢失了
每次使用分支的hash号很麻烦，可以使用捷径：
reset和checkout区别
需要注意的是，前面提到的分支操作都是commit操作，而reset和checkout还可以对文件进行file操作
注意第三列，是否移动HEAD或branch。file操作是都不会移动HEAD和branch的。
checkout是不会改变分支的，只会对HEAD进行移动。在file操作中，reset修改的是暂存区，checkout修改的是工作目录。
checkout会遇到当前工作目录还未提交，无法切换分支的error，因此需要stash
git stash
从stash中删除用stash drop
git merge 合并分支
当前场景，最终提交节点为c4fe238
通过下面命令可以看到merge后的分支关系
merge会产生冲突，例如下图是test.md
并不是每个merge都会有冲突，下图就不会有冲突
通过下面合并可以发现是一个线性合并
但是我们不希望这样（不希望fast forward快速向前合并），我们希望知道在哪里merge了master分支，添加–no-ff参数
这样就跟普通的merge相同了
git rebase
注意这张变基后的图
例如以下场景
首先rebasehi找到以下三个节点
之后rebase会找到共同节点c400和两个分支节点c4f和042之间的提交记录，让这个提交在master分支上重演！
注意下面HEAD和feature分支的变化
这样提交的历史就变成线性，因为feature分支上的每一步都是线性的和master合并，从而得到最终的feature分支
还可以选择feature分支中的单独一个部分重演，例如让575以后分支在master上重演
这样红色的575就被抛弃
rebase和merge区别，merge可以很清楚的看到分支的合并情况。
千万不要在master分支上使用rebase
git tag
资料
