1.git安装：
mac 系统如果安装了xcode 默认安装了git
使用命令 git --verison 查看git版本
2.与远程GitHub连接
1.在GitHub官网使用邮箱注册 如 [email protected]
2.在mac上使用 ssh命令生成 ssh-key 秘钥（公钥和私钥）
命令 ssh-keygen -t rsa -C '[email protected]'
3.进入当前目录下的.ssh 目录查看生成的公钥和私钥
4.查看公钥 id_rsa.pub
5.将公钥内容拷贝并粘贴到GitHub网站中设置ssh中
6. 本地git全局配置（必须，否则使用 git commit 提交时会报错）：
git config --global user.email "[email protected]"
git config --global user.name "Your Name"
3.初始化本地仓库
新建目录 gitProject--->进入gitProject--->执行 git init-->目录中有多了一个 .git 文件
4.新建文件然后提交到仓库
git add 文件名称 --加入缓冲区
git add -f 文件名称 ----强制加入该文件
git commit -m "备注" --提交到版本库
使用命令：
git status --
告诉你有文件被修改过，
git diff --
可以查看修改内容。
git reset --hard HEAD^ -- 退回到上一版本
git reset 版本号前几位 --回退到指定版本
git reflog ---查看回到哪个版本
git add 将工作区内的文件 添加到暂存区
git commit 命令只负责将 暂存区的文件提交到版本库
git checkout -- readme.txt ---撤销修改
命令
git checkout -- readme.txt意思就是，把 readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是
readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是
readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态
git checkout -- file命令中的 --很重要，没有 --，就变成了“切换到另一个分支”的命令
git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区
从版本库中删除该文件，那就用命令
git rm
删掉，并且
git commit
远程仓库：
git remote add origin [email protected]:mybefly/myprojects.git ---本地仓库与远程仓库关联 origin 为远程仓库名称
git remote rm origin 删除远程库
git push -u origin master ---将本地master分支上的内容推送到远程 origin中
由于远程库是空的，我们第一次推送
master
分支时，加上了
-u
参数，
Git不但会把本地的
master
分支内容推送的远程新的
master
分支，还会把本地
的
master
分支和远程的
master
分支关联起来，在以后的推送或者拉取时就可以简化命令。
git push origin master ---本地做了修改 就可以将本地库推送到远程仓库中
本地无版本库克隆远程仓库到本地
git clone [email protected]:mybefly/gitskills.git
分支：
1.git commit 提交记录
2.git branch branchName 创建新的分支
3.git checkout branchName 切换到分支
4. git chekcout -b branchName 创建并切换到分支
5. git branch 查看当前分支 当前分支会带有 * 号
6. git branch -d branchName 删除分支
如何避免提交mac文件夹当中的 .DS_Store 文件？
解决：
1. 在当前目录下新建 .gitignore 文件
2.使用 vim或者其他方式打开 .gitignore 文件
3.
输入
.DS_Store
换行再输入
*/.DS_Store
（将你想忽略的文件或文件夹写上去）；
4. 保存文件并退出
5. git add .gitignore 添加该文件到暂存区
6. git commit 提交该文件到版本库
7.再次提交其他文件时 就不会报 Untracked files:.DS_Store 这个错误了
合并分支：
git merge branchName 合并分支到当前分支
1.gti rebase 非当前分支
2.切换当前分支到非当前分支 再次 git rebase
当合并出现冲突时如何解决：
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用
git log --graph命令可以看到分支合并图
git merge --no-ff -m "merge with no-ff" dev --
--no-ff参数，表示禁用 Fast forward
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
git log --graph --pretty=oneline --abbrev-commit 查看合并历史
临时存储当前工作，开辟新分支修复bug:
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场
git stash一下，然后去修复bug，修复后，再
git stash pop，回到工作现场。
强行删除分支：
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过
git branch -D <name>强行删除。
远程分支：
git remote 查看远程库
git remote -v 显示更详细的信息
git push origin dev 推送分支到远程库
哪些些需要推送到远程分支，那些不需要推送？？？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
git rebase ：
rebase操作可以把本地未push的分叉提交历史整理成直线；rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比
标签 git tag ：
git tag v0.9 版本号 ----无版本号时默认为当前 HEAD
git show tagName 查看标签信息
git tag -a v0.1 -m "version 0.1 released" 1094adb --创建带说明的标签
git tag ---查看所有便签
git tag -d tagName ----删除tag
git push origin tagName ---将本地创建的标签推送到远程
git push origin --tags ----一次性推送全部尚未推送的标签到远程
删除远程的标签：
1.删除本地标签 git tag -d tagName
2.使用push 命令删除远程标签 git push origin :refs/tags/tagName
配置文件 .gitignore 忽略不要提交的文件
写得有问题，需要找出来到底哪个规则写错了，可以用gitignoregit check-ignore命令检查
每个仓库的Git配置文件都放在.git/config文件中当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig
.gitignore 文件配置规则
推荐一个好的网站 git 命令运行后 可视化运行结果：
以下是在网站上学习的记录：
命令：HEAD ==head --分离出 headgit checkout C4(版本号)相对引用 ^ 符号：git checkout 版本号 ---移动 HEAD 到当前版本git checkout HEAD^ 移动到当前版本的上一个版本git checkout HEAD^ 移动到当前版本的上一个版本git checkout HEAD^ 移动到当前版本的上一个版本
相对引用2： ~ 符号一次性移动 多次 ~ numbers 当无number时 与 ^ 符号相同 向上移动一个版本
两个父节点：git checkout HEAD^2 移动到第二个父节点上面实际应用：强制修改分支位置你现在是相对引用的专家了，现在用它来做点实际事情。我使用相对引用最多的就是移动分支。可以直接使用-f选项让分支指向另一个提交。例如:git branch -f master HEAD~3上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交
移动分支：git checkout 版本号 将HEAD指向版本git checkout HEAD 移动分支到特定版本
撤销变更：git reset 本地撤销 git reset HEAD^ 或者 git reset HEAD~numbergit revert 撤销后远程分享整理提交：g it Cherry-pickgit cherry-pick 版本1 版本2 版本3 -----将不同分支下的版本 复制到 主干(master)上
提交技巧1：使用 git rebase -i 来将需要修改的版本提到最前端使用 git commi --amend 方法来修改版本使用 git reabse -i 来讲版本顺序更改提交技巧2：使用 git cherry-pick C2 将C2版本复制到master上使用 git commit --amend 命令修改C2版本使用 git cherry-pick C3 将原来的C3版本重新移动到master
为版本添加taggit tag v1 C1 版本C1添加tag v1git tag v1 默认给当前版本添加 tag 当前版本HEAD
多分支 rebase:git rebase master bugFixgit rebase bugFix sidegit rebase side anothergit another master----将所有分支都合并到了master纠缠的分支git branch -f three C2 直接将分支 Three 移动到版本C2
查看提交记录：git log
远程仓库：：git clone 地址 ---将远程仓库克隆到本地远程分支：名称规范<remote name>/<branch name>因此，如果你看到一个名为o/master的分支，那么这个分支就叫master，远程仓库的名称就是o大多数的开发人员会将它们主要的远程仓库命名为origin，并不是o。这是因为当你用git clone某个仓库时，Git 已经帮你把远程仓库的名称设置为origin了不过origin对于我们的 UI 来说太长了，因此不得不使用简写o:) 但是要记住, 当你使用真正的 Git 时, 你的远程仓库默认为origin!git chekcout origin/master ;git commit 会分离 HEAD到新提交的版本上
git fetch:Git 远程仓库相当的操作实际可以归纳为两点：向远程仓库传输数据以及从远程仓库获取数据。既然我们能与远程仓库同步，那么就可以分享任何能被 Git 管理的更新（因此可以分享代码、文件、想法、情书等等）。
本节课我们将学习如何从远程仓库获取数据 —— 命令如其名，它就是 git fetch。git fetch 做了些什么git fetch 完成了仅有的但是很重要的两步:从远程仓库下载本地仓库中缺失的提交记录更新远程分支指针(如 o/master)git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。
如果你还记得上一节课程中我们说过的，远程分支反映了远程仓库在你最后一次与它通信时的状态，git fetch 就是你与远程仓库通信的方式了！希望我说的够明白了，你已经了解 git fetch 与远程分支之间的关系了吧。
git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信。git fetch 不会做的事git fetch 并不会改变你本地仓库的状态。它不会更新你的 master 分支，也不会修改你磁盘上的文件。
理解这一点很重要，因为许多开发人员误以为执行了 git fetch 以后，他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来，但是并没有修改你本地的文件。我们在后面的课程中将会讲解能完成该操作的命令 :D
所以, 你可以将 git fetch 的理解为单纯的下载操作。
git pull:从远程仓库拉取更新到 origin/master并合并既然我们已经知道了如何用 git fetch 获取远程的数据, 现在我们学习如何将这些变化更新到我们的工作当中。
其实有很多方法的 —— 当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:git cherry-pick o/mastergit rebase o/mastergit merge o/master等等实际上，由于先抓取更新再合并到本地分支这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的 git pull。
模拟团队合作::git fakeTeamwork 分支名 版本个数 ---git fake Teamwork 2--在远程仓库默认分支提交两个版本
gti push：git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。
远程仓库提交偏离：假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。
这种情况下, git push 就不知道该如何操作了。如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，异或由于你的提交已经过时而直接忽略你的提交？
因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作。
使用 git pull --rebase 命令 更新本地仓库并合并代码 然后发布版本 git push
远程追踪：在前几节课程中有件事儿挺神奇的，Git 好像知道 master 与 o/master 是相关的。当然这些分支的名字是相似的，可能会让你觉得是依此将远程分支 master 和本地的 master 分支进行了关联。这种关联在以下两种情况下可以清楚地得到展示：pull 操作时, 提交记录会被先下载到 o/master 上，之后再合并到本地的 master 分支。隐含的合并目标由这个关联确定的。push 操作时, 我们把工作从 master 推到远程仓库中的 master 分支(同时会更新远程分支 o/master) 。这个推送的目的地也是由这种关联确定的！local branch "master" set to track remote branch "o/master"
有两种方法设置这个属性，第一种就是通过远程分支检出一个新的分支，执行:git checkout -b totallyNotMaster o/master就可以创建一个名为 totallyNotMaster 的分支，它跟踪远程分支 o/master。
第二种方法另一种设置远程追踪分支的方法就是使用：git branch -u 命令，执行：git branch -u o/master foo这样 foo 就会跟踪 o/master 了。如果当前就在 foo 分支上, 还可以省略 foo：git branch -u o/mastergit push 参数：：：git push <remote> <place>
更新远程仓库：
参数2 ：git origin master:newBranch
命令：git pull origin