1.克隆现有仓库

    2.创建一个新的本地仓库

    本地修改

    1.查看工作目录中已更改的文件,即查看git状态

    1. git status

    2.查看跟踪文件的更改,即远程仓库与本地仓库文件的不同

    1. git diff

    3.将所有当前更改添加到下一次提交,即全部提交

    1. git add .

    4.将某个文件的更改添加到下一次提交,即部分提交

    1. git add -p <file>

    5.提交跟踪文件中的所有本地更改

    1. git commit -a

    6.提交先前进行的更改

    1. git commit

    7.更改最后一次提交(不要修改已发布的提交)

    1. git commit --amend

    提交历史

    1.显示所有提交,从最新的提交开始

    1. git log

    2.显示特定文件随时间的修改

    1. git log -p <file>

    3.查看特定文件什么时间被什么人修改了什么内容

    1. git blame <file>

    分支和标签

    1.列出所有现有分支

      2.切换当前分支

      3.基于当前head指针创建新分支

      1. git branch <new-branch>

      4.基于当前远程分支创建一个新跟踪分支

      1. git checkout --track <remote/branch>

      5.删除一个本地分支

      1. git branch -d <branch>

      6.将一次提交标记为一个标签

      1.列出当前仓库关联的所有远程仓库

      1. git remote -v

      2.显示远程仓库的详细信息

      1. git remote show <remote>

      3.关联一个新的远程仓库到本地仓库

      1. git remote add <shortname> <url>

      4.仅拉取远程仓库所有更改,不合并到本地仓库

      1. git fetch <remote>

      5.拉取远程仓库所有更改,并合并到本地仓库

      1. git pull <remote> <branch>

      6.推送本地仓库修改到远程仓库

      1. git push <remote> <branch>

      7.删除远程仓库的一个分支

      1. git branch -dr <remote/branch>

      8.推送所有本地仓库标签到远程仓库

      1. git push --tags

      1.合并指定分支到当前分支

      2.变基

        3.放弃变基

        1. git rebase --abort

        4.解决冲突之后继续变基

        1. git rebase --continue

        5.运行合并冲突解决工具来解决合并冲突

        1. git mergetool
        2. # 合并冲突解决工具需要配置,是图形化工具

        6.使用编辑器手动解决冲突,并(在解决之后)将文件标记为已解决

        1. git add <resolved-file>

        撤销

        1.放弃工作目录中的所有本地更改

        1. git reset --hard HEAD

        2.放弃特定文件中的本地更改

        1. git checkout HEAD <file>

        3.还原提交

        1. git revert <commit>

        4.将你的HEAD指针重置为上一次提交…并放弃此后的所有更改

        1. git reset --hard <commit>

        5….并将所有更改保留为未提交的更改

        1. git reset <commit>
        1. git reset --keep <commit>

        版本控制最佳做法

        提交相关更改

        提交应该是相关更改的封装。 例如,修复两个不同的BUG应产生两个单独的提交。 较小的提交可使其他开发人员更容易理解更改,并在出现问题时将其回滚。 借助暂存区和仅暂存文件部分的能力等工具,Git可以轻松创建非常精细的提交。

        经常提交

        经常提交会使你的提交变小,并且帮助你仅提交相关的更改。 而且,它使你可以更频繁地与他人共享代码。 这样,每个人都可以更轻松地定期同步整合代码更改,并避免合并冲突。 相比之下,很少的大量提交和共享代码,会导致很难解决冲突。

        不要提交未完成的代码

        你应该只能在代码完成后提交。 但这并不意味着你在提交之前必须先完成一个完整的大型功能。 恰恰相反:将功能的实现分成逻辑块,并记住要尽可能早的频繁的提交。 但是,不要只想在一天结束离开办公室之前在仓库中提交一些代码。 如果你只是因为需要干净的工作区(切换分支,同步更改等)而打算提交未完成的代码,请考虑改用git stash

        在你还没有确认工作完成之前,忍住提交代码的冲动。彻底的测试代码,确保其没有副作用(据我们所知),虽然在本地存储库中提交半生不熟的东西只需要你原谅自己,但是当涉及到向他人推送/共享代码时,测试代码就更加重要了。

        写”好”的提交注释

        提交注释的开头应该要用简短的总结语句(最多50个字符最为开头总结),后续正文与开头用空白行分开。注释的正文应该包含下面问题的详细答案: 本次修改代码的原因是什么? 本次代码与之前的实现有何不同?

        版本控制不是备份系统

        在远程服务器上备份文件是版本控制系统的一个很好的副作用。但是你不应该把你的VCS(版本控制系统)当成一个备份系统来使用。在进行版本控制时,你应该注意语义上的提交(参见相关章节)——你不应该只是填入文件。

        多使用分支

        分支是Git最强大的功能之一,这并非偶然,因为从Git创建的第一天开始快速简单的分支就是它的中心要求。分支是帮助你避免混淆不同开发线的完美工具。你应该在开发工作流中广泛使用分支,例如,增加一个新的功能;修复BUG,新的想法等。

        商定工作流程

        Git允许你从许多不同的工作流中进行选择:长时间运行的分支、主题分支、合并或变基、git流……你选择哪一个取决于几个因素:你的项目、你的整体开发和部署工作流程,以及(可能最重要的)你和你的队友的个人偏好。无论你选择如何工作,只要确保大家都同意一个通用的工作流程就可以了。

        在命令行获取帮助

          免费在线资源

          http://rogerdudler.github.io/git-guide/index.zh.html速查词典 - 图2open in new window