选一个合适的文件夹(不一定要非空)
为什么git添加文件需要add, commit两步呢?
因为commit可以一次提交很多文件，所以你可以多次add不同的文件
如果文件修改了还没git add, 则会撤销这次修改
如果文件已经git add了, 然后又修改了, 则会回到add之后修改之前的版本
现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令
git checkout -b feature1 # 准备新的feature1分支
git add readme.txt # 修改readme.md并在feature1分支上提交
git commit -m “add_feature1”
git checkout master # 切换到master
git add readme.txt # 在master分支上修改文件并提交
git commit -m “add_master”
现在master分支和feature1分支都有了各自的新的提交
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
可以看出, 不使用fast forward模式, merge后就像这样:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wKBinZdK-1610182303634)(https://ooo.0o0.ooo/2017/03/16/58ca0c3c0076b.png)]
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OCl65D4z-1610182303635)(https://ooo.0o0.ooo/2017/03/16/58ca0c6f7fde4.png)]
pass
Feature分支
阅读: 229523
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
于是准备开发：
5分钟后，开发完毕：
切回dev，准备合并：
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是，
就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，但是这个分支还是必须就地销毁：
销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用命令git branch -D feature-vulcan。
成功删除
多人协作的工作模式通常是这样：
-
首先，可以试图用git push origin branch-name推送自己的修改；
-
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
-
如果合并有冲突，则解决冲突，并在本地提交；
-
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
-
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
git config --global color.ui true # 让git显示颜色
在.gitignore文件中加上不想推送的文件类型