将本地非 git 工作合并到远程 git 存储库

Question

我想将我的工作从非 git 启动的文件夹与远程 git 存储库合并。

以下作品：

git init
git add
git commit

git remote add origin [url]
git fetch
git rebase origin/master
git push -u origin master

另一种选择是：

git init
git add
git commit

git remote add origin [url]
git pull --allow-unrelated-histories origin master
git push -u origin master

但是 --allow-unrelated-histories 写起来很长（git 的创建者不想实现一个快捷方式，因为 "it's a rare case"）而且我听说做一个 rebase 比一个更好在这种情况下合并。

你知道更快的方法吗？

编辑
长版：

我愿意跳过工作流程部分直接进入主题，但这是我的工作流程以了解原因（我记得你推荐的工作流程，但我不确定它是否适用于我的情况）：

我网站的代码在ftp
我直接在 ftp 上工作，因为它对我来说更方便
我将 ftp 文件夹拖放到我的桌面上，然后运行 git 命令将我的本地-ftp 更改与我的协作者-[=75] 合并=]个。

为什么我直接在 ftp 上工作：
- 全部集成在我的 IDE 中，我可以用一个软件 "on the fly" 进行修改
- 没有可用的本地服务器
- 无需从本地转移到 ftp（除非协作者对 GitHub 进行了更改）
- 网站的付费插件不是我在本地配置的，所以我没有合适的本地测试环境
- 我曾经在本地工作，但是当我出于任何原因将代码转移到 ftp 时结果不同

我同意这可能是 "handcrafted"，但它做得很好，因为我是单独编写代码的。现在有另一个人，所以我们把代码放在 GitHub 上，我用提到的 git 命令解决了代码之间的同步问题。我有代码的写入权限，所以我不必 fork/pull 请求。我不需要永久保留本地回购，所以我更喜欢擦除它，但如果 SCM 需要我保留我所有项目的本地回购，我会做，但是呃......我不喜欢它因为我不需要它，这就是为什么我在第一条消息中找到了解决方案。

您认为我应该有更好的工作流程吗？你认为我们是否应该在不同的分支上工作，即使是很小的变化（如果它允许有一个更清晰的历史我会做，因为我喜欢保持组织和精简，顺便说一句，这就是我使用 rebase 而不是合并的原因）？

事实上，最大的背景问题是：大型团队如何将他们的 GitHub 代码与他们的 ftp 代码同步（并在测试中检查新的 GitHub 代码是否正常 ftp 文件夹之前更新回购和实际 ftp 回购）？愚蠢的问题：他们是否直接从 ftp 开始执行 SCM（怎么做？这太棒了）？

我是 SCM 的新手，我在问自己所有这些问题...

Answer 1

Do you know a faster way to do this?

这个问题问错了。正确的问题是：是什么驱使您在 SCM 之外进行任何工作 - 在本地或远程存储库之外？

关于将您的工作与远程存储库同步的 "fastest" 方法是什么的问题是 gitimate，但由于您没有提供有关工作流程的任何详细信息，我们可以'肯定地回答那个问题。

我会推荐这个工作流程：

如果在 Github 上 - 如果合适，首先分叉远程仓库
在对本地 PC 进行任何操作之前克隆远程存储库（或您的分支），这样您就可以在本地存储库中工作。
为此feature/output创建一个分支，将来会合并
在分支中完成所有工作，提交并利用 Git 的 SCM 创建历史记录并能够随时恢复更改
如果其他人出于任何原因（例如，如果您寻求帮助）应该能够看到正在进行的工作并为您提供备份，请定期将您的分支推送到远程。
准备合并时，如果合适（或在您自己的分支中），只需发出拉取请求，并允许 code/artifact 审查；或者，如果这个项目是这样运作的，就合并到 master 中。

我们可能会推荐一些替代策略并提供更多详细信息，但我认为你让事情变得更复杂，而不是必须的，特别是在合并与变基问题方面，这必须意味着您的远程仓库，唯一的分支是 master(!) - 您是否熟悉维护多个开发、实验分支的 Git 流程模型？您是否熟悉在 Git 中分支和合并是多么容易？

Git 是为分布式源代码控制管理而设计的——所以就用它吧！（即在开发期间在本地使用它）。

更新了添加到问题的较长历史

如果我正确理解您的情况，我认为上述方法仍然可以正常工作。我建议在您的本地 PC 上创建 Github 存储库的镜像，您始终将其保存在那里。你仍然可以通过 FTP 在服务器上进行所有更改，因为你说这更方便 - 但我会小心，因为那样（如果我理解正确的话），你正在更改实时网站。如果这对您的情况有效（包括不先测试新版本就这样做的危险），那也没关系。

鉴于您的具体情况，我会尝试以下两种方法 - 但我不是 100% 确定 Git 将如何与 FTP 交互（即希望它不会刷新现有文件的日期或任何其他导致 Git 将其视为已更改的日期）

继续做你正在做的事情——除了在你的本地电脑上留下一个 loco repo。此方法只会将您的更改转储为对 master 的新提交。
- 对 FTP 站点进行新的更改
- 准备好将更新添加到存储库时，在从 FTP.
- 将您的更改从 FTP 下拉到本地存储库，只是覆盖任何现有文件。如果这按照我的想法工作，那么 git 状态此时将仅显示更改的文件。
- 执行 git add . 将所有更改添加到索引
- 致力于掌握您的更改
- 推送到远程，这应该只是将您的新提交与对远程的新更改一起添加。如果其他人在您的获取和推送之间提交，则发生冲突的可能性很小。
- 冲洗并重复
转到分支策略。仍然保留本地存储库
- 想出一些分支策略，回购上的每个人都同意（听起来只有你们两个）。在这种情况下，我可能会建议您从 master 中创建一个单独的分支，可能只是您的名字或 'dev'、'web' 等（简短且易于输入！）。
- 或者，您可以针对每个更改进行分支，但这听起来有点矫枉过正。
- 您对站点所做的任何更改，都可以从 FTP 和 add/commit 下拉到您的本地分支。
- 任何时候你有一个你想要合并到 master 的提交，做一个获取，合并，然后拉。
- 优点 1： 您可以根据需要随时提交到本地存储库，它将存储任何更改的历史记录，并允许您随时恢复到如果 FTP 站点出现问题，请前提交。
- 优势 2： 您的独立分支将在远程仓库中复制，以便所有各方都可以看到该分支的历史记录、合并完成的时间等，如果需要跟踪问题的历史记录。
- 优点 3： 如果需要，您仍然可以始终与来自分支的拉取请求合并，这应该避免在多个人试图合并时发生任何冲突（即让维护遥控器的人决定何时合并它，或者在出现问题时打开通信）。换句话说，你不对master分支负责，你可以住在你的侧分支。

如果其中的 none 看起来适合您 - 我会尝试我发布的其他解决方案作为替代方案。应该不需要每次都删除本地存储库，这样甚至可以为您节省一步，我想 - 或者只是让它成为一个获取而不是克隆？

Answer 2

我真的认为我的另一个答案更好，但这里有一个完全按照您的要求做的替代方案...

在您的开发文件夹的父文件夹中，该文件夹不在存储库中：

> git clone [repo URL]
> cd [repo name]
> mv ../[folder name of your stuff] .
> git add .
> git commit -m "added my stuff in folder [folder name of your stuff]"

本质上，您首先要克隆存储库，然后只需将您的开发文件夹移动到存储库中，添加它，然后将其提交到您需要的任何分支（我假设是 master在这里）。

这可能更短一些，可能更清晰 - 更容易理解，因为您是在回购已经存在之后添加项目，所以您没有具有不同历史记录的单独主分支。

编辑： 鉴于更新的历史记录，您甚至可以通过 FTP 从网站服务器直接进入本地仓库（而不是而不是强制执行 mv 命令。

您也可以一直保留本地存储库，只需将克隆更改为提取即可。

将本地非 git 工作合并到远程 git 存储库

Merge local non git work to remote git repository

git

merge

local

rebase

我会推荐这个工作流程：

更新了添加到问题的较长历史