共计 7736 个字符，预计需要花费 20 分钟才能阅读完成。
如何使用 GITHUB 协作构建项目
介绍
通常，人们希望作为一个团队在同一个 Construct 项目上工作。Construct 支持以文件夹结构保存项目，其中项目的每个部分都保存到一个单独的文件中。这是专门为帮助团队分别处理项目的每个部分而设计的。
然而，尝试手动管理贡献、版本和合并是一个繁琐且容易出错的过程。源代码控制软件就是为了解决这个问题而设计的。存在一些出色的解决方案，例如 SVN 和 Git。虽然这些工具是为传统的编程系统设计的（我们使用它们来开发 Construct 本身），但它们实际上可以处理任何文件，并且特别适用于基于文本的文件。由于 Construct 项目、事件表和布局信息以基于文本的格式保存，因此它非常适合源代码管理。
还有在线源代码控制服务，可以为您处理很多细节，例如托管您的文件。市面上有很多这样的服务，您可以使用其中任何一种。但是，本教程重点介绍 GitHub 的因为它是最受欢迎的服务之一，因此提供了不错的免费套餐，并具有精心设计的网络界面。
源代码管理工具非常有用，以至于许多个人开发人员仍然发现它们很有用，即使他们不在团队中工作。这些工具提供的功能包括准确查看您更改的内容、显示带有描述的更改日志、允许您查看过去任何时候所做的确切更改、回滚到以前的版本、分支以进行实验性更改等等。这对于单独开发的雄心勃勃的项目来说是非常宝贵的，因此即使您不在团队中，也值得学习该过程。
本教程不需要任何付费功能，因此您可以使用 Construct 的免费版和免费的 GitHub 帐户进行试用。
前往下一页开始使用。
CONSTRUCT 的项目文件夹结构
在 Chrome（以及其他基于 Chromium 的浏览器，如 Edge 和 Opera）中，您可以将项目保存到本地文件夹。在使用 Git 等源代码管理时，有必要使用此选项，因为它允许您处理一系列单独的文件，而不是单个 .c3p 文件。
由于您将处理项目文件夹中的单个文件，因此了解其结构以及每个文件夹和文件的用途是值得的。以下是从 Space Blaster 演示项目中保存的整个项目文件夹结构：
首先，主项目文件是根目录中的 .c3proj 文件（实际上只是一个 JSON 文件）。这将存储所有项目设置以及项目中使用的所有内容的列表。项目的其他部分保存在子文件夹中，如下所示：
- eventSheets 以 JSON 格式存储项目中使用的所有事件表。
- objectTypes 和 families 以 JSON 格式存储添加到项目中的所有对象类型和系列的数据。
- images 以 PNG 格式存储所有对象在项目中使用的所有图像。图像文件名可以是非动画对象的对象名称（例如 tiledbackground.png），也可以是动画对象的对象名称、动画名称和帧号（例如 player-default-000.png）。
- layouts 以 JSON 格式存储项目中使用的所有布局，包括图层和所有对象的放置位置。
- 其他文件夹（如图标、音乐和声音）将相应文件夹中的项目文件存储在项目栏中。
如果项目没有任何内容，则某些文件夹可能会丢失。例如，没有族的项目可能会省略族文件夹。但是，如果将任何族添加到项目中，则将创建该族。
UI 状态文件
根文件夹和一些子文件夹中还有几个.uistate.json 文件。这些是单独存储用户界面状态的 JSON 文件，例如当前打开的选项卡。它存储在一个单独的文件中，因为通常您不想共享它。仅仅因为您切换了选项卡而就必须为团队的其他成员记录更改是不必要的，并且可能是问题的根源，因此 Construct 故意将其单独保存，以便您可以排除它。基本上，该文件仅供您使用，团队的其他成员不感兴趣。
源代码管理基础知识
下图显示了源代码管理系统的基本体系结构：
服务器具有项目的主副本。这是将每个人的更改合并到一个地方的版本。
客户拥有自己的独立项目副本，称为他们的工作副本。这意味着每个团队成员的更改不会立即影响服务器，其他团队成员也无法立即看到其他人所做的更改。如果团队成员完成了某个工作单元，并希望合并他们的更改，则他们会将更改推送到服务器，然后合并他们的工作。一旦更改位于项目的服务器副本中，其他团队成员就可以拉取以下载对他们自己的工作副本的任何新更改。
单个工作会话中的典型工作流可能是：
- 首先拉取，这样你就有了项目的最新版本
- 进行一些更改
- 完成后，将更改推送到服务器以提交它们
推送后，下次每个团队成员从服务器拉取时，他们将收到这些更改。
如果进行了更改，则在不提交的情况下拉取，则服务器中的任何更改都应与本地更改合并。通常，源代码管理系统可以自动为您执行此操作。
这个过程的主要问题是冲突：当两个人更改项目的同一部分时，然后尝试同时推动这些更改。第一个人可以正常提交更改，但是当第二个人推送时，服务器会注意到他们还没有拉入其他更改，并会让他们在推送之前这样做。然后，他们将不得不手动合并其他更改，然后再次推送。稍后将对此进行更详细的描述。如果每个人都只在项目的不同部分工作，或者至少协调以确保两个人不会同时更改相同的内容，那么您应该能够避免大多数冲突。
在某些源代码管理系统中，服务器可以位于团队成员的计算机上。但是，设置起来更为复杂。使用像 GitHub 这样的基于 Web 的服务意味着他们的服务充当服务器。
设置 GITHUB
要在 GitHub 上设置所有内容，请按照以下步骤操作：
- 如果您还没有，创建 GitHub 帐户（你可以免费做这个）
- 登录发送到您在 GitHub.com 网站上的帐户
- 也下载并安装 GitHub Desktop. 我们稍后会用到它。安装后，您还需要登录到它。
创建仓库
仓库，或简称 repo，类似于 GitHub 上的一个项目。这是一组可以推送和拉取的文件。
创建新的仓库对于您想要协作的项目。如果您不想与全世界共享您的仓库，请务必将其设置为私有。公共仓库通常用于开源项目（如果你愿意，你的 Construct 项目也可以是开源项目）。请注意，您可以免费拥有的私有仓库或协作者的数量可能会有限制 – 有关最新信息，请参阅 GitHub 的定价页面.
创建存储库后，将显示一些有关如何设置存储库的说明。最简单的方法是使用我们之前下载并安装的 GitHub Desktop。这提供了一个可视化工具来处理推送和拉取更改。应该有一个按钮，上面写着“在桌面中设置”。单击该按钮，系统应提示您打开 GitHub Desktop。继续并打开它。系统将提示您在计算机上为存储库选择一个文件夹; 请确保选择一个新文件夹或空文件夹，然后单击“克隆”（GitHub 用于创建工作副本的术语）。您现在应该在 GitHub Desktop 中打开您的仓库。目前它是空的，GitHub Desktop 应该说 No local changes，因为还没有任何变化。
忽略 UI 状态文件
在继续之前，让我们确保 GitHub 忽略了我们之前提到的那些 UI 状态文件。如前所述，这些仅针对您，您不希望为它们提交更改。
要忽略它们，请在 GitHub Desktop 中选择菜单选项存储 库►存储库设置 …，然后点按“忽略的文件”。输入并单击保存。现在，GitHub 将完全忽略所有以 .uistate.json 结尾的文件，因此它们不会妨碍导致不必要的更改和冲突。*.uistate.json
请注意，这算作对存储库的更改，因此对名为的文件的更改将在您的第一次推送中显示。.gitignore
第一次推送
目前，存储库中没有文件。让我们添加第一组文件。
在“构造”中，打开现有项目，或创建一个新的空项目。然后选择菜单►项目►另存为►另存为项目文件夹 …
请注意，该选项目前仅在 Chrome 中受支持。如果仍然看不到该选项，则可能需要先启用它。查看论坛帖子本地文件和文件夹保存在 Chrome 中.
系统将提示您选择要将项目保存到的文件夹。选择您在 GitHub Desktop 中选择的本地文件夹。
切换回 GitHub Desktop。它现在应该已自动更新。左侧应该有一个您刚刚添加的所有文件的列表，而不是说“没有本地更改”。（下面的图片是在保存一个新的空项目后拍摄的，但如果您使用了现有项目，它将列出项目中的所有内容。
如果 GitHub Desktop 在截取这些屏幕截图后已更新，您可能会看到一些不同的内容，但它应该提供相同的选项。
确保列表中没有.uistate.json 文件。如果看到任何内容，请重新访问上面的“忽略 UI 状态文件”部分。
提交文件
每个更改都称为一次提交。此更改是为了添加我们的第一组文件。每个提交都必须有一个摘要，因此请在摘要框中键入一些内容，例如添加第一个文件。
在每次提交时都有一个清晰而有用的摘要和描述，这是一种很好的做法。这有助于建立有用的历史记录，并让您的队友清楚地知道您一直在做什么。
然后单击 Commit to master。（Master 是默认分支，但这是一个不同的主题。
在您发布更改之前，您的更改不会发送到服务器。这样，您可以对多个提交进行排队，并一次性提交所有提交。但是，我们只有一个提交，我们希望立即发送它，因此请单击 Publish branch。它会花一点时间上传您的文件。
完成后，再次在 Web 上查看 GitHub 存储库，或者如果页面仍处于打开状态，请重新加载该页面。你应该在那里看到你的文件！他们现在在服务器上。
现在，您已经准备好开始与您的团队合作了！
在 CONSTRUCT 中修改项目
返回到您的项目并进行更改。出于演示目的，我们将向新的空项目添加一个新的 Player 精灵。保存项目，以便更新项目文件夹中的文件。
返回到 GitHub Desktop。它现在列出了这些更改。将添加和更改文件（例如布局，现在包括新的播放器实例）混合文件。
请注意，当您选择左侧的文件时，您可以看到更改内容的预览。它可以显示添加的图像文件，也可以显示已更改的文本文件部分。
您无需了解 Construct 的 JSON 格式即可保存文件。但是，在处理项目时，您可能会开始认识到哪些类型的更改会随着时间的推移影响不同的文件。
使用此预览版来仔细检查您的更改是否符合预期并且您没有犯任何错误，这是一个好主意。
然后像以前一样，按照以下步骤将更改推送到服务器：
- 输入摘要（如添加的播放器对象），最好是描述。
- 单击 Commit to master
- 单击 Push origin 将提交发送到服务器
和以前一样，您现在可以重新加载存储库的网页并查看更改，例如浏览到新添加的文件。这也意味着您的其他队友可以接收这些更改。
GitHub 网站上也有很多有用的工具可用于您的仓库。您可以查看提交历史记录并查看所有更改的完整列表; 查看每次提交中更改的文件; 添加文档，如 README 文件; 未决问题; 使用项目板和 Wiki; 以及更多。指 GitHub 的帮助对于所有详细信息，我们在这里仅介绍基本用法！
添加协作者
您的其他队友也需要访问您的仓库。您可以在 GitHub 网站的仓库的“设置”部分添加协作者。请注意，根据您的帐户级别，可能会有限制。有关邀请协作者的更多详细信息，请参阅 GitHub 的帮助邀请协作者访问个人仓库.
邀请合作者后，他们也应该能够访问 GitHub 网站上的仓库。然后，该过程类似于首次创建仓库时的过程：下载并安装 GitHub Desktop，然后在网站上单击“克隆或下载”，然后单击“在桌面中打开”。和以前一样，他们可以选择一个本地文件夹来克隆存储库，然后它会在那里下载所有项目文件。然后，它们都设置为以与您相同的方式推送和拉取更改。
接收其他更改
如果您有其他队友进行更改，您经常希望接收对存储库所做的任何其他更改。
您需要做的就是在 GitHub Desktop 中单击 Pull origin（有时也显示为 Fetch origin），将任何新更改从服务器拉回本地工作副本。但是，每当您执行此操作时，请确保您已在 Construct 中关闭了您的项目。这将更新您的项目文件，但 Construct 不会看到它们已更改，下次您按“保存”时，您可能会撤销更改并最终弄得一团糟。确保您已关闭项目可以保证您不会意外覆盖任何内容，并确保当您下次打开它时，Construct 将在编辑器中反映所有最新更新。
GitHub Desktop 还可以在有更改等待从服务器中提取时提醒您，如下所示。单击 Pull origin 将收到这些更改 – 但如前所述，请务必确保在执行此操作之前已关闭 Construct 项目。
多亏了源代码控制的魔力，这也将更改与您自己的文件合并。这是源代码管理的一个关键功能。如果您没有在相同位置更改相同的文件，则所有内容都应该自动合并到一个连贯的项目中。
冲突解决
如果两个人同时修改同一文件的同一部分，会发生什么情况？这会产生冲突。
冲突是你应该不惜一切代价避免的事情，因为它们很容易变得复杂和令人困惑。应尽可能避免同时处理项目的相同部分。但是，无论如何，它们最终可能会不时意外地发生。
例如，假设两个人对项目描述进行了更改。一个人把它改成“我的真棒项目！”，提交它并将其推送到服务器。然后第二个人将其更改为不同的东西，例如“我的超级棒项目！”，提交它，并试图将其推送到服务器。GitHub Desktop 将停止第二个人推送，因为它知道尚未收到更改。所以它需要你先拉。
这就是冲突发生的地方。第二个人看到了冲突，因为他们对项目描述有自己的更改，但他们试图接收对项目描述的不同更改。应该有哪个描述？这无法自动解决，因此它必须要求您修复它。
您必须手动解决此问题。通常，最简单的解决方案是中止合并，然后还原本地更改。您可以在“历史记录”部分中还原提交。
但是，在某些情况下，您会有很多更改，并且您不想丢失所有这些工作。因此，您也可以手动编辑文件以解决冲突。默认建议是使用 Visual Studio 代码，一个编码编辑器，用于将文件编辑为文本。（您需要先下载并安装它才能使用它。它在处理冲突方面提供特别支持。在本例中，它会打开 VS Code 中带有冲突描述的项目文件，然后，如果向下滚动，它会突出显示冲突，并提供有关如何解决冲突的选项：
如果您知道自己在做什么，则可以手动编辑文本。但是，解决它的最简单方法是单击以下任一按钮：
- 接受当前更改：使用您尝试提交的更改。请记住，是第二个人正在解决冲突，因此这意味着使用了第二个描述，覆盖了第一个描述。
- 接受传入的更改：使用存储库中的更改。这意味着使用第一人称的描述，覆盖第二人称的描述。
在本例中，我们将使用 Accept Current Change，因此使用第二个描述。文件中也可能存在其他冲突，因此您可能需要滚动文件并修复所有冲突。解决所有问题后，保存文件并关闭它。GitHub 现在确定没有冲突，因此现在已启用提交合并，您现在可以继续从存储库中提取更改。
请注意，GitHub 处理此问题的方式是它添加了第二个提交，用于处理合并冲突。然后，您终于可以推送您的更改，并且项目将在服务器上更新。
查看所发生情况的一个好方法是查看 GitHub 网站上的提交历史记录。您可以按照推送的顺序查看每个提交的列表，并查看它们更改的文件的差异。
一些有用的工具
有关 GitHub 网站和 GitHub Desktop 提供的所有工具的完整文档，请参阅 GitHub 文档中的 GitHub 的帮助. 您可能想要探索的一些有用工具包括：
- 撤销更改：您可以改变对所犯内容的看法，并撤销它以撤消它。（请注意，这将创建另一个提交，该提交将还原先前的提交。
- 回滚到早期版本：您可以在过去的任何时候将工作副本回滚到项目的旧版本。例如，如果您可以回到 3 个月前的项目外观，并比较它的外观和工作方式。如果任何东西意外损坏，它也很有用，因为您可以回滚到最后一个已知的良好版本。
- 查看历史记录：您可以查看每个单独文件的更改日志，包括更改的时间、每次更改的提交消息和描述、更改文件的人员等。
- 责备：这个名字有点不幸，因为希望你不想用它来指责别人，但是责备分解了文件的内容，并显示了该文件的每个部分的最后更改时间以及由谁更改。基本上，这只是查看历史记录的另一种有用方法，因为您可以查看文件的每个部分上次更改的时间。
- 创建分支：分支就像项目的变体。例如，您可以创建一个分支，并更改菜单系统。如果你不喜欢它，你可以扔掉树枝，继续使用旧的。如果你喜欢它，你可以将分支合并到主分支（主分支）。这对于长期的实验性更改是有好处的，因为您正在进行的工作不会弄乱其他人正在处理的主分支。
- 使用其他 GitHub 功能（如议题、项目板、Wiki 等）来帮助您的团队有效地协同工作。
一些特定于 CONSTRUCT 的建议
Construct 将 UID（唯一 ID）分配给编辑器中的对象。它们保存在每个实例的布局文件中。默认情况下，Construct 会为新放置的实例分配最低的未使用 UID（也称为 Increment 模式，因为它倾向于分配 1、2、3、4 等数字）。这意味着，如果两个客户端都放置了一个新实例，然后合并了他们的项目，则布局文件可能对两个对象使用相同的 UID。Construct 尝试通过重新分配重复的 UID 来优雅地处理此问题，但在使用层次结构或在事件表中引用特定 UID 时，它仍然可能导致问题。相反，在协作处理项目时，强烈建议更改 UID 编号 Project 属性更改为随机。这会将新分配的 UID 更改为至少六位数字的随机数，例如 582953、295630、810344 等。这意味着两个人使用相同的 UID 创建新实例的可能性可以忽略不计。
此外，请避免对项目中的 JSON 文件进行手动编辑。您可以在 Construct 之外编辑图像和声音文件等内容，当您下次打开项目时，它应该使用这些更改。但是，如果通过直接编辑对象的 JSON 文件来重命名对象之类的操作，则很可能会损坏项目。这是因为重命名对象实际上涉及更新项目中的各种其他引用。当您从编辑器重命名对象时，Construct 会为您处理此问题，但是如果您在编辑器之外执行此操作，它将创建不一致的引用并中断项目。在解决冲突时，您可能会被迫编辑 JSON 文件，而在其他情况下，您可能不会破坏任何内容（例如更改层上的实例列表）。但一般来说，只要有可能，您都应该使用 Construct 编辑器进行更改，以避免破坏某些内容。
另请注意，当 Construct 更新时，请确保团队中的每个人都同时更新。构造项目文件不向后兼容 – 即您无法在 r100 中打开保存在 r200 中的项目。同样，在使用源代码管理时，不能将在 r200 中所做的更改合并回保存在 r100 中的项目，然后在 r100 中继续使用它。由于文件格式不向后兼容，因此可能会损坏项目。如果团队中的每个人都同时更新，则可以避免此问题。
结论
像 GitHub 这样的源代码控制软件工具是成熟和先进的工具，用于在项目上进行有效协作。它们在传统软件开发中很普遍，但源代码控制工具具有足够的通用性，使用 Construct 的团队也可以利用它们。由于这些工具已经非常成熟和全面，因此 Construct 中应该不需要任何特定的协作功能。
源代码控制被广泛认为是任何类型的专业发展的必修课。手动合并非常缓慢、困难且容易出错，因此即使一开始看起来很困难，花时间学习源代码控制工具也是非常值得的。对于个人开发人员来说，它提供的所有其他工具甚至都很方便。如果你在一个团队中工作，让每个人都参与源代码管理，我敢肯定，不久之后你就会想知道没有它你是怎么过的！