您如何避免在错误的分支上工作？

27

通常，小心就足以防止问题发生，但是有时我需要通过检查随机变量的源代码控制路径来仔细检查我正在处理的分支（例如 “嗯……我在dev分支中，对吗？”）文件。

在寻找一种更简便的方法时，我想到了相应地命名解决方案文件的名称（例如 MySolution_Dev.sln），但是每个分支中的文件名不同，因此我无法合并解决方案文件。

没什么大不了的，但是您有没有使用任何方法或“小技巧”来快速确保您位于正确的分支中？我正在将Visual Studio 2010与TFS 2008一起使用。

version-control  visual-studio  team-foundation-server  branching 
— 亨尼
source
2
这听起来像是编写VS 2010扩展的不错的选择，它允许某种可配置的视觉提示来指示分支。也许按照用户设置为解决方案资源管理器的背景上色（我会为Dev做绿色，对于QA做黄色，对于Prod做红色）。
— Jesse C. Slicer
不错的主意，即使是VS标题栏上的指示器也有帮助。
— henginy 2011年
1
我说那应该很有效。我将bash提示设置为包括git分支，以及源文件是否干净或它们是否需要签入
— Daenyth 2011年
TFS没有等于git status或的东西hg status吗？
我使用VS用户界面进行TFS操作，所以我真的不知道。
— henginy 2011年

Answers:

16

我正在使用此 http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

将标题更新为例如：

开发 \ myproject

要么

主 \ myproject

要么

发行 \ myproject

希望能帮助到你

— 林诺克
source
似乎可以做到，我将尝试一下
— 。– henginy
我将此扩展用于此目的。实际上，当我看到ynnok已经拥有链接时，我将要发布该链接。
— Bobson
1
我最终使用了这个，因为我可以在我所在分支的标题中看到它。非常棒！！！
— Piotr Kula
是的，确实非常方便！
— henginy 2013年
16

用不同的名称命名工作目录。也就是说，如果您的项目名为“ MY_PROJECT”，则为每个分支创建一个不同的工作目录。如果有一个名为“ dev”的分支，则需要一个主干目录和一个dev开发目录，如下所示：

~/henginy/projects/MY_PROJECT-trunk
~/henginy/projects/MY_PROJECT-dev
— 马修·罗达图斯（Matthew Rodatus）
source
实际上，工作目录的名称不同。但是，对于已经打开的Visual Studio，（例如，在我休息喝咖啡后回到办公桌前），我必须检查文件的路径以查看目录。所以我想这是最简单的方法，无法避免吗？
— henginy 2011年
2
@henginy这是一个很好的说明。为了确定是否在Visual Studio中，我将鼠标悬停在打开文件的选项卡上。它将显示完整文件系统路径的工具提示，从中可以确定根目录是“ -dev”还是“ -trunk”。尝试一下，看看它是否适合您。
— 马修·罗达图斯
1
是的，这正是我“检查随机文件的源代码控制路径”的方式，并且我试图找到一种更快的方法：）
— henginy 2011年
@henginy哦，对。您在OP中说过。我不知道有什么更好的办法可以解决。听起来我根本没有改善您的情况。:-(
— Matthew Rodatus 2011年
我应该在问题中更好地阐明这一点。谢谢您的帮助！
— henginy 2011年
8

我不在通用开发人员或主干分支中工作。

我总是在功能分支中工作。功能完成后，请按照以下步骤操作。

  1. 开源控件资源管理器。
  2. 从dev合并到当前功能分支。
  3. 解决所有冲突，并确保一切正常。
  4. 再次签到。将功能合并到dev分支中。
  5. 开放的开发解决方案。
  6. 签到开发分支。
  7. 关闭开发人员解决方案。
  8. 让CI构建和部署。

我只一次打开dev分支几分钟，然后立即关闭它。

— CaffGeek
source
7

您可以在每个分支中创建一个空文件，例如在主干中创建THIS_IS_TRUNK.txt，在DEV中创建THIS_IS_DEV.txt。

— 罗伯斯特尔
source
2
那实际上可能行得通。特别是在文件名前面加一个下划线，以在解决方案资源管理器中将其上移。
— henginy 2011年
6

我从命令行完成了很多（D）VCS工作。我强烈建议您迅速显示您的位置。例如，在Git仓库中的提示如下（我也对SVN这样做）：

[BranchName]RepoTop/path/to/current/wd >>

并且如果仓库当前脏了（未提交的更改）：

[BranchName!!]RepoTop/path/to/current/wd >>

如果登录到产品，我也将背景设置为红色，诸如此类。我发现简单的视觉通知对我来说超级有效。

您提到，回到计算机后，您经常会看到这种情况。我发现了一个便条纸，当我离开时，我当前的焦点（分支，错误号，功能）固定在键盘上，这使我可以快速恢复工作，而不是重新创建上次所做的事情，非常有效。 。

— 米切希尔斯洛普
source
3

我一直在使用VSCommands扩展（使用Visual Studio 2012，但有2010版本），它方便地将分支名称放在屏幕的左上角以及解决方案资源管理器中。

不以任何方式与该产品相关联，只是一个满意的用户。

— R0MANARMY
source
1
看起来很酷，很可惜，您必须为可能不需要的所有额外费用买单：(
— Piotr Kula
2

我通过在一个分支中执行几乎所有操作来避免在错误的分支中工作（在主干中-按照所谓的“不稳定主干” 分支策略）。

我被迫更新分支的情况很少见-这些是生产前和生产后的错误修正（产品候选代码隔离在分支中）。由于这些修复程序也应该在主干中，因此我通常会在主干中在那里进行草稿，测试和验证，然后移植到产品分支。通常，移植仅涉及1到5个文件的简单副本即可进行分支和构建检查。

  • 我还有些幸运，在我的大多数项目中，管理层更愿意说服客户使用较新的发行版而不是对旧发行版进行修补-这使分支机构中更新的后期制作部分几乎可以忽略不计。
— 蚊蚋
source
不必维护以前的版本确实很不错。在那种情况下，我只想将分支用于实验目的。
— henginy 2011年
@henginy我无法回忆起完全不必维护以前版本的情况。但是，管理态度可能会在这里产生很大的变化：取决于它，例如，可以在较旧的分支机构中每年实施1-2个修补程序，或者总是把这一半时间弄乱了
— gna
1

具体答案取决于您所使用的版本控制软件，但是通常会有一个命令可以使您轻松查看正在使用的分支。例如，对于Subversion，svn info在目录中使用命令查看该分支的URL。如果您对特定文件更感兴趣，也可以指定：

caleb-dev$ svn info foo.c 
Path: foo.c
Name: foo.c
URL: https://svn.mycompany.com/repo/sample/branches/caleb-dev/foo.c
Repository Root: https://svn.mycompany.com/repo/sample
Repository UUID: d62f7aef-3ad2-6098-12a-c16647d854ab
Revision: 1042
Node Kind: file
Schedule: normal
Last Changed Author: caleb
Last Changed Rev: 1031
Last Changed Date: 2011-06-07 15:28:27 -0400 (Tue, 07 Jun 2011)
Text Last Updated: 2011-06-08 03:08:12 -0400 (Wed, 08 Jun 2011)
Checksum: 123456789098765432123456789098

从URL中，我可以看到我的foo.c副本在caleb-dev分支中。

我不需要经常这样做，因为我的本地目录与分支具有相同的名称。快速查看我的命令行提示符通常足以确认我在正确的目录中，并且因此在正确的分支中工作。

— 卡列布
source
1

这里已经有很多答案，但是没有一个涉及我们可以使用的简单解决方案：对于每个分支，创建一个包含开发环境的新VM，然后从正确的分支中签出。您只需要这样做并使其一次正确，然后就可以将VM切换到分支。

— 梅森·惠勒
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.