1

我正在考虑开始使用 Gitflow。我注意到默认情况下分支以正斜杠结尾。

IE

修补程序/发布/

等等。

正斜杠是否会导致任何问题，因为 git 使用正斜杠作为文件夹分隔符。

它会导致从 git 部署带有正斜杠的任何问题吗？

我们可以使用另一个前缀，例如连字符吗？

两种方法的优缺点是什么。

提前致谢

4

3 回答 3

1

我将重新排列这些问题。

我们可以使用其他前缀，例如连字符吗？

您可以使用任何您想要的名称格式，只要您尊重您自己的操作系统（操作系统——Windows、MacOS、Linux 等）的限制。使用连字符并不能解决这些限制。

正斜杠是否会导致任何问题，因为 git 使用正斜杠作为文件夹分隔符。

Git不以这种方式使用它。这是你的操作系统。文件路径名的意思是“在目录中a/b查找名称”，即使在 Windows 上也是如此。ba

它会导致从 git 部署带有正斜杠的任何问题吗？

如果您避免操作系统的限制，则不会。让我们快速看一下这些。

背景

Git 会在不同时间将分支名称（或任何其他引用名称）写入以.git/refs/目录为根的路径中。任何分支B的“全名”例如是, , , 。这些将最终创建名为,等的文件。在每个文件中，Git 存储一个简单的值：目标对象的哈希 ID（提交哈希，用于分支名称）。refs/heads/Brefs/heads/masterrefs/heads/developrefs/heads/feature/tallrefs/heads/bugs/short.git/refs/heads/master.git/refs/heads/feature/tall

在其他时候，Git 会将所有这些名称写入一个“平面文件”：本质上，它是键值存储数据库的一个非常糟糕的替代品。每当 Git 使用自己的数据库而不是操作系统的文件系统时，Git 都会避免操作系统的限制。但由于并非一直如此，因此您必须尊重操作系统的限制。

目录（或“文件夹”）永远不是文件，反之亦然

假设您有一个名为x. 这意味着 Git 有时会创建一个文件来.git/refs/heads/x保存x.

如果您现在尝试创建一个名为 的分支x/y，Git 可能需要创建一个名为的文件.git/refs/heads/x/y来保存x/y. 但是已经有一个名为的文件x，因此不可能创建一个名为的目录x来保存一个名为y.

这意味着您必须避免使用一个名称在/被视为路径名称分隔符时成为另一个名称的前缀。

（同样的规则也适用于遥控器的名称。如果您愿意，可以命名两个不同的遥控器hq/a和hq/b，但如果这样做，则不能命名任何遥控器hq。）

外壳折叠

假设您的操作系统折叠 case。也就是说，假设您创建了一个名为 的文件ReadMe.txt，然后要求打开或查看或创建或写入一个名为readme.txt. 这是否会创建一个与现有文件不同的新文件，还是重新使用现有文件？如果您的操作系统重新使用现有的.大小写字母的不同组合，最终将重新使用原始大小写。readme.txtReadMe.txtReadMe.txtReadMe.txt

这意味着如果您创建一个名为 的分支master，然后尝试创建另一个名为 的分支MASTER，您的操作系统将重新使用小写名称。从某种意义上说，这会“混淆”Git：Git 认为master和MASTER是不同的分支，但您的操作系统坚持将两个不同的分支值存储在一个文件中。

这同样适用于路径中的目录名称。如果你命名一个分支feature/tall和第二个分支Feature/wide，Git 会认为应该总是命名第二个分支Feature/wide——但是当 Git 去创建一个新文件.git/refs/heads/Feature/wide时，你的操作系统会对自己说：“啊哈，我应该重新使用现有的小写字母—— ffeature目录并将其创建为.git/refs/heads/feature/wide." 这再次让 Git 感到困惑。

当这种情况发生时，行为有点难以预测。如果您的操作系统确实对文件进行大小写折叠，1您应该完全避免这种情况。这里的一个好习惯是选择一个大小写——通常只小写——并坚持下去。

1现代操作系统，包括 Linux 和 MacOS，实际上选择是否在每个文件系统的基础上进行大小写折叠。这意味着您可以设置一个完全区分大小写的文件系统——文件与文件readme.txt完全不同ReadMe.txt——并使用它来解决分支名称的问题。但是，无论如何，Linux 默认对其所有本机文件系统都完全区分大小写。

Unicode 规范化

操作系统执行的大小写折叠往往仅限于 ASCII：é例如，它们可能没有大写的概念。如果他们使用 Unicode 来表示“非 ASCII”字符（重音字符、阿拉伯语、中文、西里尔文、韩文、希伯来字母等），则尤其如此。但是，如果操作系统对这些更广泛的字符集完全支持 Unicode，它通常会使用 UTF-8 编码，2它将 Unicode 编码从操作系统级别的操作中“隐藏”起来，将路径名视为字节字符串。“高阶”非 ASCII 字符，即使经过编码，也不会与 ASCII 等普通字符发生冲突/，因此操作系统/在选择创建或使用目录时，不会影响非 ASCII 字符。

Unicode 规范化的过程对于没有经历过的人来说有点神秘。有关详细信息，请参阅有关 Unicode 等效性的 Wikipedia 页面，但简而言之，请考虑将 ü 表示为单个字符“u with umlaut”或组合序列“umlaut, u”的想法。如果操作系统想要折叠大小写，它可能还应该将这两个不同的字节序列视为命名同一个文件。

MacOS 执行Unicode 规范化来处理这个问题（HFS+ 中的 NFD；参见这个 StackOverflow 帖子及其各种链接）。这也影响了 Git（从 Git 2.1 版开始，它有处理它的代码，尽管在 Git 2.8.4 之前有一个错误修复）。我没有这方面的经验，但总的来说我只是建议避免这个问题：坚持使用简单的 ASCII 分支（和其他参考）名称。

2 Windows使用UTF-16-LE，但效果差不多。

于 2017-04-23T10:30:18.533 回答
0

我遇到的唯一问题是，如果您有master分支，则无法创建名为的分支master/foo/bar，因为它以已经存在的分支名称开头。

我使用 [fix/feature|path]/{issue-number}/[description/]{destination} 模式

例子：

  • fix/42/master 告诉这个分支/pr 是 master 分支上问题编号 42 的修复

  • feature/23/1.4 告诉这是一个功能 23，用于下一个小版本 1.4

然后再次

  • feature/123/create-red-button/master 在master分支上添加一个红色按钮（卡号123）

等等

于 2017-04-23T09:51:30.967 回答
0

目前，您可以在初始化 gitflow 时设置不同的后缀，git flow init如下所示：

❯ git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/] feature-
Release branches? [release/] release-
Hotfix branches? [hotfix/] hotfix-
Support branches? [support/] support-
Version tag prefix? [] v

如您所见，括号中是默认值（正斜杠作为后缀），但您可以用yourbranchname-覆盖它（最后的破折号）

于 2020-08-22T20:56:29.223 回答