在 git 混乱中从头开始?
我一直在开发一个 Visual Studio 解决方案,其中包含大约 40 或 50 个项目。
我已向 .sln 文件添加了大约 10 个项目,但与此同时,其他人也向 .sln 文件添加了一个项目。
因此,实际上存在一个文件 - V1,两个人独立地创建了两个单独的 V2。
我发现合并这些变化是一场噩梦。我正在使用的机器上安装了 BeyondCompare,它向我显示了三列合并。我无法弄清楚这一点,所以我决定用 git 认为远程版本的内容覆盖我的本地文件。 但后来我遇到了重新添加新项目的问题。
所以。在我进行第 90 次 pull+rebase/commit 之前,有没有一种简单的方法可以解决这个问题? 就像,用远程端的内容覆盖所有内容的当前本地副本。然后重新添加到我新添加的项目中。然后提交。构建+测试。然后推。也许?
*编辑:FWIW,机器还安装了 tortoise git,现在所有内容都显示为绿色勾号......所以这非常好,对吧?
I've been working on a Visual Studio solution which contains about 40 or 50 projects.
I've added about 10 more projects to the .sln file, but in the meantime somebody else added a project to the .sln file.
So effectively there was a file - V1, which two people independently worked on creating two separate V2s.
I'm finding merging the changes a nightmare. The machine I'm using has BeyondCompare installed on it, and it's showing me a three column merge. I couldn't figure that out so I decided to just overwrite my local file with what git thinks the remote version is.
But then I've the problem of re-adding the new projects back in.
So. Before I do the 90th pull+rebase / commit, is there an easy way to resolve this?
Like, overwrite the current local copy of everything with what's in the remote side. Then re-add in my newly added projects. Then commit. Build + test. Then push. Perhaps?
*edit: FWIW, the machine also has tortoise git installed and everything right now is showing with green ticks... so that's pretty good right?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您要求 Git/其他一些工具知道远程 sln 文件中添加了项目,请添加它们,然后添加我添加的项目 - 不,这不应该是您的方法。
只需修复合并冲突,以便远程添加的所有项目和您添加的项目都在那里。
If you are asking for Git / some other tool to know that there are projects added in the sln file in remote, add them, and then add the ones I have added - no that should not be your approach.
Just fix the merge conflicts such that all the projects that were added on the remote and the ones you have added are there.
首先,让我们回到已知状态。执行来创建一个名为
git reflog
并找到在您尝试执行所有这些拉动和变基之前的某个点的提交。执行 git checkout -b my-featuremy-feature
的分支,该分支指向该提交。验证它是否按预期工作,而无需服务器最近进行所有更改。现在,通过执行
gitbranch -f master origin/master
使您的master
分支与服务器上的分支匹配。现在是最困难的部分。您必须解决您更改的内容与服务器上更改的内容之间的合并冲突。这是团队工作的正常部分,你应该有条不紊地学习如何做到这一点,而不是对此发脾气。 这是一个很好的资源。 Beyond Compare是一个非常好的工具,可以帮助解决三向合并,你应该学习使用它。
有时,如果您有一个由工具生成的文件而不是手动编写的文件,则使用该工具进行更改会更容易,只需擦除本地更改并稍后将其添加回来即可。如果您不太了解 sln 文件的语法,那么您可能就是这种情况。
要仅更改 sln 文件以匹配服务器上的内容,请执行以下操作:
然后添加您的项目并照常再次提交文件。现在您希望将这些更改转移到主分支上。做:
First, let's get you back to a known state. Do a
git reflog
and find a commit that's at a point before you tried to do all this pulling and rebasing. Do agit checkout -b my-feature <commit-id>
to create a branch calledmy-feature
that points to that commit. Verify that it works as expected without all the recent changes from the server.Now, make your
master
branch match what's on the server by doinggit branch -f master origin/master
.Now comes the hard part. You have to resolve the merge conflicts between what you changed and what changed on the server. This is a normal part of working in a group and you should methodically learn how to do it rather than flipping out about it. This is a good resource on it. Beyond compare is a very good tool to help resolve 3-way merges, and you should learn to use it.
Sometimes if you have a file that's generated by a tool rather than written by hand, it's easier to use the tool to make the changes, just erasing your local changes and adding them back later. If you don't really understand the syntax of an sln file, this might be the case for you.
To change just the sln file to match what's on the server, do:
Then add your projects and commit the file again as normal. Now you want to get these changes onto the master branch. Do:
我处于“相同但不同”的情况。我把问题分成两部分。一是简单地捕获我能捕获的历史记录并将其放入名义上的快照/提交序列中。我可以识别许多不同的子项目和阶段,因此每个项目在捕获阶段都有自己的存储库。然后,我可以将它们移植在一起,并使用 git filter-branch 将其全部纳入一个大历史记录中。
对于当前的工作,我既从合适的“现在”点开始一个新的 git 存储库,又继续使用已建立的合并技术,将数据转储到 git 存储库中直到我们可以将两个过程充分融合在一起。有些人需要一些令人信服的证据。 (自我)管理意味着在新的做法被证明有效之前我们不敢放弃当前的做法。
需要一段时间才能“掌握” git 哲学,并放弃旧的根深蒂固但错误的方法。
I'm in a 'same but different' situation. I have spilt the problem into two parts. One is simply to capture what history I can and put that into a nominal sequence of snaphots/commits. I could identify a number of distinct sub-projects and phases, so each got its own repo during the capture phase. I can then
graft
them together and usegit filter-branch
to bring it all into one big history.For the current work I am both starting a new git repo from a suitable 'now' point, and also continuing with established merge techniques, with dumps into the git repo until we can fully meld the two processes together. Some folk will need some convincing & (self-)management means we daren't drop the current practice until the new one is shown to work.
It takes a while to 'get' the git philosophy, and abandon old entrenched, but wrong, methods.