我试图合理化两个似乎相关的视角(或者至少提供非常相似的功能):'Git Repository'视角(我在添加EGit后得到)和'Team Synchronizing'视角(我认为是EE分布的一部分).
据我所知,我能够让Git Repository工作(使用GitHub),或至少大部分功能:'Git Staging'窗口工作正常,我可以通过拖动文件来提交'未分级更改为"分阶段更改",然后单击"提交"图标.然后我可以通过右键单击工作区 - >遥控器 - >原点 - >网址,从"Git存储库"窗口推送我的更改,然后选择从菜单推送(是'正确'程序吗?).
通过"团队同步"的观点,即使设置它也没有运气.一旦选择'Synchronize ...'菜单,Git,然后我看到一个表(它是什么?).我正在为Destination尝试各种值(否则,无法点击Finish按钮),但无论我做什么,它都会告诉我所有项目都没有"更改".
右键单击项目并选择"团队"时,还有许多上下文菜单项.这些是什么?
在 CVS 中,团队同步是管理传入和传出更改的唯一合理方法。您可以从这一视图更新/合并传入的更改并提交传出的更改。由于每次提交都是离散的并且是非原子的,因此视图非常适合此工作流程。
然而,在 EGit 中,您已经有了用于添加、提交、推送、拉取和合并的明确操作。因此,团队同步很大程度上超出了正常工作流程。它的行为很像补丁中的美化同步 - 您选择要比较工作目录的分支,它会向您显示差异。然后,您可以集体或单独应用这些更改,但它不会获取上下文,即它不会创建合并点或诸如此类的东西。
因此,您应该训练自己,除非有特殊原因,否则不要使用。例如,也许您有两个分支 A 和 B。有人对 B 进行了更改,而您只需要其中的一小部分,因此您可以使用团队同步来显示差异并仅应用您需要的更改。或者,也许您只是想压缩分支 B 上的所有更改,并将它们称为 A 中的单个提交。然后,当您无论如何都要扔掉 B 或其远程分支时,您可能会使用团队同步,而不是用 rebase 搞砸。 。
| 归档时间: |
|
| 查看次数: |
9629 次 |
| 最近记录: |