标签：
https://zhuanlan.zhihu.com/p/19845650
Gi t中的 HEAD 是指向当前分支引用的指针，相应地也就是一个指向你的最后一次提交的指针。通常可以简单的认为 HEAD 就是你的最后一次提交的快照。 分支是源码树commit的一个指针。 tag是分支里的一个commit(tag是从需求层面提取出来的一个概念：需求issue的一个分组)。 tag不是全局的,是当前分支的。git push 不会把tag推到远程分支 将Develop分支发布到Master分支的命令： # 切换到Master分支 git checkout master # 对Develop分支进行合并 git merge --no-ff develop 这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。 使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法
http://www.cnblogs.com/softidea/p/5286990.html
一、撤销指令
我们可以使用git reset HEAD（HEAD~2）这种方式进行还原到某一个提交记录上。因为HEAD所指向的commit就是我们想要恢复的内容，也就是我们HEAD指向的commit就是我们要用这些数据覆盖暂存区数据。
这时候我们在git status看一下，暂存区的内容就被还原了。
工作流程：
•克隆项目
•签出并创建 dev 分支，使其跟踪远程的 origin/dev 分支。
•在dev分支基础上创建自己的分支 member* 。
--------------------------------------------------------------------------------
•在自己的分支上添加文件
•在自己的分支上修改文件
•合并到dev分支
•推送dev分支到origin/dev分支
--------------------------------------------------------------------------------
// 更新 .gitignore 文件
•从 dev 新建一个分支 ignore （如果预测变更频繁就建立一个远程分支，现在一般都有模板，偶尔有个没有忽略的直接在dev分支上改就可以了）
•更新忽略文件
•尽快合并到\推送到 origin/dev 分支 （避免两个组员同时更改该文件造成冲突。）
http://www.cnblogs.com/softidea/p/4221066.html
git pull = git fetch + git merge
http://www.cnblogs.com/softidea/p/4967616.html
git init 产生的目录解释
error: src refspec master does not match any.
引起该错误的原因是，目录中没有文件，空目录是不能提交上去的
error: insufficient permission for adding an object to repository database ./objects
服务端没有可写目录的权限
错误提示：fatal: remote origin already exists.
解决办法：$ git remote rm origin
错误提示：error: failed to push som refs to ........
解决办法：$ git pull origin master //先pull 下来 再push 上去
git init //在当前项目工程下履行这个号令相当于把当前项目git化，变身！
git add .//把当前目次下代码参加git的跟踪中，意思就是交给git经管，提交到本地库
git add <file> //把当前文件参加的git的跟踪中，交给git经管，提交到本地库
git commit -m “…”//相当于写点提交信息
git remote add origin git＠github.com:ellocc/gittest.git //这个相当于指定本地库与github上的哪个项目相连
git push -u origin master //将本地库提交到github上。
git clone git＠github.com:ellocc/gittest.git //将github上的项目down下来。
git fetch origin //取得长途更新，这里可以看做是筹办要取了
git merge origin/master //把更新的内容归并到本地分支/master
下面是删除文件后的提交
git status //可以看到我们删除的哪些文件
git add . //删除之后的文件提交git经管。
git rm a.c //删除文件
git rm -r gittest //删除目录
git reset --hard HEAD 回滚到add之前的状态
git diff比较的是跟踪列表中的文件(暂存区)和文件系统中文件（Work Copying）的差别
http://blog.csdn.net/qyf_5445/article/details/8737913
1，生成一个公司用的SSH-Key
1
$ ssh-keygen -t rsa -C "youremail@yourcompany.com” -f ~/.ssh/id-rsa
在~/.ssh/目录会生成id-rsa和id-rsa.pub私钥和公钥。 我们将id-rsa.pub中的内容粘帖到公司gitlab服务器的SSH-key的配置中。
2，生成一个github用的SSH-Key
1
$ ssh-keygen -t rsa -C "youremail@your.com” -f ~/.ssh/github-rsa
在~/.ssh/目录会生成github-rsa和github-rsa.pub私钥和公钥。 我们将github-rsa.pub中的内容粘帖到github服务器的SSH-key的配置中。
3，添加私钥
$ ssh-add ~/.ssh/id_rsa $ ssh-add ~/.ssh/id_rsa_github
如果执行ssh-add时提示"Could not open a connection to your authentication agent"，可以现执行命令：
$ ssh-agent bash
然后再运行ssh-add命令。
# 可以通过 ssh-add -l 来确私钥列表
$ ssh-add -l
# 可以通过 ssh-add -D 来清空私钥列表
$ ssh-add -D
http://www.cnblogs.com/softidea/p/4967611.html
git config
http://www.cnblogs.com/softidea/p/4783103.html
git st # git status git ci # git commit git br # git branch git co # git checkout git mg # git merge git line # git log --oneline
其实，我们在切换分支，和新建分支的时候，有没有想过，这些操作操作背后的工作原理是怎样的呢？最大的功臣就是.git目录下的HEAD引用，她宛如一个芭蕾舞者，从一个分支飘逸的跳到另一个分支，虽无声无息，却精准无比。
在我们身处master分支的时候，您一定很好奇，当前的HEAD的内容是什么？不妨来看看吧。
我们看到c1的提交hash值和HEAD对应分支master的当前hash值是一样的。也就是说，HEAD指向的是当前分支名master，而master又对应了当前的最新的一次提交ID.
好，那么我们再做一次提交，看看master对应的hash值有无变化。
从上图，我们可以不难看出，HEAD对应的ref没有变化，还是master，但是master对应的commit ID却变成了c2对应的commit ID，即更新为最后一次提交的ID咯。
http://www.cnblogs.com/softidea/p/4967602.html
如果一个文件被删除了，可以使用切换版本号进行恢复。恢复方法：
先确定需要恢复的文件要恢复成哪一个历史版本(commit)，假设那个版本号是： commit_id，那么
git checkout commit_id -- path_to_file
就可以恢复。
还有一个方法是：
你直接从本地把文件checkout出来就可以了，用不着从远程服务器上pull下来，因为，所以的历史版本你的本地都有的。
具体做法 git checkout file 同时恢复多个被删除的文件.
http://www.cnblogs.com/softidea/p/4756108.html
http://www.cnblogs.com/softidea/p/5129830.html
https://zhuanlan.zhihu.com/p/19845650
Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。
git config --global merge.tool vimdiff
http://blog.jobbole.com/25775/
git help config
http://www.cnblogs.com/softidea/p/4899906.html
$ git remote add [name] [url]
分支(branch)操作相关命令
查看本地分支：$ git branch
查看远程分支：$ git branch -r
创建本地分支：$ git branch [name] ----注意新分支创建后不会自动切换为当前分支
切换分支：$ git checkout [name]
创建新分支并立即切换到新分支：$ git checkout -b [name]
删除分支：$ git branch -d [name] ---- -d选项只能删除已经参与了合并的分支，对于未有合并的分支是无法删除的。如果想强制删除一个分支，可以使用-D选项
合并分支：$ git merge [name] ----将名称为[name]的分支与当前分支合并
创建远程分支(本地分支push到远程)：$ git push origin [name]
http://www.cnblogs.com/Bonker/p/3441781.html
Commit History（提交历史）
一个分支是一系列的提交，这个分支可以分成更多的分支。默认分支名是 master，确切的说仅仅是一个可移动的指针。起初，会有一个 master 分支指向了你的最后一次提交。当你每一次提交，指针会自动的移动去指向最后一次提交。
This should be understood in the context of GitHub forks (where you fork a GitHub repo at GitHub before cloning that fork locally)
http://www.cnblogs.com/softidea/p/4793254.html
git:
git fetch//获取origin上的更新
git merge//和本地代码合并，如果有clifict，还要resolve才能提交
git add <some files>//暂存数据（标识要commit的本地所有文件），.代表所有本地文件（除了ignore文件中标识的）。也可以add指定文件名的单个文件
git status -s//查看本地仓库的修改状态，如果没有输出，说明没有需要提交的。
git commit -m "注释"//提交到本地仓库
git push origin master//提交到git服务器origin的master分支
git branch//查看
git log --oneline -5
你是不是很烦那些编译过的文件 (比如 .pyc) 出现在你的 Git 仓库中？或者说你已经受够了已经把它们都加进了 Git 仓库？好了，这有个办法可以让你告诉 Git 忽略掉那些特定的文件和文件夹。只需要创建一个名为 .gitignore 然后列出那些你不希望 Git 跟踪的文件和文件夹。你还可以添加例外，通过使用感叹号(!)。
*.pyc
*.exe
my_db_config/
!main.pyc
git log ，不过，这里还有三个你应该知道的选项。
--oneline– 压缩模式，在每个提交的旁边显示经过精简的提交哈希码和提交信息，以一行显示。--graph– 图形模式，使用该选项会在输出的左边绘制一张基于文本格式的历史信息表示图。如果你查看的是单个分支的历史记录的话，该选项无效。假设你不小心提交了些你不想要的东西，不得不做一次强制重置来恢复到之前的状态。然后，你意识到在这一过程中你丢失了其它一些信息并且想要把它们找回来，或者至少瞅一眼。这正是git reflog可以做到的。
一个简单的git log命令可以为你展示最后一次commit，以及它的父亲，还有它父亲的父亲等等。而git reflog则列出了head曾经指向过的一系列commit。要明白它们只存在于你本机中；而不是你的版本仓库的一部分，也不包含在push和merge操作中。
如果我运行git log命令，我可以看到一些commit，它们都是我仓库的一部分：
然而，一个git reflog命令则展示了一次commit (b1b0ee9—HEAD@{4})，它正是我刚才进行强制重置时弄丢的：
http://www.techug.com/articlearticle
在git中，我们其实可以通过^和~来定位某个具体的commit，而不用每次都去敲繁琐的hash值。为了便于大家理解，先把结论放在前面：
使用git log –graph 命令，可以查看自己仓库的当前分支提交ID的树状图，如下图所示。
使用git log –pretty=raw命令，可以查看commit之间的父子关系，如下图所示，需要注意的是最开始的commit是没有父提交的。
查看HEAD和引用的值
我们可以通过命令来查看HEAD和引用的值，也可以通过当前仓库下的.git目录去访问。当前分支为master时，我们查看HEAD的值，命令如下：
$ cat .git/HEAD
ref: refs/heads/master
然后，我们可以查看master引用的值
$ cat .git/refs/heads/master
3b0370b....... # hash code
git commit -a -m "c5"
先切换到master分支，然后合并br1 br2 br3，会新生成一个提交3b03.
$ git checkout master
$ git merge br1 br2 br3
这时候，运用git log –oneline –graph查看生成的树状图，如下所示.
从上图分析，在第1条红线上的commit顺序是: 3b03→4927→1c73→973c
第2条红线上的commit顺序是:3b03→063f→86ba→973c
第3条黄线上的commit顺序是:3b03→4f9c→50f1→973c
这3条线的从左至右的顺序非常重要，因为HEAD^1对应的就是第1条红线的提交4927，HEAD^2对应的是第2条绿线的063f提交，HEAD^3对应的是第3条黄线的4f9c提交。3b03没有第4个父提交，因此也没有第4条线，这时候访问HEAD^n(n>3)都会报错。
因此从任何一条线上，我们都可以追溯到”c1”的commit，但是每条线上的中间节点，只能通过这条线上的节点去访问。
操作同上类似，最后的状态如下，这时候HEAD指向master，master引用指向”c8”的对应提交3b03.
http://www.cnblogs.com/softidea/p/4967607.html
标签：
原文地址：http://www.cnblogs.com/softidea/p/5444987.html
