我已经使用git有一段时间了,但我从来没有自己设置过一个新的远程回购,我一直很好奇这样做。我一直在阅读教程,我对如何让“git push”工作感到困惑。

如果我只是简单地使用git push,它会要求我查看一个默认的分支(?)指向?它提供给我的这两个选项之间的区别是什么?

git config --global push.default matching
git config --global push.default simple

匹配只是推我在本地回购上的任何分支,如果它们不匹配,我必须手动告诉它推我有的任何新的本地分支,对吗?这是最好的实践还是简单的最好?


当前回答

来自GIT文档:GIT Docs

下面给出了完整的信息。简而言之,simple只会推送当前工作的分支,而且只有当它在远程上也具有相同的名称时才会这样做。对于初学者来说,这是一个非常好的设置,将成为GIT 2.0中的默认设置

而匹配将在本地推送远程上具有相同名称的所有分支。(与你目前的工作部门无关)。这意味着可能会推送许多不同的分支,包括那些您甚至不想共享的分支。

在我个人的使用中,我通常使用不同的选项:current,它推动当前工作的分支,(因为我总是为任何更改而分支)。但对于初学者,我建议简单一点

push.default Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are: nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit. current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows. upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch's name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners. This mode will become the default in Git 2.0. matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there). To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control. This is currently the default, but Git 2.0 will change the default to simple.

其他回答

Git v2.0发布说明

向后兼容性说明

当git push [$there]没有说要推什么时,我们使用 到目前为止,传统的“匹配”语义(所有的分支都发送了 到远程只要已经有同名分支 在那里)。在Git 2.0中,默认的语义是“simple”, 它把:

只有当前的分支才能与同名的分支,而且只有 当将当前分支设置为与该远程集成时 分支,如果你正在推送到与你从中获取的相同的远程;或 只能将当前分支转到具有相同名称的分支,如果 正在推到一个不是你通常从那里获取的遥控器。

您可以使用配置变量“push.default”进行更改 这一点。如果你是一个想继续使用的老前辈 “匹配”语义,可以将变量设置为“匹配”,用于 的例子。阅读文档了解其他可能性。

当git add -u和git add -A在子目录中运行时 如果没有指定要在命令行上添加哪些路径,它们 为了与git commit -a和保持一致,对整个树进行操作 其他命令(这些命令仅用于操作当前 子目录)。输入git add -u。或者git add -A。如果你想的话 将操作限制在当前目录。

git add <path>现在与git add -A <path>相同,因此 Git add dir/会注意到你从目录中删除的路径 记录移除过程。在旧版本的Git中,Git add <path>使用 忽略删除。你可以输入git add——ignore- remove <path> to 如果确实需要,只添加<path>中添加或修改的路径。

Git push可以推送所有分支,也可以只推送一个分支,这取决于以下配置:

推送所有分支

git config --global push.default matching

它将把所有分支推到远程分支,并合并它们。 如果您不想推送所有分支,如果您完全指定了当前分支的名称,则可以推送当前分支,但这与默认情况没有多大区别。

如果分支的上游名称相同,则只推当前分支

git config --global push.default simple

因此,在我看来,最好使用这个选项并逐个分支地推动代码。最好手动和单独地推送分支。

来自GIT文档:GIT Docs

下面给出了完整的信息。简而言之,simple只会推送当前工作的分支,而且只有当它在远程上也具有相同的名称时才会这样做。对于初学者来说,这是一个非常好的设置,将成为GIT 2.0中的默认设置

而匹配将在本地推送远程上具有相同名称的所有分支。(与你目前的工作部门无关)。这意味着可能会推送许多不同的分支,包括那些您甚至不想共享的分支。

在我个人的使用中,我通常使用不同的选项:current,它推动当前工作的分支,(因为我总是为任何更改而分支)。但对于初学者,我建议简单一点

push.default Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are: nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit. current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows. upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch's name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners. This mode will become the default in Git 2.0. matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there). To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control. This is currently the default, but Git 2.0 will change the default to simple.