非常好的关于合并冲突的帖子-GitGuys：合并冲突-冲突和解决方案

这个博客真的很棒——说明性的，干净的例子，可以理解。绝对值得一看。

推拉式更改

简单来说，只需执行gitpush和gitpull。更改被合并，如果有冲突，git会通知您，您可以手动解决。

当您第一次推送到远程存储库时，需要执行git推送源主机（主机是主分支）。从那时起，你只需按一下数字键。

带有git Push--标记的Push标记。

如何设置共享团队存储库？

这里描述了如何建立一个普通的存储库——但是如何建立一种团队存储库，每个人都可以从中提取和推送到其中？

使用共享NFS文件系统

例如，假设您的团队已经拥有可以使用的共享组成员资格。

mkdir /your/share/folder/project.git
cd /your/share/folder/project.git
newgrp yourteamgroup # if necessary
git init --bare --shared

要开始使用此存储库，最简单的方法是从您已经使用过的本地存储库开始：

cd your/local/workspace/project
git remote add origin /your/share/folder/project.git
git push origin master

其他人现在可以克隆并开始工作：

cd your/local/workspace
git clone /your/share/folder/project.git

使用SSH

在目标服务器上设置用户帐户。无论您使用没有密码的帐户、有密码的帐户还是使用authorized_keys，都取决于您所需的安全级别。有关更多信息，请参阅通过SSH配置Git。

如果所有开发人员都使用相同的帐户访问此共享存储库，则不需要使用上述--shared选项。

以与上述相同的方式启动存储库后，您可以执行如下初始推送：

cd your/local/workspace/project
git remote add origin user@server:/path/to/project.git
git push origin master

看到与上面的相似之处了吗？另外，如果帐户有密码，唯一可能发生的事情就是SSH请求密码。如果您在没有密码的帐户上得到此提示，则SSH服务器可能已禁用PermitEmptyPassword。

克隆现在看起来像这样：

cd your/local/workspace
git clone user@server:/path/to/project.git

如何跟踪远程分支

假设有一个您从中克隆本地存储库的远程存储库，并且假设该远程存储库上有一个名为“some_branch”的分支，下面是如何在本地跟踪它：

# list remote branches
git branch -r

# start tracking one remote branch
git branch --track some_branch origin/some_branch

# change to the branch locally
git checkout some_branch

# make changes and commit them locally
....

# push your changes to the remote repository:
git push

还有一项我认为应该在这个列表中，可能对初学者非常有用：

不要惊慌

如果我做了一些承诺，然后做了一些可怕的事情，比如重新启动，而现在一些东西甚至所有东西都好像丢失了呢？（Rebase似乎是第一次吸引大多数人的方法，所以我专注于此。虽然git Rebase--abort有很大帮助，但有时你会发现，在交互式Rebase过程中，你把编辑搞砸了，比如，让Rebase完成，现在你想把你的旧东西拿回来。还有一些事情，比如过滤器分支…）

git的一个关键原则是它永远不会删除您提交的任何内容。（“什么，从来没有？”“不，从来没有！”。可能需要仔细挖掘才能找到以前的工作，但如果你早些时候成功地提交了一些git，那么，例如，即使是你的一系列因悲剧性的重新启动错误而被破坏的提交仍然存在，通常至少一个月（从技术上讲，直到“重新启动”到期）。

重要的是要记住，每个分支名称都标记或指向“提交ID”。这些是像7cc5272这样有趣的数字。您所做的许多事情，如向分支添加新的提交，都会使分支名称指向一个新的、不同的commit-ID。每个提交ID都有一个指向以前提交ID的链接，这实际上构成了一个充满提交的“分支”。

rebase条目谈到“重写历史”，像gitfilter branch这样的命令也会“重写历史，”但它们不是通过销毁以前的历史，而是通过添加新的历史来实现。一旦新的历史记录就位，git将“四处移动标签”，使其看起来历史已经改变。如果你在修复讨厌的bug分支上，并执行git重基并设法破坏东西，那么修复讨厌的错误标签现在指的是残骸，但原始版本仍然存在。特别是Rebase创建了一个临时（非移动，非分支）标签，拼写为ORIG_HEAD，可以让您找到它们。filter branch命令还保存所有原始名称。在某些情况下，可能没有明显的名称，但始终可以找到提交。如果有必要的话，找一个“git guru”，并解释你做了什么导致了残骸。

（命令git reflog show也可以帮助查找提交ID。）

如果您发现了您认为的部分或全部以前的工作，请尝试：

git log <commit-ID>   # ORIG_HEAD after a bad rebase, for instance
git show <commit-ID>  # or some long SHA1 value you can still see in a window

如果它看起来正确或有用，请为其命名：

git branch recover-my-stuff ORIG_HEAD

一切又回来了！事实上，现在你的糟糕的重新基础和你的原始工作都在你的git repo中“永远”（或者至少，直到你删除分支名称并让几个月过去，然后它们被垃圾收集）。您可以为任意多个恢复的提交添加任意多个名称。（分支名称实际上是免费的，除了弄乱了git分支输出之外，当然，它们还可以防止提交被垃圾收集。如果您喜欢，也可以在特定的提交ID上添加标记。）

如何将其配置为忽略文件：

让git忽略您不希望跟踪的文件的功能非常有用。

要忽略一个文件或一组文件，请提供模式。git的模式语法相当简单，但功能强大。它适用于我将在下面提到的所有三个不同的文件。

空行不忽略任何文件，通常用作分隔符。以#开头的行用作注释。这个前缀是可选的，将否定模式。任何匹配的否定模式都将覆盖优先级较低的模式。支持高级表达式和通配符示例：模式：*。[oa]将忽略存储库中以.o或.a结尾的所有文件（对象和存档文件）如果一个模式有一个以斜杠结尾的目录，git将只匹配该目录及其下的路径。这将排除匹配中的常规文件和符号链接。前导斜杠将匹配该路径名中的所有文件。示例：模式/*.c将与文件foo.c匹配，但不匹配bar/b真棒.c

gitignore（5）手册页中的好例子：

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

通常有三种不同的方法可以忽略未跟踪的文件。

1） 对存储库的所有用户忽略：

将名为.gitignore的文件添加到工作副本的根目录中。

编辑.gitignore以匹配您的首选项，哪些文件应该/不应该被忽略。

git add .gitignore 

当你完成任务后再去做。

2） 仅忽略存储库副本：

在工作副本中添加/编辑文件$GIT_DIR/info/exclude，使用您的首选模式。

示例：我的工作副本是~/src/project1，因此我将编辑~/src-project1/.git/info/exclude

你完了！

3） 在所有情况下，在您的系统中忽略：

系统的全局忽略模式可以放在一个名为whatever的文件中。

我个人的名字叫做~/.giglobalignore

然后，我可以用以下行编辑~/.gitconfig文件，让git知道这个文件：

core.excludesfile = ~/.gitglobalignore

你完了！

我发现gitignore手册页是获取更多信息的最佳资源。