Git wiki

reset其实就是在move HEAD指针。顺便会改变几个空间中的内容。

      # head = HEAD~, index = HEAD, working_directory = HEAD
      git reset --soft HEAD~

      # head = HEAD~, index = HEAD~, working_directory = HEAD ,default
      # methods
      git reset --mixed HEAD~

      # head = HEAD~, index = HEAD~, working_directory = HEAD~ , this is
      # dangerous because some commit may lost!
      git reset --hard HEAD~

git add 到index中的内容是不可回退的。git add后，使用 git reset HEAD 可以回退到add之前的状态。

reset --hard 后，其实那些commit是还在的。这些没有被任何branch引 用的commit叫 dangling commit 。这些东西git会定期清理它。如果想手 动清理，需要先把reflog清理掉（我理解reflog还是在“引用”它。）然后 手动用 git gc 来清理就可以了。

       git reflog expire --expire-unreachable=now --all
       git gc --prune=now

      +----------------------------------------------------------------------+
      |                                                    +---------------+ |
      |                                                    |     HEAD      | |
      |                                                    +------+--------+ |
      |                                                           |          |
      |                                                    +------+--------+ |
      |                                                    |    master     | |
      |                                                    +------+--------+ |
      |                                                           |          |
      +---------------+          +---------------+         +------v--------+ |
      |  commit_id:x  |          |  commit_id:y  |         |  commit_id:z  | |
      |               |          |               |         |               | |
      |   file.txt    |<---------+   file.txt    |<--------+   file.txt    | |
      |     v1        |          |     v2        |         |     v3        | |
      |               |          |               |         |               | |
      +---------------+          +---------------+         +---------------+ |
      |                                                                      |
      |                          Git repository                              |
      +----------------------------------------------------------------------+

      +---------------+          +---------------+         +-----------------+
      |    HEAD       |          |    Index      |         |Working Directory|
      +---------------+          +---------------+         +-----------------+
      |  commit_id:z  |          |               |         |                 |
      |               |          |               |         |                 |
      |   file.txt    |          |   file.txt    |         |   file.txt      |
      |     v3        |          |     v1        |         |     v3          |
      |               |          |               |         |                 |
      +---------------+          +---------------+         +-----------------+

      git reset commit_id:x file.txt

git reset 如果针对file或path进行操作。只是简单地是把对应 commit_{id中的的file放到Index}（暂存区）中。

如果对应的commit_{id刚好是HEAD}，则 git reset HEAD file 刚好和 git add file 在上图是对称动作。

      +----------+                           +----------+                   +-----------------+
      |  HEAD    |                           |  Index   |                   |Working Directory|
      +----------+                           +----------+                   +-----------------+
      |          |                           |          |                   |                 |
      |          |  git reset HEAD file.txt  |          |  git add file.txt |                 |
      | file.txt |-------------------------->| file.txt |<------------------|   file.txt      |
      |          |                           |          |                   |                 |
      |          |                           |          |                   |                 |
      +----------+                           +----------+                   +-----------------+

对于解决 Git 的 Merge Conflict 你有哪些经验和技巧？

     我的经验是使用rebase。

     具体操作
     1. git add <FILE>
     2. git commit ...
     3. git pull --rebase （将你的版本加在最后的节点上） 如果有冲突，会
        提示你。冲突分为两种，一种是在不同地方的冲突，通常情况下，git是
        可以自己合并的。另外一种是因为可能是同一个文件的编辑，git没法自
        动合并，需要二选一，这时候打开冲突的文件，手动编辑文件到可用的版
        本。然后。
     4. git rebase --continue
     5. 重复3，4直到所有的都solve
     6. git push

By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it. If you would prefer for Git to simply choose a specific side and ignore the other side instead of letting you manually merge the conflict, you can pass the merge command either a -Xours or -Xtheirs.

如果出现了confict，如果确信是可以保存某一分支的内容。可以使用这个选 项。

      git checkout -b A
      git checkout master
      # 合并后以当前master为准
      git merge -Xours A
      # 合并后以A为准
      git merge -Xtheris A

可以找到两个commit的共同的祖先。这个在想找到分支的交叉点的时候很有 用。

      git merge-base 7d6930f4c77bc7cd5e018ce046a26726ec448db3 000351e7b82e3211dd8fa5f4d0c09d647b66f450

使用git时最先需要设置的是就是用户名和邮箱：

      git config --global user.name 'xxxxx'
      git config --global user.email 'xxxx@gmail.com'

设置commit的模版，以后每次commit都会自动加入这个模版。

      git config --global commit.template ~/.gitmessage.txt

配置默认使用emacs编辑器，这里 emacsclient 不能加 --no-wait 选项。 需要让命令行等待emacsclient：

      git config --global core.editor 'emacsclient'

可以看到上一小节中我们在配置时都带了 --global 选项。从名字中可以 看出这是一个全局设置的意思。它默认修改的是 ~/.gitconfig 文件。比 如我当前的这个文件长这样：

     [diff]
             tool = bc3
     [difftool]
             prompt = false
     [merge]
             tool = bc3
     [mergetool]
             prompt = true
             keepBackup = false
     [filter "lfs"]
             clean = git-lfs clean %f
             smudge = git-lfs smudge %f
             required = true
     [user]
             name = PengXie
             email = xxx@gmail.com
     [core]
             quotepath = false
             editor = emacsclient
     [commit]
             template = /Users/pengpengxp/.gitmessage.txt
     [http]
             proxy = socks5://172.16.25.48:1089
     [https]
             proxy = socks5://172.16.25.48:1089
     [push]
             default = simple

如果不加这个选项，默认是就是配置当前仓库（需在在一个仓库内执行，不 然会报错。）。此时它修改的是当前目录下 .git/config 文件。只对本仓 库有效。

     git push origin local-branch-name:server-branch-name

把local的branch推送到origin标记的remote上的名字为server-branch-name的 branch，如果没有，则新建。

     git push origin --all

把本地所有分支推送到remote上去。名字就和本地是一样的。

git push origin serverfix:serverfix

it says,"Take my serverfix and make it the remote's serverfix." You can use thsi format to push a local branch into a remote branch that is named differently. If you didn't want it to be called serverfix on the remote, you could instead run git push origin serverfix:awesomebranch to push your local serverfix branch to the awesomebranch branch on the remote project; If you didn't want it to be called serverfix on the remote, you could instead run \(git push origin serverfix:awesomebranch\) to push your local serverfix branch to the awesomebranch branch on the remote project.

我的理解

git push origin localserverfix:remoteserverfix

localserverfix是本地branch的名字，remoteserverfix是remote端branch的名 字。

设置这个选项，可以不用每次都显示的指定需要push的分支，设置对了，以后就 直接git push就行了。。manual上面是这么写的：

     push.default
         Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific
         workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is
         probably what you want. Possible values are:

         ·   nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who
             want to avoid mistakes by always being explicit.

         ·   current - push the current branch to update a branch with the same name on the receiving end. Works in both central and
             non-central workflows.

         ·   upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which
             is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from
             (i.e. central workflow).

         ·   simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name
             is different from the local one.

             When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest
             option and is suited for beginners.

             This mode will become the default in Git 2.0.

         ·   matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the
             set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the
             repository you push to will have these two branches, and your local maint and master will be pushed there).

             To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before
             running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually
             finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also
             this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or
             update the tip of existing branches outside your control.

             This is currently the default, but Git 2.0 will change the default to simple.

我暂时使用设置成了 current 选项。每次都push我的当前分支。现在推 荐使用 simple 。

     git config --global push.default "simple"

git可以是一个本地库，但是它更多地，应该是和远端做交互，以进行多人协 作。

git remote 命令就是设置远端库的地址的。常用的命令：

     # 查询所有远端
     git remote -v
     # 添加
     git remote add origin <url>
     # 修改
     git remote set-url origin <url>
     # 其它
     git remote --help

其实可以看到，这些 origin 都只是一个 url 的别名而已。

git和远端进行交互，有两种方式可选：ssh和https。不过一般https都只有下 载权限（就像很多开源软件一样，大家都可以下载）。而上传权限的话，一般 需要配置 ssh 方式了。使用ssh最好上传公钥到github上去，这样push就可 以不需要密码了， 可以参考 一个实际的例子 。

我的理解

读了pro git对应部份，终于明白了。git remote就是控制远程的分支的。一般默 认origin/master是你最近一次和remote连接的时候，remote那边的master指向的 snapshot。在本地，origin/master就是指向remote的master的“指针”。 master是指向本地的。如果在最近有别人修改过remote上的master（也就是把 master向前推进了），使用git fetch origin来获得所有remote上origin有的而 本地没有的。

英文原文：To synchronize your work, you run a git fetch origin command. This command looks up which server origin is, fetches any data from it that you don't yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position.

那么还有一个问题：如果origin还有其他分支呢？也会一起fetch过来然后 update了？是的。英文原文如下：

It's important to note that when you do a fetch that brings down new remote branches, you don't automatically have local, ediable copies of them. In other words, in this case, you don't have a new serverfix branch – you only have an origin/serverfix pointer that you can't modify.

If you want your own serverfix branch that you can work on, you can base it off your remote branch:

     git checkout -b origin/serverfix

原因是这些文件夹都是我通过使用`git clone'下来的。里面被理解成了 submodule这种东西了。黙认它们应该是跟踪对应的repo去了。所以我希望 能建立一个完全独立的.emacs.d的话。每次下载下来的东西。最好都把.git 去掉。

可以使用ssh的方式来和github仓库交互，配置默认无密码后，每次提交都不需 要输入用户名和密码了，很方便。

配置默认的ssh和一般几台机器上差不多，先使用ssh-keygen生成id_rsa.pub。 然后拷贝其中内容到github端。github帐户那儿有设置ssh的。把它粘贴上去就 行了。当然最后需要输入密码确认一遍。

刚开始的时候我配置好了ssh，但是push还是需要输入用户名密码，结果发现， 原来一般git clone的时候使用的是https，所有保存在origin中的url都是https 的。需要修改为ssh的。我认为应该可以直接修改.git目录中的config中的url都 可以的。但是我还是照着网上说的，使用命令来修改的：

     git remote set-url origin git@github.com:pengpengxp/.emacs.d.git

中文的doc

其实是都在的，只不过是被隐藏了。使用下面的命令可以看到的。

     git branch -a

不过如果要在remote上的其他分支上进行开发，最好在弄出一个本地分支出来做：

     git checkout -b "local-branch-name" "remote-branch-name"

使用下面的命令删除远程分支：

     git push origin --delete "remote-branch-name"

也可以这样简写：

     git push origin :"remote-branch-name"

在magit的状态下，使用P，有–force选项，直接按-f，然后再按一次P就行了。