Git工作常用命令整理

首先我们第一需要知道的是如何找到git的帮助文档，在git命令后面加上--help，例如我想知道git clone的帮助文档，那么就是git clone --help，或者在你的git安装目录里面的html/文件夹里面找吧。。

1. 初始化代码库
   1.1 在GitHub上面注册帐号
   1.2 New一个repository保存自己的代码
   如何理解repository
   一个帮你保存文件的目录仓库，并且保存你文件的修改记录
   1.3 填写你的repository基本属性，默认创建是public的，就是开源，如果选择不开源,需要money
   

   

   create repository
   
   1.4 这样我们就创建了一个属于我们的代码库！之后就是给代码库添加文件了！有两个方式一个是通过http，另一个是ssh，我们现在只说http，ssh的话，某度是个好东西。
   1.4.1 选择本地文件夹后初始化git仓库
   cd [direct]
   git init
   1.4.2 添加文件内容
   git add [文件名]
   git add --a //添加所有文件
   1.4.3 提交到本地commit
   git commit -m "first commit"
   1.4.4 链接到远程代码库并提交代码（如果已经链接到了远程代码库，那么remote这句可以省略）
   git remote add origin [仓库地址]
   git push -u origin master // 首次提交一定要添加origin master
   1.4.5 如果我们已经有了一个代码库，需要提交到我们新建的代码库
   git remote add origin [仓库地址]
   git push -u origin master

2. 下载代码库
   一般来说我们下载代码只需要clone命令就可以了，其它的参数要看需求，其它的参数使用默认的就可以了
   git clone [repository]

    //完整模式
    git clone [--template=]
    [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
    [-o ] [-b ] [-u ] [--reference ]
    [--separate-git-dir ]
    [--depth ] [--[no-]single-branch]
    [--recursive | --recurse-submodules] [--] 
    []
   

我们在工作的时候，一般都是协同工作的，那么问题来了，如果同事提交了代码，我们要如何更新，那就是从仓库更新代码，更新代码的命令是pull，负责把代码拉下来
git pull

    //完整模式
    git pull [options] [ […]]

3. 分支处理
   为了规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。企业级应用把分支分为以下几种master，developer，hotfix，release，feature

   

   代码分支管理

   3.1 master分支
   master和develop分支都是主分支，主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。
   master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。

   3.2 develop分支
   develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
   当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。

   3.3 release分支
   使用规范：
   可以从develop分支派生
   必须合并回develop分支和master分支
   分支命名惯例：release-*

   release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
   当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
   成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

   3.4 hotfix分支
   使用规范：
   可以从master分支派生
   必须合并回master分支和develop分支
   分支命名惯例：hotfix-*

   

   hotfix

   除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的 软件版本。当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要 从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

   3.5 feature分支
   使用规范：
   可以从develop分支发起feature分支
   代码必须合并回develop分支
   feature分支的命名可以使用除master，develop，release-，hotfix-之外的任何名称

   feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
   一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。

   

   feature

   3.6 Git代码
   查看分支
   【本地分支】git branch
   【查看所有分支】git branch -a
   【查看所有分支及其状态】git branch show origin

     //完整模式
    git branch [--color[=] | --no-color] [-r | -a]
    [--list] [-v [--abbrev= | --no-abbrev]]
    [--column[=] | --no-column]
    [(--merged | --no-merged | --contains) []] […]
    git branch [--set-upstream | --track | --no-track] [-l] [-f]  []
    git branch (--set-upstream-to= | -u ) []
    git branch --unset-upstream []
    git branch (-m | -M) [] 
    git branch (-d | -D) [-r] …
    git branch --edit-description []
   
    切换分支
    git checkout [br]
   
    //完整模式
    git checkout [-q] [-f] [-m] []
    git checkout [-q] [-f] [-m] --detach []
    git checkout [-q] [-f] [-m] [--detach] 
    git checkout [-q] [-f] [-m] [[-b|-B|--orphan] ] []
    git checkout [-f|--ours|--theirs|-m|--conflict=