我想将非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的创建者不想实现快捷方式，因为"这是一种罕见的情况")，我听说在这种情况下，与其进行合并，不如进行重新基准。
你知道更快的方法吗？
编辑
长版本：
我很乐意跳过工作流部分，直接进入要点，但以下是我的工作流，以了解原因(我记住了你推荐的工作流，但我不确定它是否适用于我的情况)：
- 我的网站代码在ftp上
- 我直接在ftp上工作，因为它对我来说更方便
- 我在桌面上拖放ftp文件夹，并运行git命令将我的本地ftp更改与我的合作者GitHub更改合并
为什么我直接在ftp上工作：
-所有这些都集成在我的IDE中，我可以用一个软件"即时"进行修改
-没有本地服务器可供使用
-没有从本地转移到ftp的操作(除非合作者在GitHub上进行了更改)
--网站的插件不受我的本地处理，因此我无法拥有一个合适的本地测试环境
.我以前在本地工作，但由于任何原因，当我将代码转移到ftp时，结果都不一样
我同意这可能是"手工制作"的，但它做得很好，因为我独自编写代码。现在有另一个人，所以我们把代码放在GitHub上，我用提到的git命令解决了代码之间的同步问题。我有对代码的写访问权限，所以我不必分叉/拉取请求。我不需要永久保留本地回购，所以我更喜欢删除它，但如果SCM需要我保留我所有项目的本地回购，我会这样做，但嗯…我不喜欢它，因为我不需要它，这就是我在第一条消息中找到解决方案的原因。
你认为我应该有一个更好的工作流程吗？你认为我们应该在不同的分支上工作吗，即使是小的更改(如果允许有更干净的历史，我会这样做，因为我喜欢保持组织和精简，顺便说一句，这就是我使用rebase而不是合并的原因)？
事实上，最大的背景问题是：大型团队如何将他们的GitHub代码与他们的ftp代码同步(在更新repo和实际的ftp repo之前，在测试ftp文件夹上检查新的GitHub代码是否可以)？愚蠢的问题：他们能直接从ftp进行SCM吗(怎么做？这太棒了)？
我是SCM的新手，我在问自己所有这些问题。。。
你知道更快的方法吗？
这个问题问错了。正确的问题是：是什么驱使你在SCM之外——在本地或远程回购之外——做任何工作
将您的工作与远程回购同步的"最快"方式是什么，这个问题是合理的，但由于您没有提供任何工作流程的详细信息，我们无法确定答案。
我建议使用此工作流：
- 如果在Github上-如果合适，首先分叉远程repo
- 在对本地PC执行任何操作之前，先克隆远程repo(或分叉)，这样您就可以在本地repo中工作
- 为将来将合并的此功能/输出创建分支
- 在分支中完成所有工作，提交并以其他方式利用Git的SCM创建历史记录，并能够随时恢复更改
- 如果其他人出于任何原因(比如你寻求帮助)能够看到正在进行的工作，并为你提供备份，请定期将你的分支推到远程
- 当准备合并时，如果合适的话(或者在您自己的fork中)，只需发出一个pull请求，并允许对代码/工件进行审查；或者，如果这个项目就是这样运作的，就合并到master中
我们可能会推荐一些替代策略，并提供更多细节，但我认为你会让事情变得更加复杂，尤其是在合并与重组问题上，这一定意味着在你的远程回购中，唯一的分支是master(！)-例如，你熟悉维护多个开发、实验分支的Gitflow模型吗？你熟悉在Git中分支和合并有多容易吗？
Git是为分布式源代码管理而设计的，所以使用它吧！(即在开发过程中在本地使用)
针对添加到问题中的较长历史更新
如果我正确理解你的情况，我认为以上内容仍然有效。我建议您在本地PC上创建一个Github repo的镜像，并始终保存在那里。你仍然可以通过FTP在服务器上进行所有更改，因为你说这更方便——但我会小心，因为那时(如果我理解正确的话)，你正在更改实时网站。如果这适用于您的情况(包括在不首先测试新版本的情况下这样做的危险)，那么这也没关系。
考虑到您的具体情况，我会尝试以下两种方法，但我不能100%确定Git将如何与FTP交互(即，希望它不会刷新现有文件的日期或其他任何导致Git将其视为已更改的文件)
-
继续做你正在做的事情-除了在你的本地电脑上留下一个loco repo。这种方法只会将你的更改作为新的提交到master。
- 对FTP站点进行新的更改
- 当准备好将更新添加到repo时，在从FTP退出之前，将远程服务器提取到本地服务器，以获取远程服务器上的任何新提交
- 将您的更改从FTP下拉到本地repo，只需覆盖任何现有文件。如果这是我认为的方式，那么git状态此时将只显示更改后的文件
- 执行
git add .将所有更改添加到索引 - 承诺掌握您的更改
- 推送到远程，这应该只是添加你的新提交和你对远程的新更改。如果其他人在你的获取和推送之间提交，那么发生冲突的可能性很小
- 冲洗并重复
-
转到分支策略。仍保持本地回购
- 想出一些大家都同意的分支策略(听起来只有你们两个人)。在这种情况下，我可能建议您从master中单独创建一个分支，可能只使用您的名称或"dev"、"web"等(简短且易于键入的内容！)
- 或者，您可以针对每一个更改进行分支，但这听起来有些过头了
- 您对网站所做的任何更改，都可以从FTP中删除并添加/提交到您的本地分支机构
- 任何时候，只要您有一个要合并到master的提交，就进行提取、合并，然后拉取
- 优点1:您可以随时向本地回购进行提交，本地回购将存储任何更改的历史记录，并允许您在FTP站点出现问题时随时恢复到以前的提交
- 优势2:如果需要跟踪问题的历史记录，您的单独分支机构将在远程回购中复制，以便所有各方都可以查看该分支机构的历史记录、何时进行合并等
- 优点3：如果需要，您仍然可以始终与来自分支的拉取请求合并，这样可以避免在多人试图合并时发生任何冲突(即，让维护远程的人员决定何时合并，或者在出现问题时打开通信)。换句话说，你不需要对主分支负责，你可以住在你的分支中
如果这些看起来都不适合你，我会尝试我发布的另一个解决方案作为替代方案。不应该每次都删除本地repo，所以我认为这甚至会为你节省一步——或者只是让它成为一个提取而不是克隆？
我真的认为我的另一个答案更好，但这里有一个替代方案，可以完全按照你的要求。。。
在不在repo中的开发文件夹的父文件夹中：
> 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]"
本质上，您首先要克隆repo，然后将您的开发文件夹移动到repo中，添加它，并将它提交到您需要的任何分支(我在这里假设是master)。
这可能更短，可能更干净，更容易理解，因为您是在回购已经存在之后添加项目的，所以您没有具有不同历史的单独主分支。
编辑：考虑到更新的历史记录，您甚至可以通过从网站服务器直接FTP进入本地repo(而不是强制执行mv命令)来缩短这一时间。
您也可以一直保留本地repo，只需将克隆更改为获取即可。