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

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

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

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

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

让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手册页是获取更多信息的最佳资源。

如何“标记”一组特定的修订

如何“标记”、“标记”或“发布”特定文件集的特定修订集，以便以后随时可以提取该修订集？

使用git标记命令。

要简单地“标记”当前修订，只需运行。。

git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'

要列出当前标记，只需运行不带参数的git标记或-l（小写l）：

$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname

要删除标记，请使用-d标志：

$ git tag -d thetagname 
Deleted tag 'thetagname'
$ git tag
[no output]

要标记特定（先前）提交，只需执行。。

git tag [tag name] [revision SHA1 hash]

例如：

git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b

注意：默认情况下，git创建一个“轻量级”标记（基本上是对特定修订的引用）。“正确”的方法是使用-a标志。这将启动编辑器，请求标记消息（与请求提交消息相同，您也可以使用-m标志在命令行上提供标记消息）。使用带注释的标记创建一个具有自己的ID、日期、tagger（作者）和可选的GPG签名（使用-s标记）的对象。有关这方面的更多信息，请参阅本文

git tag mytagwithmsg -a -m 'This is a tag, with message'

要列出带有注释的标记，请使用-n1标志显示每个标记消息的1行（-n245显示每个注释的前245行，依此类推）：

$ git tag -l -n1
mytagwithmsg    This is a tag, with message

有关更多信息，请参阅git标记（1）手册页

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

不要惊慌

如果我做了一些承诺，然后做了一些可怕的事情，比如重新启动，而现在一些东西甚至所有东西都好像丢失了呢？（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社区书。说真的，一个问题中的20多个问题绝对不会简明扼要。Git社区书有HTML和PDF两种格式，可以用清晰、格式良好、经过同行评审的答案回答您的许多问题，并且格式可以让您直接解决手头的问题。

唉，如果我的帖子真的让你不安，我会删除它。说吧。