将本地非git工作合并到远程git存储库。
我想将我的工作从一个非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需要我对我所有的产品进行本地回购，我会做的，但是呃.我不喜欢它，因为我不需要它，这就是为什么我在我的第一条信息中找到了一个解决方案。
你觉得我应该有更好的工作流程吗？你认为我们应该在不同的分支上工作，即使是小的变化(如果它允许我有一个更干净的历史，我会这样做，因为我喜欢保持组织和精简，这就是为什么我使用重基而不是合并)？
事实上，大的背景问题是:大型团队如何将它们的GitHub代码与ftp代码同步(并且在更新回购和实际ftp之前，在测试ftp文件夹中检查新的GitHub代码是可以的)？愚蠢的问题:他们是否从ftp做SCM (怎么做？)这会很棒的)？
我是单片机的新手，我问自己所有这些问题.
回答 2
Stack Overflow用户
发布于 2017-09-16 22:54:00
你知道更快的方法吗？
这是个不该问的问题。正确的问题是：是什么驱使您在SCM之外做任何工作?本地或远程回购？。
什么是将您的工作与远程回购同步的“最快”方法的问题是合法的，但是由于您没有提供关于您的工作流程的任何细节，所以我们不能肯定地回答这个问题。
我建议您使用此工作流：
- 如果在Github叉远程回购(如果适当的话)第一。
- 复制远程回购(或您的叉子)之前，对您的本地PC做任何工作，这样您就可以在本地回购。
- 为该特性/输出创建分支，该分支将在将来合并
- 在分支中完成所有工作，提交并以其他方式利用Git的SCM创建历史记录和随时恢复更改的能力
- 定期将您的分支推到远程，如果其他人由于任何原因应该能够看到正在进行的工作(例如，如果您请求帮助)，并给您备份。
- 当准备合并时，只要发出一个拉-请求(如果适当的话)(或者在您自己的叉子中)，并允许代码/工件检查；或者，如果这个项目是这样操作的，那么就合并到master中即可。
我们可能会推荐更多细节的替代策略，但我认为你正在使事情变得更加复杂，尤其是在合并还是重基问题方面，这意味着在远程回购中，惟一的分支是master(!) --例如，您熟悉维护多个开发和实验分支的Gitflow模型吗？您熟悉在Git中进行分支和合并有多容易吗？
Git是为分布式源代码管理而开发的--所以请使用它！(即在开发过程中在本地使用).
更新为更长的历史添加到问题中
如果我正确理解你的情况，我认为上面的工作还是会很好的。我建议在你的本地PC上创建一个Github的镜像，你总是把它保存在那里。您仍然可以通过FTP在服务器上完成所有的更改，因为您说这更方便--但是我会小心的，因为那样的话(如果我理解的话)，您正在更改实时网站。如果这对您的情况有效(包括在不首先测试新版本的情况下这样做的危险)，那么这是很好的。
考虑到您的具体情况，我会尝试以下两种方法--但我不能100%确定Git将如何与FTP交互(例如，希望它不会刷新现有文件或其他导致Git将其视为更改的文件的日期)。
- 继续做你正在做的事情--除了在你的本地电脑上留下一个临时回购。此方法将只将您的更改转储为对主的新提交。
- Make your new changes to the FTP site
- When ready to add your updates to the repo, do a fetch of the remote server to your local server to pick up any new commits on the remote before pulling down from FTP.
- Pull your changes down from the FTP into the local repo, just overwriting any existing files. If this works the way I think, then a git status will show only the changed files at this point.
- Do a `git add .` to add all the changes to the index
- Commit to master with your changes
- Push to remote, which should just add your new commit with your new changes to the remote. Small possibility of a conflict if someone else commits between your fetch and push.
- rinse and repeat
- 去一个分公司的战略。仍然保持本地回购
- Come up with some branching strategy that everyone on the repo agrees with (sounds like it's just two of you). In this case I might suggest you just have a separate branch from master, probably just with your name or 'dev', 'web', etc. (something short and easy to type!).
- Alternately, you could branch for every change, but that sounds like overkill here.
- Any changes you make to the site, you can pull down from FTP and add/commit to your local branch.
- Any time you have a commit that you want to merge to master, do a fetch, merge, then pull.
- **Advantage 1:** You can commit as often as you want to your local repo, which will store a history of any changes, and allow you to revert at any time to a former commit if something goes wrong on the FTP site.
- **Advantage 2:** Your separate branch will be duplicated on the remote repo so that all parties can see the history of that branch, when merges were done, etc., if the history of issues needs to be tracked.
- **Advantage 3:** You can still always merge with a pull request from a branch, if desired, which should avoid any conflicts if multiple people are trying to merge (i.e. let the person maintaining the remote decide when to merge it, or open communications if there will be an issue). In other words, you don't take responsibility for the master branch, you can just live in your side branch.
如果所有这些看起来都不适用于你--我会尝试另一个我作为替代方案发布的解决方案。应该没有必要每次删除本地回购，这样甚至可以为您节省一步，我认为-或者也许只是让它成为一个获取而不是一个克隆？
Stack Overflow用户
发布于 2017-09-16 23:06:31
我真的认为我的另一个答案更好，但这里有一个选择，完全按照你的要求.
在未在回购中的开发文件夹的父文件夹中：
git克隆回购URL > cd回购名称> mv ./文件夹名称的东西。> git添加。> git提交-m“将我的东西添加到文件夹名中”
本质上，您首先要克隆回购()，然后将您的开发文件夹移到回购中，添加它，并将其提交到您需要的任何分支(我在这里假设为Master)。
这可能有点短，可能更干净-更容易理解，因为您是添加项目后，回购已经存在，所以您没有单独的主分支具有不同的历史。
编辑:考虑到更新的历史，您甚至可以通过从网站服务器直接下载到本地回购(而不是强制使用mv命令)来缩短时间。
您也可以随时保留本地回购，只需将克隆更改为获取。
https://stackoverflow.com/questions/46255861
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号