git使用

win10+VS2015

1. 安装Git-2.6.3-64-bit.exe

2. 远程已设置ssh

3.获取远程代码

p.s. "[*]"表示要替换的内容，"[]"这个不要不要的 

 打开要下载代码的路径，右键"git bash here"

 

 "git clone [ssh.url]"

 显示“100% done”表示克隆完成

 "cd [路径]"  //进入代码根目录显示“master”  表示你本地的master主

 "git branch" //查看本地分支

 "git checkout -b [分支名称]" //创建新分支 并切换到新分支

 "git branch -a" //查看所有分支

 

"git status -s" 查看当前修改

"git add [文件路径]" //加文件到暂存区

"git commint" 提交

"git commint - " 加注册提交

"git push -u origin master":

把本地库的内容推送到远程，使用 git push命令，实际上是把当前分支master推送到远程。

由于远程库是空的，我们第一次推送master分支时，加上了 –u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。推送成功后，可以立刻在github页面中看到远程库的内容已经和本地一模一样了，

 

从现在起，只要本地作了提交，就可以通过如下命令：
"git push origin master"
把本地master分支的最新修改推送到github上了，现在你就拥有了真正的分布式版本库了。

 

git add:

git add * git会自动把你当前目录所有修改过的文件添加
git add . Git会递归地将你执行命令时所在的目录中的所有文件添加上去，所以如果你将当前的工作目录作为参数，它就会追踪那儿的所有文件

 一、前言
git add命令主要用于把我们要提交的文件的信息添加到索引库中。当我们使用git commit时，git将依据索引库中的内容来进行文件的提交。
二、基本
git add <path>表示 add to index only files created or modified and not those deleted 
我通常是通过git add <path>的形式把我们<path>添加到索引库中，<path>可以是文件也可以是目录。
git不仅能判断出<path>中，修改（不包括已删除）的文件，还能判断出新添的文件，并把它们的信息添加到索引库中。
三、git add -u
git add -u 表示 add to index only files modified or deleted and not those created 
git add -u [<path>]: 把<path>中所有tracked文件中被修改过或已删除文件的信息添加到索引库。它不会处理untracted的文件。
省略<path>表示.,即当前目录。
四、git add -A
git add -A: [<path>]表示把<path>中所有tracked文件中被修改过或已删除文件和所有untracted的文件信息添加到索引库。

省略<path>表示.,即当前目录。
五、git add -i
我们可以通过git add -i [<path>]命令查看<path>中被所有修改过或已删除文件但没有提交的文件，
并通过其revert子命令可以查看<path>中所有untracted的文件，同时进入一个子命令系统。
比如：
 git add -i
           staged     unstaged path
  1:        +0/-0      nothing branch/t.txt
  2:        +0/-0      nothing branch/t2.txt
  3:    unchanged        +1/-0 readme.txt
*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now>
这里的t.txt和t2.txt表示已经被执行了git add，待提交。即已经添加到索引库中。
readme.txt表示已经处于tracked下，它被修改了，但是还没有被执行了git add。即还没添加到索引库中。
5.1、revert子命令
可以通过git add -i的revert子命令（3: [r]evert）把已经添加到索引库中的文件从索引库中剔除。
（3: [r]evert）表示通过3或r或revert加回车执行该命令。执行该命令后，git会例出索引库中的文件列表.
然后通过数字来选择。输入"1"表示git会例出索引库中的文件列表中的第1个文件。
"1-15"表示git会例出索引库中的文件列表中的第1个文件到第15个文件.回车将执行。
如果我们不输入任何东西，直接回车，将结束revert子命令，返回git add -i的主命令行。
5.2、update子命令
可以通过update子命令（2: [u]pdate）把已经tracked的文件添加到索引库中。其操作和revert子命令类似。
5.3、add untracked子命令
通过add untracked子命令（4: [a]dd untracked）可以把还没被git管理的文件添加到索引库中。其操作和revert子命令类似。
5.4、diff子命令
可以通过diff子命令（6: [d]iff）可以比较索引库中文件和原版本的差异。其操作和revert子命令类似。
5.5、status子命令
status子命令(1: [s]tatus)功能上和git add -i相似
5.6、quit子命令
quit子命令（7: [q]uit）用于退出git add -i命令系统
六、帮助
我们可以通过git add -h命令来看git add命令的帮助文档。
 git add -h
usage: git add [options] [--] <filepattern>...
    -n, --dry-run         dry run
    -v, --verbose         be verbose
    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively 
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run

 

 

创建分支： $ git branch mybranch 切换分支： $ git checkout mybranch 创建并切换分支： $ git checkout -b mybranch

更新master主线上的东西到该分支上：$git rebase master

切换到master分支：$git checkout master

更新mybranch分支上的东西到master上：$git rebase mybranch

提交：git commit -a

对最近一次commit的进行修改：git commit -a –amend

commit之后，如果想撤销最近一次提交(即退回到上一次版本)并本地保留代码：git reset HEAD^

合并分支：(merge from) $ git checkout master $ git merge mybranch (merge from mybranch)

删除分支： $ git branch -d mybranch

强制删除分支： $ git branch -D mybranch

列出所有分支： $ git branch

查看各个分支最后一次提交： $ git branch -v

查看哪些分支合并入当前分支： $ git branch –merged

查看哪些分支未合并入当前分支： $ git branch –no-merged

更新远程库到本地： $ git fetch origin

推送分支： $ git push origin mybranch

取远程分支合并到本地： $ git merge origin/mybranch

取远程分支并分化一个新分支： $ git checkout -b mybranch origin/mybranch

删除远程分支：　$ git push origin :mybranch

rebase: $ git checkout mybranch

$ git rebase master (rebase from master)

举例： $ git checkout server

$ git rebase –onto master server client $ git checkout master $ git merge client (fostforward) $ git rebase master server (checkout sever) $ git merge server $ git branch -d client $ git branch -d server

 

#查看本地分支

git branch

#查看远程分支

git branch -a

#创建分支

git branch 分支名

#切换分支

git checkout 分支名

#删除本地分支

git branch -d 分支名

#删除远程分支

git push origin :远程分支名程

（号前面的空格不能少，原理是把一个空分支push到server上，相当于删除该分支。）

备注

今天删除本地分支 git branch -d XX 提示:  the branch  XXX is not fully merged 原因：XXX分支有没有合并到当前分支的内容

解决方法：使用大写的D 强制删除  git branch -D XXX  

另外不能删除当钱checkout 的分支 其它：删除远程分支 需要切换到其它分支之后删除当前分支

否则会：error:cannot delete the branch 'XXX' which you are currently on

 

删除远程分支后，使用 git branch -a依然可以看到相应分支名

使用  git fetch -p

原因是有跟踪

 

假定远端库名为 origin, 你要比较的本地分支为 test, 远端分支为 xxx

1 2 3 4 5

# 获取远端库最新信息 $ git fetch origin   # 做diff $ git diff test origin/xxx

 

 

P.s.

 1. 第一次从本地分支push到运程分支时 报如下错误

$ git push origin dev-2016:xxtest
To git@gitlab.**********
 ! [rejected]        dev-2016 -> xxtest(non-fast-forward)
error: failed to push some refs to 'git@gitlab.**********. git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

解决办法：

$ git pull origin xxtest

然后再push就OK了。

 1. 尽量不要省略 地址写完成

git pull	git pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。它的完整格式稍稍有点复杂。 $ git pull <远程主机名> <远程分支名>:<本地分支名> 比如，取回origin主机的next分支，与本地的master分支合并，需要写成下面这样。 $ git pull origin next:master 如果远程分支是与当前分支合并，则冒号后面的部分可以省略。 $ git pull origin next 上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。 $ git fetch origin $ git merge origin/next 在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动”追踪”origin/master分支。 Git也允许手动建立追踪关系。 git branch --set-upstream master origin/next 上面命令指定master分支追踪origin/next分支。 如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。 $ git pull origin 上面命令表示，本地的当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。 $ git pull 上面命令表示，当前分支自动与唯一一个追踪分支进行合并。 如果合并需要采用rebase模式，可以使用–rebase选项。 $ git pull --rebase <远程主机名> <远程分支名>:<本地分支名>
git push	git push命令用于将本地分支的更新，推送到远程主机。它的格式与git pull命令相仿。 $ git push <远程主机名> <本地分支名>:<远程分支名> 注意，分支推送顺序的写法是<来源地>:<目的地>，所以git pull是<远程分支>:<本地分支>，而git push是<本地分支>:<远程分支>。 如果省略远程分支名，则表示将本地分支推送与之存在”追踪关系”的远程分支(通常两者同名)，如果该远程分支不存在，则会被新建。 $ git push origin master 上面命令表示，将本地的master分支推送到origin主机的master分支。如果后者不存在，则会被新建。 如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。 $ git push origin :master # 等同于 $ git push origin --delete master 上面命令表示删除origin主机的master分支。 如果当前分支与远程分支之间存在追踪关系，则本地分支和远程分支都可以省略。 $ git push origin 上面命令表示，将当前分支推送到origin主机的对应分支。 如果当前分支只有一个追踪分支，那么主机名都可以省略。 $ git push 如果当前分支与多个主机存在追踪关系，则可以使用-u选项指定一个默认主机，这样后面就可以不加任何参数使用git push。 $ git push -u origin master 上面命令将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了。 不带任何参数的git push，默认只推送当前分支，这叫做simple方式。此外，还有一种matching方式，会推送所有有对应的远程分支的本地分支。Git 2.0版本之前，默认采用matching方法，现在改为默认采用simple方式。如果要修改这个设置，可以采用git config命令。 $ git config --global push.default matching # 或者 $ git config --global push.default simple 还有一种情况，就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要使用–all选项。 $ git push --all origin 上面命令表示，将所有本地分支都推送到origin主机。 如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做git pull合并差异，然后再推送到远程主机。这时，如果你一定要推送，可以使用–force选项。 $ git push --force origin 上面命令使用–force选项，结果导致在远程主机产生一个”非直进式”的合并(non-fast-forward merge)。除非你很确定要这样做，否则应该尽量避免使用–force选项。 最后，git push不会推送标签(tag)，除非使用–tags选项。 $ git push origin --tags
git branch

 

 本地文件上传到git服务器 

1. New Project  -----OK

2.绑定项目

        $ git init

        $ git remote add origin git@gitlab.***.org:***-ERP/***.git

        $ git add .

        $ git commit -m "初始化

        $ git push -u origin master

 

 项目根目录下的文件：

.gitigonre 你想要忽略的文件或者目录

• /mtk/ 过滤整个文件夹

• *.zip 过滤所有.zip文件

• /mtk/do.c 过滤某个具体文件

.gitattribute 用于设置文件的对比方式（常用非文本文件）

参考地址：https://git-scm.com/book/zh/v1/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-Git%E5%B1%9E%E6%80%A7

 

 

参考以下：

http://www.cnblogs.com/tugenhua0707/p/4050072.html#!comments

http://git-scm.com/book/en/v2

http://blog.csdn.net/hudashi/article/details/7664374 【git add 详解】

http://www.15yan.com/topic/yi-dong-kai-fa-na-dian-shi/6yueHxcgD9Z/

 

http://www.tech126.com/git-fetch-pull/

 

Git status回车出现如下错误

 stderr: error: bad signature fatal: index file corrupt
在项目有.git这同级打开Git Bash Here
1. 输入  $ rm -f .git/index

出现

ssss@DESKTOP-ssssMINGW64 /e/project/ssss(master)

 

2. 再输入

$ git reset

 

出现如下没有提交的文件说明好了，然后重启开发工具就行。 Unstaged changes after reset: M       sss/app/src/main/AndroidManifest.xml M    

然后重启开发工具就好了

 

 

git reset [--hard|soft|mixed|merge|keep] [<commit>或HEAD]：将当前的分支重设（reset）到指定的<commit>或者HEAD（默认，如果不显示指定commit，默认是HEAD，即最新的一次提交），并且根据[mode]有可能更新index和working directory。mode的取值可以是hard、soft、mixed、merged、keep。下面来详细说明每种模式的意义和效果。

A). --hard：重设（reset） index和working directory，自从<commit>以来在working directory中的任何改变都被丢弃，并把HEAD指向<commit>。 

具体一个例子，假设有三个commit， git st:

commit3: add test3.c

commit2: add test2.c

commit1: add test1.c

执行git reset --hard HEAD~1后，

显示：HEAD is now at commit2，运行git log

commit2: add test2.c

commit1: add test1.c

运行git st， 没有任何变化

B). --soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向<commit>。这个模式的效果是，执行完毕后，自从<commit>以来的所有改变都会显示在git status的"Changes to be committed"中。 

具体一个例子，假设有三个commit， git st:

commit3: add test3.c

commit2: add test2.c

commit1: add test1.c

执行git reset --soft(默认) HEAD~1后，运行git log

commit2: add test2.c

commit1: add test1.c

运行git status， 则test3.c处于暂存区，处于准备提交状态。即此时git commit就会提交它。

  在使用git进行协作开发时，我们经常需要将自己的修改生成patch发给被人，但是在修改代码的过程中我们进行了很多次的提交，如何生成从最初的代码状态到最终代码状态的patch呢？下面要介绍的功能是应对这中情况。

现假设我们git软件仓库中的分支情况如下：

a-->b-->c

也就是说我们的代码从状态a修改到状态b，进行一次提交，然后再修改到状态c，进行一次提交。这时我们已经肯定由a到c的修改是正确的，不再需要状态b了，并且要把从a到c的变化生成一个patch发送给别人。如果直接打包的话会生成两个path，那么如何生成一个patch呢，这时就需要git-reset命令。

首先给状态a创建一个tag，假设名称为A，然后执行

git-reset --soft A

这样我们的软件仓库就变为

a

状态b和状态c都已经被删除了，但是当前的代码并没有被改变，还是状态c的代码，这时我们做一次提交，软件仓库变成下面的样子：

a-->d

状态d和状态c所对应的代码是完全相同的，只是名字不同。现在就可以生成一个patch打包发给别人了

C). --mixed：仅reset index，但是不reset working directory。这个模式是默认模式，即当不显示告知git reset模式时，会使用mixed模式。这个模式的效果是，working directory中文件的修改都会被保留，不会丢弃，但是也不会被标记成"Changes to be committed"，但是会打出什么还未被更新的报告。报告如下： 

引用

Unstaged changes after reset: 

M Test.Scala 

M test.txt

D). --merge和--keep用的不多，在下面的例子中说明。 

二、常用示例

下面列出一些git reset的典型的应用场景： 

A) 回滚add操纵 

引用

$ edit                                     (1) 

$ git add frotz.c filfre.c 

$ mailx                                    (2) 

$ git reset                                (3) 

$ git pull git://info.example.com/ nitfol  (4) 

(1) 编辑文件frotz.c, filfre.c，做了些更改，并把更改添加到了index 

(2) 查看邮件，发现某人要你pull，有一些改变需要你merge下来 

(3) 然而，你已经把index搞乱了，因为index同HEAD commit不匹配了，但是你知道，即将pull的东西不会影响已经修改的frotz.c和filfre.c，因此你可以revert这两个文件的改变。revert后，那些改变应该依旧在working directory中，因此执行git reset。 

(4) 然后，执行了pull之后，自动merge，frotz.c和filfre.c这些改变依然在working directory中。 

B) 回滚最近一次commit 

引用

$ git commit ... 

$ git reset --soft HEAD^      (1) 

$ edit                        (2) 

$ git commit -a -c ORIG_HEAD  (3) 

(1) 当提交了之后，你又发现代码没有提交完整，或者你想重新编辑一下提交的comment，执行git reset --soft HEAD^，让working tree还跟reset之前一样，不作任何改变。 

HEAD^指向HEAD之前最近的一次commit。 

(2) 对working tree下的文件做修改 

(3) 然后使用reset之前那次commit的注释、作者、日期等信息重新提交。注意，当执行git reset命令时，git会把老的HEAD拷贝到文件.git/ORIG_HEAD中，在命令中可以使用ORIG_HEAD引用这个commit。commit 命令中 -a 参数的意思是告诉git，自动把所有修改的和删除的文件都放进stage area，未被git跟踪的新建的文件不受影响。commit命令中-c <commit> 或者 -C <commit>意思是拿已经提交的commit对象中的信息（作者，提交者，注释，时间戳等）提交，那么这条commit命令的意思就非常清晰了，把所有更改的文件加入stage area，并使用上次的提交信息重新提交。 

C) 回滚最近几次commit，并把这几次commit放到叫做topic的branch上去。 

引用

$ git branch topic/wip     (1) 

$ git reset --hard HEAD~3  (2) 

$ git checkout topic/wip   (3)

(1) 你已经提交了一些commit，但是此时发现这些commit还不够成熟，不能进入master分支，但你希望在新的branch上润色这些commit改动。因此执行了git branch命令在当前的HEAD上建立了新的叫做 topic/wip的分支。 

(2) 然后回滚master branch上的最近三次提交。HEAD~3指向当前HEAD-3个commit的commit，git reset --hard HEAD~3即删除最近的三个commit（删除HEAD, HEAD^, HEAD~2），将HEAD指向HEAD~3。 

D) 永久删除最后几个commit 

引用

$ git commit ... 

$ git reset --hard HEAD~3   (1)

(1) 最后三个commit（即HEAD, HEAD^和HEAD~2）提交有问题，你想永久删除这三个commit。 

E) 回滚merge和pull操作 

引用

$ git pull                         (1) 

Auto-merging nitfol 

CONFLICT (content): Merge conflict in nitfol 

Automatic merge failed; fix conflicts and then commit the result. 

$ git reset --hard                 (2) 

$ git pull . topic/branch          (3) 

Updating from 41223... to 13134... 

Fast-forward 

$ git reset --hard ORIG_HEAD       (4)

(1) 从origin拉下来一些更新，但是产生了很多冲突，你暂时没有这么多时间去解决这些冲突，因此你决定稍候有空的时候再重新pull。 

(2) 由于pull操作产生了冲突，因此所有pull下来的改变尚未提交，仍然再stage area中，这种情况下git reset --hard 与 git reset --hard HEAD意思相同，即都是清除index和working tree中被搞乱的东西。 

(3) 将topic/branch合并到当前的branch，这次没有产生冲突，并且合并后的更改自动提交。 

(4) 但是此时你又发现将topic/branch合并过来为时尚早，因此决定退滚merge，执行git reset --hard ORIG_HEAD回滚刚才的pull/merge操作。说明：前面讲过，执行git reset时，git会把reset之前的HEAD放入.git/ORIG_HEAD文件中，命令行中使用ORIG_HEAD引用这个commit。同样的，执行pull和merge操作时，git都会把执行操作前的HEAD放入ORIG_HEAD中，以防回滚操作。 

F) 在被污染的working tree中回滚merge或者pull 

引用

$ git pull                         (1) 

Auto-merging nitfol 

Merge made by recursive. 

nitfol                |   20 +++++---- 

... 

$ git reset --merge ORIG_HEAD      (2)

(1) 即便你已经在本地更改了一些你的working tree，你也可安全的git pull，前提是你知道将要pull的内容不会覆盖你的working tree中的内容。 

(2) git pull完后，你发现这次pull下来的修改不满意，想要回滚到pull之前的状态，从前面的介绍知道，我们可以执行git reset --hard ORIG_HEAD，但是这个命令有个副作用就是清空你的working tree，即丢弃你的本地未add的那些改变。为了避免丢弃working tree中的内容，可以使用git reset --merge ORIG_HEAD，注意其中的--hard 换成了 --merge，这样就可以避免在回滚时清除working tree。 

G) 被中断的工作流程 

在实际开发中经常出现这样的情形：你正在开发一个大的feature，此时来了一个紧急的bug需要修复，但是目前在working tree中的内容还没有成型，还不足以commit，但是你又必须切换的另外的branch去fix bug。请看下面的例子 

引用

$ git checkout feature ;# you were working in "feature" branch and 

$ work work work       ;# got interrupted 

$ git commit -a -m "snapshot WIP"                 (1) 

$ git checkout master 

$ fix fix fix 

$ git commit ;# commit with real log 

$ git checkout feature 

$ git reset --soft HEAD^ ;# go back to WIP state  (2) 

$ git reset                                       (3)

(1) 这次属于临时提交，因此随便添加一个临时注释即可。 

(2) 这次reset删除了WIP commit，并且把working tree设置成提交WIP快照之前的状态。 

(3) 此时，在index中依然遗留着“snapshot WIP”提交时所做的uncommit changes，git reset将会清理index成为尚未提交"snapshot WIP"时的状态便于接下来继续工作。 

(H) Reset单独的一个文件 

假设你已经添加了一个文件进入index，但是而后又不打算把这个文件提交，此时可以使用git reset把这个文件从index中去除。 

引用

$ git reset -- frotz.c                      (1) 

$ git commit -m "Commit files in index"     (2) 

$ git add frotz.c                           (3)

(1) 把文件frotz.c从index中去除， 

(2) 把index中的文件提交 

(3) 再次把frotz.c加入index 

(I) 保留working tree并丢弃一些之前的commit 

假设你正在编辑一些文件，并且已经提交，接着继续工作，但是现在你发现当前在working tree中的内容应该属于另一个branch，与这之前的commit没有什么关系。此时，你可以开启一个新的branch，并且保留着working tree中的内容。 

引用

$ git tag start 

$ git checkout -b branch1 

$ edit 

$ git commit ...                            (1) 

$ edit 

$ git checkout -b branch2                   (2) 

$ git reset --keep start                    (3)

(1) 这次是把在branch1中的改变提交了。 

(2) 此时发现，之前的提交不属于这个branch，此时你新建了branch2，并切换到了branch2上。 

(3) 此时你可以用reset --keep把在start之后的commit清除掉，但是保持working tree不变。