git-2.2.0.64_Git 2.0有什么新功能？

git-2.2.0.64

At the end of May, Git’s primary developer, Junio C Hamano, announced on their mailing list the much awaited release of Git 2.0. If you go through the release notes, you will find that there are quite a few changes that have been welcomed by the community.

5月底，Git的主要开发人员Junio C Hamano 在他们的邮件列表中宣布了期待已久的Git 2.0版本。 如果仔细阅读发行说明 ，您会发现社区已经对很多更改进行了欢迎。

In this article, I’ll provide an overview of these changes. We will see two big changes that are creating waves, followed by a few miscellaneous ones.

在本文中，我将概述这些更改。 我们将看到两个巨大的变化正在产生浪潮，随后是一些其他变化。

git push默认行为 (git push Default Behaviour)

If you use Git for your projects, you should know that the general format for pushing code looks like the following:

如果在项目中使用Git，则应该知道推送代码的一般格式如下：

git push [remote_name] [local_branch]:[remote_branch]

If you are disciplined in your habits and use this syntax, you would not even notice this change in Git. However, if you were lazy and just executed git push, you would have probably received the following message:

如果您养成习惯并使用此语法，那么您甚至不会注意到Git中的这一更改。 但是，如果您懒惰并只是执行git push ，则可能会收到以下消息：

warning: push.default is unset; its implicit value is changing in 
 Git 2.0 from 'matching' to 'simple'. To squelch this message 
 and maintain the current behavior after the default changes, use: 

   git config --global push.default matching

 To squelch this message and adopt the new behavior now, use: 

   git config --global push.default simple

In Git 1.x, the default behaviour is set to matching. This means that all your local branches that have matching branches on the remote are pushed. However, in Git 2.0, the default is changed to simple, which would push only your current branch to the remote branch with the same name. If you want to continue with matching, as in 1.x, you can always change the default.

在Git 1.x中，默认行为设置为matching 。 这意味着将推送所有在远程具有匹配分支的本地分支。 但是，在Git 2.0中，默认设置更改为simple ， 这只会将当前分支推送到具有相同名称的远程分支。 如果您要继续进行matching ，如1.x中所示，则始终可以更改默认值。

对git add更改 (Changes to git add)

Git 2.0 brings some changes in the git add command.

Git 2.0在git add命令中带来了一些变化。

取消追踪已删除的文件 (Untracking Removed Files)

You would often find the following output on a git status when you deleted files:

删除文件时，通常会在git status下找到以下输出：

# On branch master
  # Changes not staged for commit:
  #   (use "git add/rm <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #   deleted:    my_file1
  #   deleted:    my_file2

In Git 1.x, git add ignores files that were removed from your repository and you would have to remove them separately. With Git 2.0, git add dir/ will notice removed files and stage the changes for your commit. You can add --ignore-removal if you want to stage only new or modified files.

在Git 1.x中， git add忽略从存储库中删除的文件，而您必须分别删除它们 。 使用Git 2.0时， git add dir/会注意到已删除的文件并为您的提交git add dir/更改。 如果只想--ignore-removal新文件或修改过的文件，则可以添加--ignore-removal 。

git add -u (git add -u)

Regular Git users frequently use the git add -u command. This command stages the changes in all tracked files for a commit. However, in Git 1.x, one drawback of the commit was that it worked on files within the directory from where the command was run. With Git 2.0, this command is a tree-wide operation, meaning it searches for changed files in your whole repository and adds them, irrespective of where you run the command.

普通的Git用户经常使用git add -u命令。 此命令暂存所有跟踪文件中的更改以进行提交。 但是，在Git 1.x中，提交的一个缺点是它可以处理运行命令的目录中的文件。 在Git 2.0中，此命令是树状操作，这意味着它会在整个存储库中搜索更改的文件并将其添加，而不管您在何处运行该命令。

If that’s confusing, let me try to explain with an example. Let’s say you have in your repository two files with changes — README and src/my_file. If you change your directory to src and then run git add -u, in Git 1.x only my_file gets added. In Git 2.0, both files are added. If you ran the command from the parent directory, both files are added irrespective of the version.

如果这令人困惑，那么让我尝试举例说明。 假设您的存储库中有两个具有更改的文件README和src/my_file 。 如果您将目录更改为src ，然后在Git 1.x中运行git add -u ，则仅添加my_file 。 在Git 2.0中，两个文件都被添加。 如果从父目录运行该命令，则无论版本如何，都会添加两个文件。

杂项变化 (Miscellaneous Changes)

Finally, we’ll summarize here some other changes you might want to be aware of.

最后，我们在这里总结一些您可能需要注意的其他更改。

git pull (git pull)

Git pull now has a new configuration variable, pull.ff, which can be set to allow it to accept only fast forward branches, which eliminates merges, and therefore leads to no conflicts.

Git pull现在有了一个新的配置变量pull.ff ，可以对其进行设置，使其仅接受快速前进分支 ，从而消除了合并，因此不会导致冲突。

git svn (git svn)

If you use Git with other version control systems, you would probably have come across the command git svn, which would serve as the base command for all Subversion-related functions.

如果将Git与其他版本控制系统一起使用，则可能会遇到命令git svn ，它将作为所有与Subversion相关的功能的基本命令 。

Remote tracking branches for git svn were created under refs/remotes in Git 1.x. However, they will be created under refs/remotes/origin, which can be changed with the --prefix option. git svn is not such a popular feature as most organizations have moved on to Git and this will probably not affect a lot of people.

git svn远程跟踪分支是在Git 1.x中的refs/remotes下创建的。 但是，它们将在refs/remotes/origin下创建，可以使用--prefix选项进行更改。 git svn并不是一个受欢迎的功能，因为大多数组织都已转移到Git，这可能不会影响很多人。

.gitignore文件 (.gitignore Files)

Trailing whitespaces in .gitignore files are warned and ignored, unless they are quoted. This change is not backwards compatible.

.gitignore文件中的.gitignore空格将被警告和忽略，除非用引号引起来。 此更改不向后兼容。

git grep (git grep)

The grep command within Git enabled you to search within all branches. You can now make it behave like a native grep when -h (no header) and -c (count) options are given.

Git中的grep命令使您可以在所有分支中进行搜索。 现在，当给出-h (无标头)和-c (计数)选项时，可以使其表现得像本地grep。

删除远程帮助程序界面 (Removal of Remote Helper Interfaces)

The remote helper interfaces for Mercurial and Bazaar, which were found under contrib/, are no longer a part of Git and are now maintained as separate repositories as third party plug-ins.

在contrib/下找到的Mercurial和Bazaar的远程帮助程序接口不再是Git的一部分，现在作为第三方插件作为单独的存储库进行维护。

期待 (Looking Forward)

Git is no doubt the most popular version control management system, and the discussions on HackerNews regarding the release notes proves that. Git 2.0 has its fair share of new features, but so did every version of Git 1.x. There are a few backwards incompatible changes, but they likely will not affect you. If you use Git, the future looks bright. If you don’t, when are you joining the club?

Git无疑是最受欢迎的版本控制管理系统， 关于HackerNews的发行说明的讨论证明了这一点。 Git 2.0有很多新功能，但是每个版本的Git 1.x都有。 有一些向后不兼容的更改，但它们可能不会影响您。 如果您使用Git，那么前途一片光明。 如果没有，您什么时候加入俱乐部？

翻译自: https://www.sitepoint.com/whats-new-git-2-0/

git-2.2.0.64