如何在子文件夹中设置git origin？ 关于Git项目布局的重要说明

如何解决如何在子文件夹中设置git origin？ 关于Git项目布局的重要说明

初步信息；

• 我正在使用macOS。
• 我有一个名为“ projects”的文件夹，其中存储了所有的git存储库。 （如果这不合逻辑，请解释原因，让我知道。这将帮助我改进）。

我做了什么；

在“项目”文件夹中，有2个已经存在的项目。

• 我从浏览器转到GitHub并手动创建了一个新的存储库。
• 复制的克隆网址
• 打开终端并导航到我的“项目”文件夹
• 创建了一个名为“ x”的新文件，其名称与新创建的存储库相同。

现在问题来了。

• 当我当前的工作目录是“项目”时，我键入：

  git remote set-url“新存储库的克隆URL”

现在，当我键入git status时，“项目”文件夹中的其他两个存储库文件也会计为更改。 （毫不奇怪）我相信我应该进入“ x”文件并在该文件中设置远程原点。 （另外，如果您认为我在这一部分的想法有误，请告诉我。）

我的问题是：当我仅处理“ x”文件时，如何看不到其他两个存储库的文件为“要提交的更改”？

谢谢

解决方法

要放大Ôrel said in a comment，每个项目应该有一个目录（如果喜欢，可以使用文件夹）。您可以根据需要将所有这些文件存储在名为projects的目录/文件夹中。

假设您的两个项目分别是https://github.com/kutay/proj1和https://github.com/kutay/proj2，在Mac上，您将从主目录开始：

mac:~$ mkdir projects          # you already did this
mac:~$ cd projects
mac:~/projects$ git clone https://github.com/kutay/proj1
[Git messages happen here]
mac:~/projects$ git clone https://github.com/kutay/proj2
[Git messages happen here as well]

结果将是您现在在主目录中有projects/proj1和projects/proj2，或者在proj1目录中也有proj2和projects。使用cd进入要在其中执行工作的目录，然后从此处运行git status和其他Git命令。

关于Git项目布局的重要说明

在项目中工作时，必须cd进入Git称为工作树或工作树的顶层。例如：cd ~/projects/proj1将带您进入proj1工作树。

在每个工作树的顶层，Git的私有文件都位于.git目录中。也就是说，现在有一个~/projects/proj1/.git目录（或文件夹），Git在其中保存其文件。您可以根据需要查看这些文件（和子目录），但一般来说，绝对不要直接修改这些文件。

Git实际存储的内容以及往返于GitHub的内容都是 commits 。每次提交都会存储Git知道的每个文件，作为完整快照。 git checkout（或git switch）操作告诉Git 从快照中复制文件。快照中存储的文件是只读的：您和Git都无法更改它们。它们也采用特殊的，仅Git的，压缩和去重复的格式，因此只有Git可以读取。

您所做的工作发生在工作树中：在这里，有一些文件（和目录/文件夹）以普通的日常格式存储。这些文件实际上不在存储库中。存储库文件位于该.git子目录中。当您要求时，Git只是将其保存的文件复制到您的工作树中。

换句话说，每个文件始终有至少两个副本：您使用git checkout或{{1}选择的当前提交中的一个副本}，以及您可以读取和写入的工作树中的一个。当前提交副本无法更改。没关系！您要做的是更改新提交。而不是更改提交中的文件。

要构建新的提交，通常，您将修改（和/或创建）工作树中的文件。您可能认为这足够了，但是还不够：Git不会从这些文件中进行 new 提交！相反，Git从每个文件的第三副本进行新的提交。第三份副本采用特殊的，仅限Git的重复数据删除格式（因此在大多数情况下实际上根本不是副本）。

每个文件的第三个副本位于Git调用的内容中，即 index 或 staging area 或（通常是最近）缓存 。名称“索引”不是很好。不幸的是，它有点像主名。 “登台区域”涵盖了您使用的方式，虽然更好，但还不够完善，因此在这里我主要使用“索引”一词。

要告诉Git更新（或创建）Git索引中的第三份副本，请使用git switch。运行git add并告诉它一些工作树文件的名称，Git将确保该文件的索引副本与您的工作树副本匹配。如果为git add提供完整的目录名称，例如git add或.，它将使Git的索引包含并匹配该目录中的所有文件。

每个文件的这些索引副本（Git的特殊，只读，压缩和重复数据删除格式）是Git知道的文件。当您运行subdir时，Git将使用文件的这些副本进行一次新提交。由于它们已经是Git格式，因此git commit可能很快。请注意，索引中的文件的长名称带有嵌入式（正斜杠），例如git commit。 Git的索引不能包含一个单独的文件夹名称，因此，Git提交不能包含目录。提交仅包含文件（嗯，这就是提交元数据，这里我们没有介绍）。

剩下的要知道的事……好吧，还有很多。让我们来谈谈一些：

• 每个Git是独立的。通常，（有些例外），每个 Git存储库都有一个每个提交的副本。

• 每个Git存储库也都有其自己的私有分支名称。您在Git存储库之间共享的是 commits 。

• 要连接两个Git存储库，请使用path/to/file.ext和git push。

  • git fetch操作从您的存储库开始，您希望在其中拥有他们没有的东西，然后给他们新的提交，然后询问他们更新他们的一些分支名称。

  • git push操作从您的存储库开始，您希望它们在其中可能还没有您想要的东西。您连接到他们，让您的Git向他们的Git询问他们的分支和提交，然后您的Git询问他们的任何提交，即您 >不要。

  
  因此，在运行完两个操作之后，两个Git通常都具有相同的提交。如果您可以确定自己已经基本上处于同步状态，则不必同时执行这两项操作：如果您认为他们有自己想要的新内容，则只需git fetch，而只需{{ 1}}如果您想给他们新的东西。

• 分支名称很重要，因为它们可以让您查找提交。但是实际上承诺很重要。分支名称仅在查找提交方面起作用。

因此，要记住的事情是：

• Git与 commits 有关。
• 提交包含（所有文件的）快照，以及一些元数据（我们尚未真正讨论过）。
• 商品已编号（我们根本没有讨论过），但是以一种怪异的方式使数字看起来是随机的。这些是Git的哈希ID 。它们缩写得很像fetch之类。各地的所有Git都同意哈希ID，这是使Git工作的魔力的关键来源之一。
• 分支名称记住为您提交哈希ID（因为否则是不可能的！）。
• 我们根本没有讨论过的push命令非常有用。
• 您可以在工作树或工作树中进行工作，在那里您可以查看和使用文件。但是这些文件实际上不是在 Git中。
• 您使用a1c9f33d进行新的提交，但这实际上并没有使用您的工作树文件，因此您必须大量使用git status。
• 存储库的本质是它包含提交（和其他内部Git对象），作为一种有史以来所有提交的大型数据库。您使用git commit将新的提交放入Git。它还包含一些名称，例如分支名称，以帮助查找这些提交。
• 存储库本身是git add目录。在此存储库中，文件采用特殊的仅Git格式，包含在提交中（也以仅Git格式存储）。 Git的索引也与两个数据库一起位于此git fetch目录内：Git对象中的一个大对象（包括提交），以及映射到提交对象ID（散列ID）的名称之一（包括分支名称）。