Git诞生11年后，BitKeeper宣布开源，十年前，BitKeeper 因作为 Linux Kernel 的源代码管理系统而闻名。不过由于其为商业软件，后来 Linus Torvalds 受其启发开发了 Git 来管理内核源代码。最近，BitKeeper 宣布以 Apache 2.0 许可发布其源代码，可谓姗姗来迟。

1. 创建本地仓库
   git init --bare shared.git（或者直接git init）
2. 配置个人信息
   git config user.name "yourName"
git config user.email "your@gmail.com"
   或者
   git config --global user.name "yourName"
git config --global user.email "your@gmail.com"
3. 复制仓库到本地
   git clone /f/software/repository/git/shared.git/ .(注意点代表当前目录)
   或者
   git clone git@github.com:challengeof/challengeof.github.io.git
   或者
   git clone https://github.com/challengeof/challengeof.github.io.git
4. 未提交
   git diff readme.txt （diff --> difference）
   • 【使用时机，修改readme.txt，但还没有准备提交(还未add commit)，想看看此次修改和上次提交的区别】
5. 提交后
   git diff HEAD -- readme.txt
   • 命令可以查看工作区和版本库里面最新版本的区别
6. 查看历史
   git log
   • 可以查看提交历史，以便确定要回退到哪个版本
7. 重返未来
   git reflog
   • 查看命令历史，以便确定要回到未来的哪个版本
8. 撤销操作
   git checkout -f
   • 撤销全部
     git checkout -- readme.txt
   • 撤销readme.txt文件，–很重要，不然就切换到另一个分支了，一种是readme.txt自修改后还没有被放到暂存区，
     现在，撤销修改就回到和版本库一模一样的状态；(还不如再次git pull一次或者 直接vim readme.txt)【改变的是工作区内容】
     一种是readme.txt已经添加到暂存区后，又在工作区作了修改xx ，现在，撤销修改就回到 刚刚git add到暂存区时的状态，暂存区还在。
9. 创建分支
   git checkout -b dev
   • 创建dev分支并切换到该分支。相当于执行了:
     git branch dev
git checkout dev
10. 合并和删除分支
    git merge dev
    • 假设当前分支是master，merge dev,把dev分支合并到当前分支（默认是Fast-forward快进模式 也就是直接把master指向dev的当前提交，所以合并速度非常快。）
      git branch -d dev
    • 删除dev分支，-D 为强制删除。

11. 合并分支造成的冲突

    • 例子:
      master分支
      git add a.jsp git commit a.jsp -m "the content is a"
      dev分支
      git add a.jsp git commit a.jsp -m "the content is aaaa"
      合并分支
      git merge dev// 冲突产生，两分支同时修改了一行 , git status查看 冲突的文件
      修改冲突:
      vim a.jsp git add a.jsp git commit -m "conflict fixed" (commit不加文件名哦)
      查看分支合并情况
      git log --graph --pretty=oneline --abbrev-commit
      删除分支 git branch -d dev
      git branch -d dev
      查看分支合并图
      git log --graph
      合并分支 续
      git merge dev(快进模式) git merge --no-ff -m "merge with no-ff" dev
      查看分支历史
      git log --graph --pretty=oneline --abbrev-commit
      合并分支时，加上–no-ff
      参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward
      合并就看不出来曾经做过合并。

12. 标签
    git tag v1.0

    • 标签就是快照，在当前最新commit上打了一个快照，或者针对 某个commit id 打标签。
      git tag v1.0 622222(622222是commit id)。
    • 查看标签列表
      git tag
    • 查看标签信息
      git show v1.0(git show )
    • 创建带有说明的标签
      git tag -a v1.0 -m "version1.0的标签" 6222222
    • 操作标签
      git tag -d v1.0删除标签 (因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。)
      git push origin v1.0 (git push origin <tagname>推送某个标签 到远程仓库。
      git push origin --tags //推送本地所有为推送的 标签到远程
      git tag -d v1.0 git push origin :refs/tags/v1.0删除已经推送到远程的标签，注意格式。
      git config --global color.ui true Git显示颜色，会让命令输出看起来更醒目。
13. 推送分支
    git push origin master 指定本地分支 master->远程master。
    git push origin dev 指定本地分支 dev ->远程 dev
    git checkout -b dev origin/dev 我需要在dev分支上开发，就必须创建远程origin的dev分支到本地
14. 其他
    git pull 拉去远程分支代码。
    git remote -v 查看远程库信息。

    注意事项

• 从本地推送分支，使用git push origin branch-name
  ，如果推送失败，先用git pull
  抓取远程的新提交。
• 本地新建的分支如果不推送到远程，对其他人就是不可见的。
• git pull命令，不能在同一个用户下面git pull得到自己刚刚提交的，会提示当前文件已经是最新的，pull 不下来。
• 直接在远程客户端 web上面更新a 文件，在电脑上面就可以git pull得到刚刚更新的代码。
• 不同的用户目录(本地仓库如user1，user2)默认都有一个master分支。
• git checkout
  其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
• github 上面 的 pull request用于你fork了别人的项目，然后修改fork后的代码，想提交到 别人的项目里面，就需要点击 pull request。
• 研究发现，如APPdemo文件夹下，git init 初始化本地仓库
  git add ,git commit,都是在当前文件夹下面进行的
  只有git push推送到远程仓库(或者本机其他目录下的仓库中[也算远程仓库，只不过是离线的远程仓库])。前提是需要关联本地仓库与远程仓库
  git clone 命令的时候，默认会做一次关联，如果没有关联的话，需要我们手动关联。
• 但是不管远程仓库(net) 远程仓库(本机)，本地仓库(某一个文件夹)本质上都是仓库。
• 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成，master分支是主分支，因此要时刻与远程同步；
  dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，
  除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
  标签是为了打上版本号信息，当然不能乱叫，通常用：v1.0, v1.1, v2.0 …或者按发布日期：build-20160503, build-20160504 …
  如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。
  如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。
  有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status
  都会显示Untracked files …，有强迫症的童鞋心里肯定不爽。好在Git考虑到了大家的感受，这个问题解决起来也很简单，
  在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。不需要从头写.gitignore
  文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
  如忽略
  Python编译产生的.pyc
  、.pyo
  、dist
  等文件或目录：
  // 「#」 是注释 通配符
  「#」 Python: .py[cod]
  .so .egg
  git 工作区 和暂存区 各个分支用的是同一个，仅仅提交的时候由于指针指的地方不同，令我们感觉似乎在不同区间上面工作，
  且git限定我们 工作区间被修改(如 index.jsp 被修改或被git add但是未 commit) 此时 git是不允许git checkout （切换分支的）
  注意关联远程仓库和关联远程分支
  关联远程仓库
  git remote add origin git@github.com:challengeof、challengeof.github.io.git
  关联远程分支
  git branch --set-upstream dev origin/dev

技巧篇

• 漂亮的log界面
  git config --global alias.lg "log --color --graph --pretty=format: '%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
• 最近一次提交
  git config --global alias.last 'log -1'//等价 git log -1
• 配置文件
  配置Git的时候，加上–global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
  配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中
  cat .git/config
• 难点篇
  当你接到一个修复一个bug的任务时,创建一个分支issue-101来修复它，但是当前正在dev上进行的工作只进行到一半,还没法提交，
  但是此时 必须在两个小时内修复该bug，怎么办？
  Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。
  使用git stash就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，
  所以你可以放心的修 Bug，等到修完Bug，提交到服务器上后，再使用git stash apply将以前一半的工作 应用回来。
  也许有的人会说，那我可不可以多次将未提交的代码压入到栈中？答案是可以的。当你多次使用’git stash’命令后，你的栈里将充满了未提交的代码，
  这时候你会对将哪个版本应用回来有些困惑，git stash list命令可以将当前的Git栈信息打印出来，你只需要将找到对应的版本号，
  例如使用git stash apply stash@{1}就可以将你指定版本号为stash@{1}的工作取出来，当你将所有的栈都应用回来的时候，
  可以使用git stash clear来将栈清空。在这里顺便提下git format-patch -n, n是具体某个数字。
  例如 git format-patch -1 这时便会根据log生成一个对应的补丁，如果 ‘git format-patch -2’ 那么便会生成2个补丁，当然前提是你的
  log上有至少有两个记录。
  看过上面的信息，就可以知道使用场合了：当前工作区内容已被修改，但是并未完成。这时Boss来了，说前面的分支上面有一个Bug，需要立即修复。
  可是我又不想提交目前的修改，因为修改没有完成。但是，不提交的话，又没有办法checkout到前面的分支。此时用Git Stash就相当于备份工作区了。
  然后在Checkout过去修改，就能够达到保存当前工作区，并及时恢复的作用。