标签：style http io color ar os 使用 sp 文件
2. Git help
Git help 获取git基本命令
（假设要知道某个特定命令的用法，比如：使用Git help clone，来获取git clone的用法）
3. Git本地操作基本命令
3.1. Git init
或者使用git init-db。
创建一个空的Git库。在当前文件夹中产生一个.git 的子文件夹。以后，全部的文件变化信息都会保存到这个文件夹下，而不像CVS那样，会在每一个文件夹和子文件夹下都创建一个CVS文件夹。
在.git文件夹下有一个config文件，能够改动当中的配置信息。
3.2. Git add
将当前工作文件夹中更改或者新增的文件增加到Git的索引中，增加到Git的索引中就表示记入了版本号历史中，这也是提交之前所须要运行的一步。
能够递归加入，即假设后面跟的是一个文件夹作为參数，则会递归加入整个文件夹中的全部子文件夹和文件。比如：
git add dir1 （ 加入dir1这个文件夹，文件夹下的全部文件都被加入 ）
Git add f1 f2 （ 加入f1，f2文件）
git add . ( 加入当前文件夹下的全部文件和子文件夹 )
3.3. Git rm
从当前的工作文件夹中和索引中删除文件。
能够递归删除，即假设后面跟的是一个文件夹做为參数，则会递归删除整个文件夹中的全部子文件夹和文件。比如：
git rm –r * （进入某个文件夹中，运行此语句，会删除该文件夹下的全部文件和子文件夹）
git rm f1 (删除文件f1，包括本地文件夹和index中的此文件记录)
git rm --ached f1 (删除文件f1，不会删除本地文件夹文件，仅仅删除index中的文件记录；将已经git add的文件remove到cache中,这样commit的时候不会提交这个文件, 适用于一下子加入了非常多文件, 却又想排除当中个别几个文件的情况.)
3.4. Git commit
提交当前工作文件夹的改动内容。
直接调用git commit命令，会提示填写凝视。通过例如以下方式在命令行就填写提交凝视：git commit -m "Initial commit of gittutor reposistory"。 注意，和CVS不同，git的提交凝视必须不能为空，否则就会提交失败。
git commit另一个 -a的參数，能够将那些没有通过git add标识的变化一并强行提交，可是不建议使用这样的方式。
每一次提交，git就会为全局代码建立一个唯一的commit标识代码，用户能够通过git reset命令恢复到随意一次提交时的代码。
git commit –-amend –m “message” （在一个commit id上不断改动提交的内容）
3.5. Git status
查看版本号库的状态。能够得知哪些文件发生了变化，哪些文件还没有加入到git库中等等。 建议每次commit前都要通过该命令确认库状态。
最常见的误操作是， 改动了一个文件， 没有调用git add通知git库该文件已经发生了变化就直接调用commit操作， 从而导致该文件并没有真正的提交。这时假设开发人员以为已经提交了该文件，就继续改动甚至删除这个文件，那么改动的内容就没有通过版本号管理起来。假设每次在 提交前，使用git status查看一下，就能够发现这样的错误。因此，假设调用了git status命令，一定要格外注意那些提示为 “Changed but not updated:”的文件。 这些文件都是与上次commit相比发生了变化，可是却没有通过git
add标识的文件。
3.6. Git log
查看历史日志，包括每次的版本号变化。每次版本号变化相应一个commit id。
Git log -1
-1的意思是仅仅显示一个commit，假设想显示5个，就-5。不指定的话，git log会从该commit一直往后显示。
Git log --stat –summary （显示每次版本号的具体变化）
在项目日志信息中，每条日志的首行（就是那一串字符）为版本号更新提交所进行的命名，我们能够将该命名理解为项目版本号号。项目版本号号应该是唯一的，默认由 Git 自己主动生成，用以标示项目的某一次更新。假设我们将项目版本号号用作git-show 命令的參数，就可以查看该次项目版本号的更新细节。比如：
1) Git log
2）Git show
实际上，上述命令并不是是真正的进行版本号号自己定义，仅仅是制造了一个tag对象而已，这在进行项目版本号对外公布时比較实用。
3.7. Git merge
把server上下载下来的代码和本地代码合并。或者进行分支合并。
比如：当前在master分支上，若想将分支dev上的合并到master上，则git merge dev
注意：git merge nov/eclair_eocket （是将servergit库的eclair_eocket分支合并到本地分支上）
git rebase nov/eclair_eocket （是将servergit库的eclair_eocket分支映射到本地的一个暂时分支上，然后将本地分支上的变化合并到这个暂时分支，然后再用这个暂时分支初始化本地分支）
3.8. Git diff
把本地的代码和index中的代码进行比較，或者是把index中的代码和本地仓库中的代码进行比較。
1） Git diff
比較工作文件夹和Index中的代码。
2） Git diff - - cached
比較index和本地仓库中的代码。
3.9. Git checkout
3.9.1. 切换到分支
1) 创建一个新分支，并切换到该分支上
Git checkout –b 新分支名
2）切换到某个已经建立的本地分支local_branch
Git checkout local_branch
（使用cat .git/HEAD后，显示refs:refs/heads/ local_branch）
3) 切换到server上的某个分支remote_branch
Git checkout remote_branch
（远程分支remote_branch能够通过 git branch –r 列出）
4) 切换到某个commit id
Git checkout commit_id
（使用cat .git/HEAD后，显示commit_id）
5) 切换到某个tag
Git checkout tag
（使用cat .git/HEAD后，显示tag）
注意： 除了1）和2）外，其余三种都仅仅是切换到了一个暂时的( no branch )状态 （this head is detached），这时用 git branch 能够看到处于（no branch）上， cat .git/HEAD 看到指向对应的commit id。 这个（no branch）仅仅是暂时存在的，并非一个真正建立的branch。 假设此时运行2），则这个（no branch）就自己主动消失了；假设运行1）， 则创建新分支 new branch，并把这个(no branch)挂到这个新分支上，此时cat
.git/refs/heads/new_branch 能够看到已经指向了刚才那个commit id。
3.9.2. 用已有分支初始化新分支
运行以下的命令，在切换到某个已经建立的local branch或者某个remote branch或者某个commit id 或者某个tag的同一时候，创建新分支new_branch，而且挂到这个新分支上。
1） 切换到某个已经建立的本地分支local_branch，而且使用此分支初始化一个新分支new_branch。
git checkout –b new_branch local_branch
2) 切换到某个远程分支remote_branch，而且用此分支初始化一个新分支new_branch。
Git checkout –b new_branch remote_branch
3) 切换到某个commit id，并建立新分支new_branch
Git checkout –b new_branch commit_id
4) 切换到某个tag，并建立新分支new_branch
Git checkout –b new_branch tag
3.9.3. 还原代码
比如 “git checkout app/model/user.rb” 就会将user.rb文件从上一个已提交的版本号中更新回来，未提交的工作文件夹中的内容所有会被覆盖。
3.10. Git-ls-files
查看当前的git库中有那些文件。
3.11. Git mv
重命名一个文件、文件夹或者链接。
比如：Git mv helloworld.c helloworld1.c （把文件helloworld.c 重命名为 helloworld1.c）
3.12. Git branch
3.12.1. 总述
在 git 版本号库中创建分支的成本差点儿为零，所以，不必吝啬多创建几个分支。当第一次运行git init时，系统就会创建一个名为“master”的分支。 而其他分支则通过手工创建。
以下列举一些常见的分支策略：
创建一个属于自己的个人工作分支，以避免对主分支 master 造成太多的干扰，也方便与他人交流协作；
当进行高风险的工作时，创建一个试验性的分支；
合并别人的工作的时候，最好是创建一个暂时的分支用来合并，合并完毕后再“fetch”到自己的分支。
对分支进行增、删、查等操作。
注意：分支信息一般在.git/refs/文件夹下，当中heads文件夹下为本地分支，remotes为相应server上的分支，tags为标签。
3.12.2. 查看分支
git branch 列出本地git库中的全部分支。在列出的分支中，若分支名前有*，则表示此分支为当前分支。
git branch –r 列出servergit库的全部分支。
（能够继续使用命令 “ git checkout -b 本地分支名 server分支名”来获取server上某个分支的代码文件）。
3.12.3. 查看当前在哪个分支上
cat .git/HEAD
3.12.4. 创建一个分支
1） git branch 分支名
尽管创建了分支，可是不会将当前工作分支切换到新创建的分支上，因此，还须要命令“git checkout 分支名” 来切换，
2） git checout –b 分支名
不但创建了分支，还将当前工作分支切换到了该分支上。
3.12.5. 切换到某个分支：git checkout 分支名
切换到主分支：git checkout master
3.12.6. 删除分支
git branch –D 分支名
注意： 删除后，发生在该分支的全部变化都无法恢复。强制删除此分支。
3.12.7. 比較两个分支上的文件的差别
git diff master 分支名 （比較主分支和还有一个分支的差别）
3.12.8. 查看分支历史
git-show-branch （查看当前分支的提交凝视及信息）
git-show-branch -all（查看全部分支的提交凝视及信息）比如：
* [dev] d2
! [master] m2
--
* [dev] d2
* [dev^] d1
* [dev~2] d0
*+ [master] m2
在上述样例中， “--”之上的两行表示有两个分支dev和master， 且dev分支上最后一次提交的日志是“d2”,master分支上最后一次提交的日志是 “m2”。 “--”之下的几行表示了分支演化的历史，当中 dev表示发生在dev分支上的最后一次提交，dev^表示发生在dev分支上的倒数第二次提交。dev~2表示发生在dev分支上的倒数第三次提交。
3.12.9. 查看当前分支的操作记录
git whatchanged
3.12.10. 合并分支
法一：
git merge “凝视” 合并的目标分支 合并的来源分支
假设合并有冲突，git会有提示。
比如：git checkout master （切换到master分支）
git merge HEAD dev~2 (合并master分支和dev~2分支)或者：git merge master dev~2
法二：
git pull 合并的目标分支 合并的来源分支
比如: git checkout master （切换到master分支）
git pull . dev~2（合并当前分支和dev~2分支）
3.13. Git rebase
一般在将server最新内容合并到本地时使用，比如：在版本号C时从server上获取内容到本地，改动了本地内容，此时想把本地改动的内容提交到server上；但发现server上的版本号已经变为G了，此时就须要先运行Git rebase，将server上的最新版本号合并到本地。比如：
用以下两幅图解释会比較清楚一些，rebase命令运行后，实际上是将分支点从C移到了G，这样分支也就具有了从C到G的功能。
3.14. Git reset
库的逆转与恢复除了用来进行一些废弃的研发代码的重置外，另一个关键的数据。比方我们从远程clone了一个代码库，在本地开发后，准备提交回远程。可是本地代码库在开发时，有功能性的commit，也有出于备份目的的commit等等。总之，commit的日志中有大量无用log，我们并不想把这些 log在提交回远程时也提交到库中。 因此，就要用到git reset。
git reset的概念比較复杂。它的命令形式：git reset [--mixed | --soft | --hard] [<commit-ish>]
命令的选项：
--mixed 这个是默认的选项。如git reset [--mixed] dev^(dev^的定义能够參见2.6.5)。它的作用仅是重置分支状态到dev1^, 可是却不改变不论什么工作文件的内容。即，从dev1^到dev1的全部文件变化都保留了，可是dev1^到dev1之间的全部commit日志都被清除了， 并且，发生变化的文件内容也没有通过git add标识，假设您要又一次commit，还须要对变化的文件做一次git add。 这样，commit后，就得到了一份很干净的提交记录。 （回退了index和仓库中的内容）
--soft相当于做了git reset –mixed，后，又对变化的文件做了git add。假设用了该选项， 就能够直接commit了。（回退了仓库中的内容）
--hard这个命令就会导致全部信息的回退， 包含文件内容。 一般仅仅有在重置废弃代码时，才用它。 运行后，文件内容也无法恢复回来了。（回退了工作文件夹、index和仓库中的内容）
比如：
切换到使用的分支上；
git reset HEAD^ 回退第一个记录
git reset HEAD~2 回退第二个记录
假设想把工作文件夹下的文件也回退，则使用git reset - - hard HEAD^ 回退第一个记录
git reset - - hard HEAD~2 回退第二个记录
还能够使用例如以下方法：
将当前的工作文件夹全然回滚到指定的版本号号，如果例如以下图，我们有A-G五次提交的版本号，当中C的版本号号是 bbaf6fb5060b4875b18ff9ff637ce118256d6f20，我们运行了‘git reset bbaf6fb5060b4875b18ff9ff637ce118256d6f20‘那么结果就仅仅剩下了A-C三个提交的版本号
3.15. Git revert
还原某次对版本号的改动，比如：git revert commit_id （当中commit_id为commit代码时生成的一个唯一表示的字符串）
比如：（3.6中）git revert dfb02e6e4f2f7b573337763e5c0013802e392818 （运行此操作，则还原上一次commit的操作）
3.16. Git config
利用这个命令能够新增、更改Git的各种设置，比如 “git config branch.master.remote origin” 就将master的远程版本号库设置为别名叫做origin版本号库。
3.17. Git show
显示对象的不同类型。
3.18. Git tag
创建、列出、删除或者验证一个标签对象（使用GPG签名的）。
能够将某个详细的版本号打上一个标签，这样就不须要记忆复杂的版本号号哈希值字符串了，比如你能够使用 “git tag revert_version bbaf6fb5060b4875b18ff9ff637ce118256d6f20” 来标记这个被你还原的版本号，那么以后你想查看该版本号时，就能够使用 revert_version标签名，而不是哈希值了。
4. Gitserver操作命令（与server交互）
4.1. Git clone
取出server的仓库的代码到本地建立的文件夹中（与server交互）
通过git clone获取远端git库后，.git/config中的开发人员信息不会被一起clone过来。仍然须要为本地库的.git/config文件加入开发人员信息。此外，开发人员还须要自己加入 . gitignore文件。
通过git clone获取的远端git库，仅仅包括了远端git库的当前工作分支。假设想获取其他分支信息，须要使用 “git branch –r” 来查看， 假设须要将远程的其他分支代码也获取过来，能够使用命令 “ git checkout -b 本地分支名 远程分支名”，当中，远程分支名为 “git branch –r” 所列出的分支名， 通常是诸如“origin/分支名”的样子。假设本地分支名已经存在， 则不须要“-b”參数。
比如：
4.2. Git pull
从server的仓库中获代替码，和本地代码合并。（与server交互，从server上下载最新代码，等同于： Git fetch + Git merge）
从其他的版本号库（既能够是远程的也能够是本地的）将代码更新到本地，比如：“git pull origin master ”就是将origin这个版本号库的代码更新到本地的master主分支。
git pull能够从随意一个git库获取某个分支的内容。使用方法例如以下：
git pull username@ipaddr:远端repository名远端分支名 本地分支名。这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。当中，假设不写本地分支名，则默认pull到本地当前分支。
须要注意的是，git pull也能够用来合并分支。 和git merge的作用同样。 因此，假设你的本地分支已经有内容，则git pull会合并这些文件，假设有冲突会报警。
比如：
4.3. Git push
将本地commit的代码更新到远程版本号库中，比如 “git push origin”就会将本地的代码更新到名为orgin的远程版本号库中。
git push和git pull正好想反，是将本地某个分支的内容提交到远端某个分支上。使用方法： git pushusername@ipaddr:远端repository名本地分支名 远端分支名。这条命令将本地git库的一个本地分支push到远端git库的远端分支名中。
须要格外注意的是，git push好像不会自己主动合并文件。因此，假设git push时，发生了冲突，就会被后push的文件内容强行覆盖，并且没有什么提示。 这在合作开发时是非常危急的事情。
比如：
4.4. Git fetch
从server的仓库中下载代码。（与server交互，从server上下载最新代码）
相当于从远程获取最新版本号到本地，不会自己主动merge，比Git pull更安全些。
使用此方法来获取server上的更新。
比如：假设使用git checkout nov/eclair_rocket （nov/eclair_rocket为server上的分支名），则是获取上次使用git fetch命令时从server上下载的代码；假设先使用 git fetch ，再使用git checkout nov/eclair_rocket，则是先从server上获取最新的更新信息，然后从server上下载最新的代码。
标签：style http io color ar os 使用 sp 文件
原文地址：http://www.cnblogs.com/gcczhongduan/p/4070883.html
