Git 是否有“重新启动”的工作流程？你的项目？
我已经使用 Git 有一段时间了，我真的很喜欢它，但有一件事我一直无法弄清楚。几乎每次我启动一个项目时，我都会遇到这种情况，我不知道自己将陷入什么境地（在本例中为 Node.js）：
我在项目中取得了很大的进展，像一个优秀的 Git 公民一样做出承诺。然后我彻底搞砸了……或者意识到我不可能挽救我当前的代码。我想重新开始，但因为我是肛门的，我不想失去我的 git 提交。有没有办法将 git 提交“转移”到这个新项目？
编辑：感谢您的快速回复 - 我忘了添加。这个新项目将位于 git 存储库外部的新基本文件夹中。那么我可以将 git repo 复制到该目录吗？删除文件然后提交对我来说不起作用，因为当我过渡到新项目时，我会从以前的项目中获取工作片段。
谢谢！ 马特·穆勒
I've been using Git for a bit now and I really like it but one thing I'm haven't been able to figure out. I run into this scenario almost every time I start a project where I don't know what I'm getting myself into (in this case Node.js):
I get pretty far in a project, committing along like a good Git citizen. Then I royally mess up... or realize I cannot possibly salvage my current code. I want to start fresh, but because I'm anal, I don't want to lose my git commits. Is there any way to "transfer" git commits to this new project?
EDIT: Thanks for the quick responses - I forgot to add. This new project would be in a new base folder thats outside the git repo. Would I just copy the git repo to that directory then? Deleting the files then committing won't work for me because I take working snippets from the previous project as I transition into the new project.
Thanks!
Matt Mueller
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
@matt，您可以在当前主分支（或任何分支）上创建一个新分支，然后执行
其中 n 是您想要返回的提交次数。但要小心，在重置主分支之前，请确保新分支具有您想要的提交，因为硬重置会将它们吹走（我认为）。
您还可以通过其 sha1 哈希返回到特定提交，语法应该类似。
@matt, you can create a new branch off the current master (or any branch), and then do a
where n is the number of commits back you want to go. but be careful, make sure the new branch has the commits you want before you reset your master, as the hard reset blows them away (I think).
You can also go back to a specific commit via its sha1 hash, the syntax should be similar.
嗯，这取决于你想如何恢复到良好的状态。
如果您只想注销一些以前的提交（工作单元）与好的提交混合在一起，那么使用 git rebase -i HEAD~10 ......增加“10”以足够远并删除那些提交都是垃圾。
如果您想将单个文件恢复到旧版本，请执行 git checkout HEAD~10 -- Node.js ，将其拉入当前工作区，然后提交，表示您正在恢复所有文件自从……你明白了之后就发生了变化。
如果您只想删除一堆最近的提交，您可以 git reset --hard HEAD~10 或其他任何方式恢复到旧版本。
Well, it depends on exactly how you want to get back to a good state.
If you just want to write off some previous commits (units of work) mixed up with good ones then use
git rebase -i HEAD~10... increase "10" to be far enough back and remove the commits that are junk.If you want to revert a single file to an older version, do
git checkout HEAD~10 -- Node.jsto pull that into the current workspace and then commit that, saying you're reverting all the changes since... you get the idea.If you just want to remove a bunch of recent commits, you can
git reset --hard HEAD~10or whatever to revert back to that old version.您在初始提交中已经有了代码的基础。
一种方法是在当前分支的顶端添加一个标签，然后使用 git-reset --hard 将项目返回到最开始的位置，然后从那里继续。
在这种情况下，我更喜欢使用标签，因为只要有标签，提交就会被扎根并且不会被垃圾收集。另外，如果您经常使用分支，那么您并不总是会被死分支分散注意力，因为标签不会显示在分支列表中。
You already have the base of your code in the initial commit.
One way to do this is to add a tag to the tip of your current branch and then use
git-reset --hardto back your project out to the very beginning and then continue from there.I prefer to use tags in this case because as long as you have a tag the commits will be rooted and won't be garbage collected. Also, if you use branches a lot, then you aren't always distracted by the dead branch as tags don't show up in branch lists.
您可以复制旧的 git 存储库，重命名旧分支（以避免将来混淆），然后使用
gitcherry-pick [rev]或git checkout [rev] -- [filename]取决于您是要选择特定提交还是获取处于特定状态的文件。作为第三种可能性，您可以git rebase --interactive消除损坏的提交并根据您的需要重新安排其他提交。我还建议使用 成功的 Git 分支模型，即（以及其他建议）使用一次性分支来实现实验性功能，并且在您知道它们没问题之前不要将它们合并回来：
（来源： nvie.com)
You can copy over the old git repo, rename the old branches (to avoid future confusion) and then use either
git cherry-pick [rev]orgit checkout [rev] -- [filename]depending on whether you want to pick specific commits or obtain files as they were in a specific state. As a third possibility, you cangit rebase --interactiveto eliminate broken commits and rearrange the others to your needs.I can also recommend using the workflow described in A successful Git branching model, i.e. (among other suggestions) use throw-away branches for experimental features and don't merge them back until you know they are ok:
(source: nvie.com)