我的Git常用命令.txt

http://git-scm.com/docs

我的常用
git init        创建一个空的Git库。在当前目录中产生一个.git 
git add dir1  （添加dir1这个目录，目录下的所有文件都被加入 ） 
git add f1 f2 （ 添加f1，f2文件） 
git add .      ( 添加当前目录下的所有文件和子目录 ) 
git status     查看版本库的状态
git log        查看历史日志
git diff       比较工作目录和Index中的代码

git checkout local_branch 切换到某个已经建立的本地分支local_branch
git checkout –b 新分支名
git checkout master     //取出master版本的head。
git checkout tag_name    //在当前分支上 取出 tag_name 的版本
git checkout  master file_name  //放弃当前对文件file_name的修改
        eg: git checkout bb.txt   //放弃对bb.txt文件的修改(当前相对的路径)
              git checkout .   //git放弃对当前文件夹的所有文件的修改
git checkout  commit_id file_name  //取文件file_name的 在commit_id是的版本。commit_id为 git commit 时的sha值。

git show exp  //显示分支信息
git push https://git.oschina.net/zruibin/me.git 将本地commit的代码更新到远程版本库中
git remote add master //添加多个远程库，例：git remote add master https://github.com/zruibin/EMACScript_Conveting_Script
git remote set-url --add master https://github.com/zruibin/EMACScript_Conveting_Script
git push all --all //由于有多个远程库，提交时需要执行该命令
git push -f origin master // origin 远程仓库名， master 分支名， -f 为force，意为：强行、强制。

git fetch origin master:temp 这句命令的意思是：从远程的origin仓库的master分支下载到本地并新建一个分支temp
git branch -d temp 如果该分支没有合并到主分支会报错，可以用以下命令强制删除git branch -D <分支名>
I
git中，每次提交修改文件之前要add，然后再commit。git的add命令和许多版本控制系统不一样，不是增加新增的文件，而是以内容为单位，
将最新修改的内容，添加到一个临时的索引中，等待commit。实践发现，如果修改一个文件，然后diff查看修改，然后add，然后再修改，
然后在commit

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: [<path>]表示把<path>中所有tracked文件中被修改过或已删除文件和所有untracted的文件信息添加到索引库。
                    省略<path>表示.,即当前目录。
git add -i我们可以通过git add -i [<path>]命令查看<path>中被所有修改过或已删除文件但没有提交的文件，
并通过其revert子命令可以查看<path>中所有untracted的文件，同时进入一个子命令系统

git diff temp 比较master分支和temp分支的不同,查看当前的工作目录与另外一个分支的差别
git diff branch1 branch2 --stat  --stat 是显示文件列表, 否则是文件内容diff
git diff test origin/xxx 对比获取远端库最新信息
git diff HEAD -- ./lib  显示你当前工作目录下的lib目录与上次提交之间的差别(或者更准确的 说是在当前分支)
git diff --stat 如果不是查看每个文件的详细差别，而是统计一下有哪些文件被改动，有多少行被改 动，就可以使用‘--stat' 参数

git remote 不带参数，列出已经存在的远程分支
git remote -v 这个命令可以显示对应项目的远程克隆地址。
git remote add origin url 本地的当前的项目与远程的哪个仓库建立连接
git remote remove <name> 删除远程克隆地址

git branch 不带参数：列出本地已经存在的分支，并且在当前分支的前面加“*”号标记
git branch -r 列出远程分支
git branch -a 列出本地分支和远程分支
git branch 创建一个新的本地分支，需要注意，此处只是创建分支，不进行分支切换  #git branch newbranch2
git branch -m | -M oldbranch newbranch 重命名分支，如果newbranch名字分支已经存在，则需要使用-M强制重命名，否则，
                                        使用-m进行重命名。
git branch -d | -D branchname 删除branchname分支
git branch -d -r branchname 删除远程branchname分支
git branch --track [branch] [remote-branch] 新建一个分支，与指定的远程分支建立追踪关系
git branch --set-upstream-to [remote-branch] 建立追踪关系，在现有分支与指定的远程分支之间
git push origin branch_name  push本地分支代码到远端服务器
git pull origin branch_name  pull远端分支代码到本地对应分支
git push origin --delete branch_name  删除远程分支

git merge origin/b  合并远程分支
git merge b         合并本地分支
git merge temp 合并temp分支到master分支(当前所在的分支为master)
                            合并完成后再执行git status，可以列出所有的合并，若有冲突的则在Unmerged paths中


git tag列出当前现有的tag
git tag -l <pattern>列出符合条件的tag。
git tag V3 5b888 //以后可以用V3来代替复杂的名称(5b888…)
git tag -a your_version_tagname your_commit_sha1 -m "your commit message"添加tag。
        "-a"表明是annotated类型的tag，可以保留一些相关的信息。
        不加"-a"表明是lightweight类型的tag，没有额外信息，仅仅是一个特定提交对象的引用。一般我们都使用"-a"选项。
        "your_version_tagname"是你想要加的tag名字，如"v1.2"之类的。
        "your_commit_sha1"是你在你多个历史提交中需要为某个提交打tag而不是为最近的一次提交打tag，可以加上那次提交的commit sha1值。
        -m "your commit message"则是为这个tag添加说明。
        在tag还没有被git push之前，你可以使用git tag -d your_version_tagname来删除它。
        使用git push origin your_version_tagname来push这个tag到远程分支，
        也可以使用git push origin -- tags一次性的推送所有本地新增的tag到远程分支。
        这样别人通过clone仓库或者同步数据之后也能看到这些tag。
        push了tag之后就算tag打的不对也不应该再删除这些tag，而是重新再新增一个正确的tag。
        git推送tag到远端服务器
默认情况下，git push并不会把tag标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。
1.push单个tag，命令格式为：git push origin [tagname]
例如：
git push origin v1.0 #将本地v1.0的tag推送到远端服务器
2.push所有tag，命令格式为：git push [origin] --tags
例如：
git push --tags
或
git push origin --tags
注：上述命令运行后，如果其他人clone远端服务器代码或进行pull同步后，也会看到这些标签。


git commit -m "Initial commit of gittutor reposistory"。 提交
         commit message 写错了，如果还没有push到服务器，只是本地进行了commit，并且没有进行新的commit，只需要
         git commit --amend;如果进行了新的commit，只需要git reset --soft xxx （xxx有问题那次提交的commit id），然后在进行
         git commit就行，不过所有后面的提交都成为了一次提交;如果想保持每次提交独立的话，使用
            git checkout -b tmp ^xxx
            git cherry-pick xxx
            git commit --amend
            git cherry-pick <依次后面的提交id>
        xxx还是有问题那次提交的commit id，单独建立tmp分支修改说明，然后将后面的提交一个一个的cherry-pick到新分支，然后删除掉旧的分支就可以了


git cherry-pick 可以选择某一个分支中的一个或几个commit(s)来进行操作
        假设我们有个稳定版本的分支，叫v2.0，另外还有个开发版本的分支v3.0，我们不能直接把两个分支合并，
        这样会导致稳定版本混乱，但是又想增加一个v3.0中的功能到v2.0中，这里就可以使用cherry-pick了。

        # 先在v3.0中查看要合并的commit的commit id
        git log
        # 假设是 commit f79b0b1ffe445cab6e531260743fa4e08fb4048b

        # 切到v2.0中
        git check v2.0

        # 合并commit
        git cherry-pick f79b0b1ffe445cab6e531260743fa4e08fb4048b

git rebase  有点类似git merge，但是两者又有不同，打个比方，你有两个抽屉A和B，里面都装了衣服，现在想把B中的衣服放到A中，
                  git merge是那种横冲直撞型的，拿起B就倒入A里面，如果满了（冲突）再一并整理；而git rebase就很持家了，它会一件一件的从B往A中加，
                  会根据一开始放入的时间顺序的来加，如果满了你可以处理这一件，你可以继续加，或者跳过这一件，又 或者不加了，把A还原。
                  所以merge适合那种比较琐碎的，简单的合并，系统级的合并还是用rebase吧。

                        专业的区别请移步到这里合并和衍合
   
                        # 合并b
                        git rebase b

                        # 处理完冲突继续合并
                        git rebase –continue

                        # 跳过
                        git rebase –skip

                        # 取消合并
                        git rebase –abort

            git rebase，顾名思义，就是重新定义（re）起点（base）的作用，即重新定义分支的版本库状态。
            要搞清楚这个东西，要先看看版本库状态切换的两种情况：

            我们知道，在某个分支上，我们可以通过git reset，实现将当前分支切换到本分支以前的任何一个版本状态，即所谓的“回溯”。
            即实现了本分支的“后悔药”。也即版本控制系统的初衷。 还有另一种情况，当我们的项目有多个分支的时候。我们除了在本地开发的时候可能会“回溯”外，
            也常常会将和自己并行开发的别人的分支修改添加到自 己本地来。这种情况下很常见。作为项目管理员，肯定会不断的合并各个子项目的补丁，
            并将最新版本推送到公共版本库，而作为开发人员之一，提交自己的补丁之 后，往往需要将自己的工作更新到最新的版本库，
            也就是说把别的分支的工作包含进来。
            举个例子来说吧！假设我们的项目初期只有一个master分支，然后分支上作过两次提交。这个时候系统只有一个master分支，他的分支历史如下：

            master0（初始化后的版本）
            ||
            v
            master1（第一次提交后的版本）
            ||
            v
            master2（第二次提交后的版本）

            这个时候，我们可以通过git reset将master分支（工作目录、工作缓存或者是版本库）切换到master1或者master0版本，这就是前面所说的第一种情况。
            假设我们这里把master分支通过git reset回溯到了master1状态。那么这个时候系统仍然只有一个master分支，分支的历史如下：

            master0（初始化后的版本）
            ||
            v
            master1（第一次提交后的版本）

            然后，我们在这里以master1为起点，创建了另一个分支test。那么对于test分支来说，他的第一个版本test0就和master1是同一个版本，此时项目的分支历史如下：

            master0（初始化后的版本）
            ||
            v
            master1（第一次提交后的版本）===test0（test分支，初始化自master分支master1状态）

            这个时候，我们分别对master分支、test分支作两次提交，此时版本库应该成了这个样子：

            master0（初始化后的版本）
            ||
            v
            master1===test0==>test1===>test2
            ||
            v
            master2===>master3

            这个时候，通过第一种git reset的方式，可以将master分支的当前状态（master3）回溯到master分支的master0、master1、master2状态。 
            也可已将test分支当前状态（test2）回溯到test分支的test0、test1状态，以及test分支的父分支master的master0、 master1状态。
            那么。如果我要让test分支从test0到test2之间所有的改变都添加到master分支来，使得master分支包含test分支的所有修改。这个时候就要用到git rebase了。
            首先，我们切换到master分支，然后运行下面的命令，即可实现我们的要求：

            git rebase test 这个时候，git做了些什么呢？先将test分支的代码checkout出来，作为工作目录
            然后将master分支从test分支创建起的所有改变的补丁，依次打上。如果打补丁的过程没问题，rebase就搞定了
            如果打补丁的时候出现了问题，就会提示你处理冲突。处理好了，可以运行git rebase –continue继续直到完成
            如果你不想处理，你还是有两个选择，一个是放弃rebase过程（运行git rebase –abort），另一个是直接用test分支的取代当前分支的（git rebase –skip）。
            此外，rebase还能够让你修订以前提交，这个功能日后再说。



 提交代码的log里面会显示提交者的信息
  git config --global user.name [username]
  git config --global user.email [email]



忽略文件.gitignore
忽略文件规则:
忽略规则是对文件名有效的;
A: 空行或#号开始的行,会被忽略;
B: 可以使用通配符:
   *        任意字符;
   ?        单个字符;
   [abc]    多种可能的字符a、b或c;
   [a-z0-9] 表示在某个范围内进行匹配;
   \        转义字符;
   !        表示取反(不忽略),写在某条规则的前面;
C: 路径分隔符"/";如果"/"后面的名称是个目录,则该目录以及该目录下的所有文件都会被忽略;如果"/"后面的名称是个文件,则该文件不会被忽略;
   例如: /name
   如果name是个目录,则目录name和name下的所有文件都会被忽略;如果name是个文件,则该文件不会被忽略;
D: .gitignore文件也可以忽略自己,只要把自己的名字写进来即可;
E: 一条(行)忽略规则只对某一个目录下的文件有效,而对该目录下的子目录中的文件无效;
F: 一条(行)忽略规则也可以只对单个文件有效(忽略单个指定的文件);

例如:
*.a       #忽略所有以.a为后缀的文件;
!lib.a    #不忽略文件lib.a;
/TODO     #只忽略此目录下TODO文件,子目录的TODO不被忽略;
build/    #忽略build目录下的所有文件;
doc/*.txt #只忽略doc/下所有的txt文件,但是不忽略doc/subdir/下的txt文件;

查看提交历史git log,如  git log --name-status b3d76ee39d0a24132b0e7eed5b28085776990156

-p 按补丁格式显示每个更新之间的差异。
--stat 显示每次更新的文件修改统计信息。
--shortstat 只显示 --stat 中最后的行数修改添加移除统计。
--name-only 仅在提交信息后显示已修改的文件清单。
--name-status 显示新增、修改、删除的文件清单。
--abbrev-commit 仅显示 SHA-1 的前几个字符，而非所有的 40 个字符。
--relative-date 使用较短的相对时间显示（比如，“2 weeks ago”）。
--graph 显示 ASCII 图形表示的分支合并历史。
--pretty 使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。


git回到上一版本命令
git reset是指将当前head的内容重置，不会留log信息。
git reset HEAD filename  从暂存区中移除文件
git reset --hard HEAD~3  会将最新的3次提交全部重置，就像没有提交过一样。
git reset --hard commit (38679ed709fd0a3767b79b93d0fba5bb8dd235f8) 回退到 38679ed709fd0a3767b79b93d0fba5bb8dd235f8 版本
根据--soft --mixed --hard，会对working tree和index和HEAD进行重置:
git reset --mixed：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息
git reset --soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
git reset --hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容，此命令慎用！
例如：我要彻底返回在上一次提交以前的版本。git reset --hrad HEAD~1
我要回到上一次提交的版本：git reset --hard 版本号
强行回滚远程服务器：git push -f


git clone
git clone git://github.com/someone/some_project.git   some_project 
              //将'git://github.com/someone/some_project. 
              git'这个URL地址的远程版本库，完全克隆到本地some_project目录下
用法1：git clone <repository> <directory>
      将<repository>指向的版本库创建一个克隆到<directory>目录。目录<directory>相当于克隆版本库的工作区，文件都会检出，版本库位于工作区的.git目录中
用法2：git clone --bare <repository> <directory.git>
用法3：git clone --mirror <repository> <directory.git>
    用法2和用法3创建的克隆版本库都不包含工作区，直接就是版本库的内容，这样的版本库称为裸版本库。一般约定俗成裸版本库的目录名以.git做后缀，
    所以上面示例中将克隆出来的裸版本库目录名写作<directory.git>。区别在于用法3克隆出来的裸版本对上游版本库进行了注册，这样可以在裸版本库中使用git fetch命令和上游版本库进行持续同步。
    不使用--bare或--mirror创建出来的克隆包含工作区，这样就会产生两个包含工作区的版本库，这两个版本库对等。
    这两个工作区本质上没有区别，往往提交在一个版本A中进行，另一个B作为备份。
    只能从B执行git pull命令从A中拉回新的提交实现版本库同步，而不能从版本库A向版本库B执行git push推送操作还可以通过git init的方式创建裸版本库，需要加--bare参数。
    当执行git push命令时，如果没有设定推送的分支，而且当前分支也没有注册到远程的某个分支，将检查远程分支是否有和本地相同的分支名（如master），如果有，则推送，否则报错。


git stash
git stash 往堆栈推送一个新的储藏
git stash save "work in progress for foo feature" 使用save可以对进度添加备注
git stash list  查看现有的储藏
git stash pop 恢复的是最近的一次改动
git stash pop stash@{id}或者 git stash apply stash@{id}  通过git stash list查看stash列表，从中选择你想要pop的stash
git stash drop <stash@{id}> 删除stash，如果不加stash编号，默认的就是删除最新的，也就是编号为0的那个，加编号就是删除指定编号的stash。
git  stash clear 是清除所有stash
git stash pop  与 git stash apply <stash@{id}> 的区别：
        git stash pop stash@{id}命令会在执行后将对应的stash id 从stash list里删除，
        而 git stash apply stash@{id} 命令则会继续保存stash id


git archive
git archive，对任意提交对应的目录树建立归档。
git archive -o latest.zip HEAD，基于最新提交建立归档文件latest.zip
git archive -o partial.tar HEAD src doc，只将目录src和doc建立到归档文件partial.tar中
git archive --format=tar --prefix=1.0/ v1.0 | gzip > foo-1.0.tar.gz，基于里程碑v1.0建立归档，并且为归档中的文件添加目录前缀1.0
git archive xxxx xxx代表SHA-1 Hash值


git clean
git clean 是从工作目录中移除没有track的文件. 通常的参数是git clean -df:
              -d表示同时移除目录,-f表示force,因为在git的配置文件中, clean.requireForce=true,如果不加-f,clean将会拒绝执行.
               -n 显示 将要 删除的文件和目录 ，-f 删除 文件，-df 删除 文件 和 目录


git删除中间某个commit

1.git log获取commit信息 
2.git rebase -i (commit-id) 
commit-id 为要删除的commit的下一个commit号 
3.编辑文件，将要删除的commit之前的单词改为drop 
4.保存文件退出大功告成 
5.git log查看


git config --global core.quotepath false          # 显示 status 编码
git config --global gui.encoding utf-8            # 图形界面编码
git config --global i18n.commit.encoding utf-8    # 提交信息编码
git config --global i18n.logoutputencoding utf-8  # 输出 log 编码