.gitignore文件示例：

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

…or create a new repository on the command line

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

…or push an existing repository from the command line

git remote add origin https://github.com/helloworldtang/docs.gitgit 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

参考：

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

因为他们是两个不同的项目，要把两个不同的项目合并，git需要添加一句代码，在git pull，

假如我们的源是origin，分支是master，那么我们 需要这样写git pull origin master --allow-unrelated-histories需要知道，我们的源可以是本地的路径

git pull origin master --allow-unrelated-historiesFrom https://github.com/helloworldtang/mp-demo * branch            master     -> FETCH_HEADMerge 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 masterCounting 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 10054fatal: The remote end hung up unexpectedlyWriting 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 unexpectedlyEverything 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/LocalezeImporter/com/tripadvisor/feeds/SingleMenuLocalezeMatcher.java

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. 

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 就是你的最后一次提交的快照。

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

Git branch

git branch -r 列出远程分支，例如：

git branch -a 列出本地分支和远程分支，例如：

git branch 创建一个新的本地分支，需要注意，此处只是创建分支，不进行分支切换，例如：

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

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

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

2.git branch -r查看远程所有分支

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

 新建分支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看一下，暂存区的内容就被还原了。

工作流程：

•在自己的分支上添加文件

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

git pull = git fetch + git merge

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

git init 产生的目录解释

错误提示：fatal: remote origin already exists.

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之前的状态

http://blog.csdn.net/qyf_5445/article/details/8737913

1

$ ssh-keygen -t rsa -C "youremail@yourcompany.com” -f ~/.ssh/id-rsa

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的配置中。

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

git config

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

git st # git statusgit ci  # git commitgit br # git branchgit co # git checkoutgit mg # git mergegit 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)操作相关命令

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 代表了特定分支在某一个时刻的特定版本。

更多详细

[资源： ]

Index（ 暂存区）

这里的 Index 就是你打算的下一次提交。从根本上来说它就是一个

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

更多详细

作者：范洪春

链接：https://zhuanlan.zhihu.com/p/19845650

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

This should be understood in the context of (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 "" 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 中忽略文件

你是不是很烦那些编译过的文件 (比如 .pyc) 出现在你的 Git 仓库中？或者说你已经受够了已经把它们都加进了 Git 仓库？好了，这有个办法可以让你告诉 Git 忽略掉那些特定的文件和文件夹。只需要创建一个名为 .gitignore 然后列出那些你不希望 Git 跟踪的文件和文件夹。你还可以添加例外，通过使用感叹号(!)。

*.pyc*.exemy_db_config/!main.pyc

 git log ，不过，这里还有三个你应该知道的选项。

• --oneline– 压缩模式，在每个提交的旁边显示经过精简的提交哈希码和提交信息，以一行显示。
• --graph– 图形模式，使用该选项会在输出的左边绘制一张基于文本格式的历史信息表示图。如果你查看的是单个分支的历史记录的话，该选项无效。

假设你不小心提交了些你不想要的东西，不得不做一次强制重置来恢复到之前的状态。然后，你意识到在这一过程中你丢失了其它一些信息并且想要把它们找回来，或者至少瞅一眼。这正是git reflog可以做到的。

然而，一个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和引用的值

$ cat .git/HEAD

$ cat .git/refs/heads/master

git commit -a -m "c5"

先切换到master分支，然后合并br1 br2 br3，会新生成一个提交3b03.

这时候，运用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