git分支管理最佳实践_管理Git仓库的6个最佳实践-CSDN博客

git分支管理最佳实践

可以访问源代码可以分析应用程序的安全性。但是，如果没有人真正看过代码，问题就不会被发现，即使人们正在积极地看代码，通常也要看很多东西。幸运的是，GitHub有一个活跃的安全团队，最近，他们发现了一个特洛伊木马，该木马已提交到多个Git存储库中，甚至潜入了回购所有者。尽管我们无法控制其他人如何管理自己的存储库，但我们可以从他们的错误中学习。为此，本文回顾了将文件添加到自己的存储库中的一些最佳实践。

了解您的回购

对于安全的Git存储库，这可以说是零规则。作为项目维护者，无论您是自己启动它还是从他人那里采用它，了解自己存储库中的内容都是您的工作。您可能没有代码库中每个文件的存储列表，但是您需要了解所管理内容的基本组成部分。如果几十个合并后出现一个杂散文件，您将可以很容易地发现它，因为您不知道它的用途，并且需要检查它以刷新内存。发生这种情况时，请查看文件，并确保您确切了解为什么需要这样做。

禁止二进制斑点

Git用于文本，无论是用纯文本编写的C或Python还是Java，还是JSON，YAML，XML，Markdown，HTML或类似的东西。 Git对于二进制文件不是很理想。

两者之间的区别是：


   
   
    
    
     
     $ 
     
     cat hello.txt
     
     

This is plain text.
     
     

It 
     
     's readable by humans and machines alike.

Git knows how to version this.



$ git diff hello.txt 

diff --git a/hello.txt b/hello.txt

index f227cc3..0d85b44 100644

--- a/hello.txt

+++ b/hello.txt

@@ -1,2 +1,3 @@

 This is plain text.

+It' s readable by humans and machines alike.
     
     

 Git knows how to version this.

还有这个：


   
   
    
    
     
     $ 
     
     git diff pixel.png
     
     


     
     diff 
     
     --git a 
     
     / pixel.png b 
     
     / pixel.png
     
     

index 563235a..7aab7bc 
     
     100644 
     
     

Binary files a 
     
     / pixel.png and b 
     
     / pixel.png differ
     
     


     
     

$ 
     
     cat pixel.png
     
     

 PNG
     
     

▒
     
     

IHDR7n  
     
     $gAMA   
     
     

               abKGD݊ tIME 
     
     


     
     

                          -2R  
     
     

IDA c 
     
     `   
     
     !   
     
     3 
     
     % tEXtdate:create2020-06-11T11: 
     
     45 :04+ 
     
     12 :00  r. 
     
     % tEXtdate:modify2020-06-11T11: 
     
     45 :04+ 
     
     12 :00  ʒIEND B 
     
     `

二进制文件中的数据无法以与解析纯文本相同的方式进行解析，因此，如果二进制文件中发生任何更改，则必须重写整个内容。一个版本与另一个版本之间的唯一区别是所有内容，它们的总和很快。

更糟糕的是，您（Git存储库维护者）无法合理地审计二进制数据。这违反了零规则：知道存储库中的内容。

除了常用的POSIX工具之外，您还可以使用git diff检测二进制文件。当您尝试使用--numstat选项来比较二进制文件时，Git返回空结果：


   
   
    
    
     
     $ 
     
     git diff 
     
     --numstat 
     
     / dev 
     
     / null pixel.png 
     
     | 
     
     tee 
     
     

-     -   
     
     / dev 
     
     / null = 
     
     > pixel.png
     
     

$ 
     
     git diff 
     
     --numstat 
     
     / dev 
     
     / null file.txt 
     
     | 
     
     tee 
     
     


     
     5788  
     
     0   
     
     / dev 
     
     / null = 
     
     > list.txt

保留第三方库为第三方

第三方库也不例外。尽管这是开放源代码的众多优势之一，您可以自由地重用和重新分配未编写的代码，但是有很多充分的理由不将第三方库存储在您自己的存储库中。首先，除非您自己检查了所有代码（以及将来的合并），否则您无法完全担保第三方。其次，当您将第三方库复制到您的Git存储库中时，它会将焦点分散到真正的上游资源之外。对库有信心的人从技术上仅对库的主副本有信心，而不对随机回购中的副本有信心。如果您需要锁定特定版本的库，请为开发人员提供项目所需版本的合理URL，或者使用Git Submodule 。

抵抗盲目的git add

如果您的项目已编译，请不要使用git add . （其中.是当前目录或特定文件夹的路径），是添加任何新内容的简便方法。如果您不是手动编译项目，而是使用IDE为您管理项目，那么这尤其重要。在IDE管理项目时，跟踪添加到存储库中的内容非常困难，因此仅添加您实际编写的内容而不是任何新对象弹出项目文件夹非常重要。

如果确实使用git add . ，请在推送前检查登台情况。如果在执行git status时在项目文件夹中看到不熟悉的对象，请在运行make clean或等效命令后找出它的来源以及为什么它仍在项目目录中。这是一种罕见的构建工件，不会在编译期间重新生成，因此在提交之前请三思。

使用Git忽略

为程序员提供的许多便利也非常嘈杂。任何项目，程序，艺术作品或其他艺术作品的典型项目目录中都充斥着隐藏文件，元数据和剩余的工件。您可以尝试忽略这些对象，但是git status噪音越多，您错过某些东西的可能性就越大。

您可以通过维护一个良好的gitignore文件来为您过滤掉这种噪音。因为这是使用Git的任何人的普遍要求，所以有一些入门gitignore文件可用。 Github.com/github/gitignore提供了几个专门构建的gitignore文件，您可以下载这些文件并将其放置到自己的项目中，而Gitlab.com几年前将gitignore模板集成到了回购创建工作流程中。使用这些帮助您为项目建立合理的gitignore策略并坚持下去。

查看合并请求

当您通过电子邮件收到合并或提取请求或补丁文件时，请勿仅对其进行测试以确保其正常工作。阅读进入代码库的新代码并了解其如何产生结果是您的工作。如果您不同意该实现，或者更糟的是，您不理解该实现，请向提交该实现的人发送消息，并要求其进行澄清。质疑希望成为存储库中永久性代码的代码不是社交目的，但是违反用户与用户的社会契约就是不知道您将其合并到什么代码中。