.gitignore文件示例：

.classpath
.project
.idea/
.settings/
target/
*~
*.iml
*.log
*.tmp

…or create a new repository on the command line

echo "# docs" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/helloworldtang/docs.git
git push -u origin master

…or push an existing repository from the command line

git remote add origin https://github.com/helloworldtang/docs.git
git push -u origin master //将本地的master分支推送到origin主机,同时指定origin为默认主机。如果有多个远程主机时使用。下次使用git push就会推送到默认的这个主机

 https://www.zhihu.com/question/20019419

idea的git commnad可能有问题 

在向配置gitlab的服务器进行Git push 出现以下错误

fatal: protocol error: bad line length character: No s
出现的原因是这个当前用户不拥有当前project的push权限
解决办法当然是联系管理员增加当前用户的权限咯

参考：
http://stackoverflow.com/questions/22314298/git-push-results-in-fatal-protocol-error-bad-line-length-character-this

>git pull origin master
warning: no common commits
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/helloworldtang/mp-demo
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master
fatal: refusing to merge unrelated histories

因为他们是两个不同的项目，要把两个不同的项目合并，git需要添加一句代码，在git pull，
这句代码是在git 2.9.2版本发生的，最新的版本需要添加--allow-unrelated-histories

假如我们的源是origin，分支是master，那么我们 需要这样写git pull origin master --allow-unrelated-histories需要知道，我们的源可以是本地的路径
http://blog.csdn.net/lindexi_gd/article/details/52554159

git pull origin master --allow-unrelated-histories
From https://github.com/helloworldtang/mp-demo
 * branch            master     -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 LICENSE   | 201 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 README.md |   3 +
 2 files changed, 204 insertions(+)
 create mode 100644 LICENSE
 create mode 100644 README.md

$ git push origin master
Counting objects: 69, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (56/56), done.
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054
fatal: The remote end hung up unexpectedly
Writing objects: 100% (69/69), 1.57 MiB | 931.00 KiB/s, done.
Total 69 (delta 15), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
Everything up-to-date

解决办法：

git config http.postBuffer 524288000

http://blog.csdn.net/songjinshi/article/details/19074783

在git pull的过程中，如果有冲突，那么除了冲突的文件之外，其它的文件都会做为staged区的文件保存起来。

重现：

$ git pull

A    Applications/Commerce/BookingAnalysis.java
A    Applications/Commerce/ClickSummaryFormatter.java
M    Applications/CommerceForecasting/forecast/Forecast.java
A    Applications/CommerceForecasting/forecast/ForecastCurveProviderCategory.java
M    Applications/CommerceForecasting/forecast/ForecastProvider.java
M    Applications/CommerceForecasting/forecast/InputPropertyItem.java
......

A    Applications/LocalezeImporter/com/tripadvisor/feeds/SingleMenuLocalezeMatcher.java
A    Applications/LocalezeImporter/com/tripadvisor/feeds/TypeCategory.java

Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.

通过git status你会发现下面古怪的事情：

zhonghua@pts/ttys000 $ git status
# On branch sns
# Your branch and 'snsconnect/sns' have diverged,
# and have 1 and 52 different commit(s) each, respectively.
#
# Changes to be committed:
#
#    new file:   src/config/features_daodao.ini
#    new file:   src/config/services.xml
#    new file:   src/config/svnroot/hooks/mailer.conf
#    new file:   src/config/svnroot/hooks/mailer.py
#    new file:   src/config/svnroot/hooks/post-commit
#    new file:   src/config/svnroot/hooks/pre-commit
#    new file:   src/config/svnroot/hooks/prerelease_notifications.py
#    new file:   src/config/svnroot/hooks/run_checks.py
…….

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    _build/
#    css/combined/
#    css/gen/
#    daodao-site.patch
#    daodao-site.patch1
#    js/combined/
#    js/gen/
#    lib/weibo/
#    src/bin/

Pull is not possible because you have unmerged files.

解决：

1.pull会使用git merge导致冲突，需要将冲突的文件resolve掉 git add -u, git commit之后才能成功pull.

2.如果想放弃本地的文件修改，可以使用git reset --hard FETCH_HEAD，FETCH_HEAD表示上一次成功git pull之后形成的commit点。然后git pull. 
【这个很坑。处理merging时，执行git reset --hard FETCH_HEAD后，最原始的代码没有了。坑啊】
注意：

git merge会形成MERGE-HEAD(FETCH-HEAD) 。git push会形成HEAD这样的引用。HEAD代表本地最近成功push后形成的引用。

https://www.cnblogs.com/highriver/archive/2012/01/06/2314175.html

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 branch

git branch 不带参数：列出本地已经存在的分支，并且在当前分支的前面加“*”号标记，例如：
#git branch
* master
newbranch

git branch -r 列出远程分支，例如：
#git branch -r
m/master -> origin_apps/m1_2.3.4
origin_apps/hardware/test
origin_apps/m1
origin_apps/m1_2.3.4
origin_apps/master

git branch -a 列出本地分支和远程分支，例如：
#git branch -a
* master
newbranch
remotes/m/master -> origin_apps/m1_2.3.4
remotes/origin_apps/hardware/test
remotes/origin_apps/m1
remotes/origin_apps/m1_2.3.4
remotes/origin_apps/master

git branch 创建一个新的本地分支，需要注意，此处只是创建分支，不进行分支切换，例如：
#git branch newbranch2
#git branch
* master
newbranch
newbranch2
当前的分支依然是master，不进行切换。

git branch -m | -M oldbranch newbranch 重命名分支，如果newbranch名字分支已经存在，则需要使用-M强制重命名，否则，使用-m进行重命名。
git branch -d | -D branchname 删除branchname分支
git branch -d -r branchname 删除远程branchname分支

例子：
git help branch中的一个例子：
$ git clone git://git.kernel.org/pub/scm/.../Linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14
$ git checkout my2.6.14
第三行符合git branch <branchname> [<start-point>]的格式，即以v2.6.14为start-point，创建新的本地分支branchname。

查看分支git branch [-r | -a]：

1.Git branch查看本地所有分支

2.git branch -r查看远程所有分支
3.git branch -a查看本地和远程所有分支

如图，一般当前本地分支前带有“*”号且为绿色，远程分支为红色

 新建分支git branch [-f] <branchname>：

新建一个分支，但不切换。如图新建了test分支，但是目前依旧在dev5.7分支上。

你可以使用 git checkout -b <branchname> 新建并切换至新分支

删除分支git branch (-d | -D) <branchname>：

1.git branch -d <branchname>删除本地分支，其中<branchname>为本地分支名

2.git branch -d -r <branchname>删除远程分支，其中<branchname>为本地分支名

删除后，还要推送到服务器上才行，即git push origin :<branchname>

如图删除本地test分支，使用-D则表示强制删除，相当于 --delete --force

重命名分支 git branch (-m | -M) <oldbranch> <newbranch>：

如图重命名oldbranch为newbranch，使用-M则表示强制重命名。

如果你需要重命名远程分支，推荐的做法是：

1. 删除远程待修改分支
2. push本地新分支名到远程

一、撤销指令

• git checkout还原工作区的功能
• git reset 还原暂存区的功能
• git clean 还没有被添加进暂存区的文件也就是git还没有跟踪的文件可以使用这个命令清除他们
• git revert 撤销本次提交。

我们可以使用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

Check in = 做一次提交

提交的另一种叫法。

Commit History（提交历史）

如果你做了一些改变并且提交，这次提交保存了一个指向上一次提交的指针。所以提交“流”是单向的。提交“流”可以被分割为 分支。

Branch（即另存为）

一个分支是一系列的提交，这个分支可以分成更多的分支。默认分支名是 master，确切的说仅仅是一个可移动的指针。起初，会有一个 master 分支指向了你的最后一次提交。当你每一次提交，指针会自动的移动去指向最后一次提交。

和真正的分支一样，它也可以被进一步的拆分。你可以在每一个分支上独立的工作。比如，同一时刻使用 Windows XP 和 Windows 7 在不同的版本下相互独立的进行工作。可以把一个基本的 Linux 拥有各种不同的风格想象成不同分支。

https://zhuanlan.zhihu.com/p/19845650

HEAD

Gi t中的 HEAD 是指向当前分支引用的指针，相应地也就是一个指向你的最后一次提交的指针。通常可以简单的认为 HEAD 就是你的最后一次提交的快照。

Tag（书签）

分支可能变得复杂，tag 在这里可以拯救你。 Tag 就像一个书签。创建后可以指向任何分支的任意地方的一次特定的提交。不像分支，比如 master 分支指向了最后一次提交，而 tag 通常可以指向特定的一次提交。

一个 tag 代表了特定分支在某一个时刻的特定版本。


更多详细 Git Object: Tag | Git Tag | GitGuys.com
[资源： Git objects: the tag]

Index（ 暂存区）

这里的 Index 就是你打算的下一次提交。从根本上来说它就是一个 装卸码头你可以决定哪些改动被运走。由于工作目录和 Git 已经保存的内容在本质上是分离的，这允许开发者创建他们想要的提交。既然在 Git 保存数据之前有了这一个暂存区，你获得了更多的灵活性和控制权。


更多详细 What is the deal with the Git Index? What is the Git Index? - GitGuys

作者：范洪春
链接：https://zhuanlan.zhihu.com/p/19845650
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

This should be understood in the context of GitHub forks (where you fork a GitHub repo at GitHub before cloning that fork locally)

• • upstream generally refers to the original repo that you have forked
    (see also "Definition of “downstream” and “upstream”" for more on upstream term)
  • origin is your fork: your own repo on GitHub, clone of the original repo of GitHub

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

在 Git 中忽略文件

你是不是很烦那些编译过的文件 (比如 .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值。为了便于大家理解，先把结论放在前面：

1. “^”代表父提交,当一个提交有多个父提交时，可以通过在”^”后面跟上一个数字，表示第几个父提交，”^”相当于”^1”.
2. ~<n>相当于连续的<n>个”^”.
3. checkout只会移动HEAD指针，reset会改变HEAD的引用值。

使用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.

1. “^”代表父提交,当一个提交有多个父提交时，可以通过在”^”后面跟上一个数字，表示第几个父提交，”^”相当于”^1”.
2. ~<n>相当于连续的<n>个”^”.
3. checkout只会移动HEAD指针，reset会改变HEAD的引用值。

http://www.cnblogs.com/softidea/p/4967607.html