在代码版本中来回恢复时选择哪种版本类型? +TFS VS2010

发布于 2024-11-17 05:07:53 字数 522 浏览 0 评论 0原文

我唯一的一位同事几周前离开了,现在我必须将所有内容合并在一起,为我和我的新开发人员创建一个基线工作环境。我以前的同事完成了与 Team Foundation Server 相关的大部分管理工作。

我当前的结构由 4 个分支和一个 Bugs 分支组成。分支 A 和分支 B 是我们独立的开发分支,它们是从中央开发分支(分支 C)分支出来的。中央开发分支(分支 C)源自主分支(分支 D)。 Bugs 分支不应该影响我的问题,因此它应保持未命名状态。

不久前,我在尝试将所有内容合并在一起时犯了一些错误,因此我恢复了分支 A、分支 B 和分支 C 的工作版本。

现在我已经获得了分支 A、B 和 CI 的工作版本开始将分支 A/B 合并到 C 中。我想,因为我在技术上不使用最新的代码,并且由于我已经恢复到旧版本,所以我可能必须将“版本类型”更改为“最新”以外的其他内容版本”。

版本类型

我应该更改版本类型,还是应该将其保留为最新版本并继续进行合并?

My one and only coworker left a couple weeks ago, and I now have to Merge everything together creating a baseline work environment for my new developer and I. My previous coworker had done most of the management related to our Team Foundation Server.

My current structure consists of 4 Branches and a Bugs Branch. Branch A, and Branch B were our separate Development Branches, which were branched off of a Central Dev Branch (Branch C). The Central Dev Branch (Branch C) was derived from the Main Branch (Branch D). The Bugs branch shouldn't affect my problem so it shall remain unnamed.

I made some mistakes a while ago when trying to Merge everything together so therefore I've reverted to working versions of Branch A, Branch B, and Branch C.

Now that I've gotten working versions of Branch A, B and C I want to begin merging Branch A/B into C. I figure since I'm technically not working with the newest code, and since I've reverted back to older versions that I may have to change the "Version Type" to something other than "Latest Version".

Version Type

Should I be changing the Version type, or should I leave it as Latest Version and be on my way with Merging?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

囍笑 2024-11-24 05:07:53

当我阅读问题时,分支结构如下所示:

D (Main) 
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs

快速术语(这样我可以使用简短的表示法):

  • FI = 正向集成(从父分支到子分支)
  • RI = 反向集成(从子分支到其父分支)分支)
  • 分支 C 是分支 A 和分支 B 的父级。A 和 B 是 C 的子级

从最初的问题来看,听起来存在以下状态:

  1. A 和 B两者都有尚未进行 RI 的更改C.
  2. 您恢复了 C、B 和 A 中之前的合并尝试。
  3. (?)您在每个分支中提交了回滚(使用 tf.exe 回滚...),因此当您从每个分支“获取最新”时,您将拥有工作版本而不是失败的合并版本。

这是我的建议

  1. 回滚到 A、B 和 C 的稳定版本(如果您还没有的话)。
  2. C->A,测试,A->C,验证OK。
  3. C→B,测试,B→C,验证OK。

详细信息:

  1. tf 回滚到 A 的工作版本,
    B 和 C(如果您还没有这样做
    已经)
  2. FI从C->A(C到A)

    • 尽可能解决所有冲突
    • 为您创建一个搁置集
      待合并
    • 现在在 A 中测试
      直到您确信合并是
      成功了,你已经让所有 C 与所有 A 一起工作。
    • 将合并更改提交给 A。
  3. RI 从 A 到 C,

  4. 从 C 重复步骤 2 和 3 - >B,然后 B->C

提示:“A”可以是具有最简单或最重要更改的开发人员分支。

* 如果您决定不提交更改以回滚到早期的“稳定”版本,那么您可能需要使用版本类型选项...但是如果所有三个分支都有需要回滚的更改,那么您至少需要回滚 c,然后合并 A 的先前版本。我个人更喜欢从所有 3 个分支开始,让它们的最新版本成为您想要继续的工作版本。 (合并已经足够棘手,无需合并到特定的变更集)。

您描述的场景很常见,但不是最佳的。如果 A 和 B 都频繁地合并到 C(每次进行 FI 和测试之后),那么您的合并任务将会小得多。


前进

我提出了一些建议,可以减少您未来合并的痛苦。

  1. 对于日常工作,开发人员可以使用 TFS 搁置集来处理待处理的更改,然后直接签入公共开发分支。仅当您需要隔离时才需要完整分支(例如同时处理冲突的更改或多个开发人员处理重大更改)
  2. 仅当您需要与其他开发人员更改隔离时才从公共开发人员分支创建子分支。例如,如果您正在实施一项需要两个开发人员共同工作的重大变更,您可以创建一个“功能”分支,一个或两个开发人员可以在不破坏开发人员分支稳定性的情况下处理该功能,然后尽快合并回开发分支特性稳定。
  3. FI 经常从父母到孩子合并!否则合并将变得非常难以协调。

对于您的团队规模而言,您可能拥有太多分支(除非您具有不应并排存在的并行功能)。理智随着你远离主分支的数量而降低。我会让所有开发人员在单个 Dev 分支 (C) 中工作,然后仅在需要时创建一个短期功能分支(然后在功能足够稳定以合并到 Dev 分支后立即关闭该分支。

TFS 分支指南 是一个很好的资源,提供漂亮的分支模式图片和大量指南,包括可能更适合您未来需求的不同模式。

享受吧! -泽芬

As I read the question the branch structure looks something like the following:

D (Main) 
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs

Quick terms (so I can use short notation):

  • FI = Forward Integration (from Parent branch to a child branch)
  • RI = Reverse Integration (from a child branch to it's parent branch)
  • Branch C is the parent of branch A and branch B. A and B are children of C.

From initial question it sounds like the following state exists:

  1. A and B both have changes that have not been RI'd to C.
  2. You reverted previous merge attempts in C, B, and A.
  3. (?) you committed the rollback in each branch (using tf.exe rollback ...) so when you "get latest" from each branch you have your working versions rather than the failed merge versions.

Here's my recommendation:

  1. rollback to stable versions of A, B, and C (if you haven't already).
  2. C->A, test, A->C, verify OK.
  3. C->B, test, B->C, verify OK.

Details:

  1. tf rollback to working version of A,
    B, and C (if you haven't done so
    already)
  2. FI from C->A (C to A)

    • resolve all conflicts you can
    • create a shelveset for your
      pending merge
    • Now test in A
      until you are confident the merge was
      successful and you've got all of C working with all of A.
    • Commit the merge change to A.
  3. RI from A to C,

  4. Repeat steps 2 and 3 going from C->B, then B->C

TIP: "A" can be whichever developer branch has either the easiest or most important changes.

* If you decide not to commit the change to rollback to your earlier "stable" version then you probably need to use the Version type option... but if all three branches have changes needing rollback then you at least need to rollback c, then merge previous version of A. I'd personally prefer starting with all 3 branches having their latest be the working versions that you want to proceed with. (Merges are already tricky enough without having to merge to a specific changeset).

The scenario you described is very common, but is not optimal. If both A and B have been making frequent merges to C (after doing FI and testing each time) then your merge task will be much smaller.


MOVING FORWARD

I a couple recommendations that may reduce your future merge pains.

  1. For daily work developers can use TFS shelvesets for their pending changes, then check directly into a common dev branch. Full branch is only needed if you require isolation (such as working on conflicting changes at same time OR multiple developers working on a breaking change)
  2. Create a child branch from the common Developer branch only when you need isolation from other developer changes. For example, if you are implementing a breaking change that requires both devs to work on you can make a "feature" branch, one or both devs can work on the feature without destabilizing the developer branch, then merge back to Dev branch as soon as feature is stable.
  3. FI Merge from parent to children often! Otherwise merges become very difficult to reconcile.

You may have too many branches for the size of your team (unless you have parallel features that should not exist side-by-side). Sanity decreases with number of branches you are away from Main. I'd have all developers work out of single Dev branch (C) then make a short-lived feature branch only when needed (then close the branch as soon as feature is stable enough to merge to Dev branch.

The TFS Branching Guide is a good resource for pretty branching pattern pictures and lots of guidance including different patterns that may better suite your needs going forward.

Enjoy! -Zephan

平安喜乐 2024-11-24 05:07:53

如果 A 和 B 是在 C 上创建的开发分支(我的意思是新代码/功能单独添加到主开发中的分支),并且它们已经达到生命周期的终点,那么它们需要重新集成回 C 中将 A 或 B 的最新版本合并到 C 中是正确的做法。

If A and B are development branches (by that I mean a branch where new code / features is added separately to the main development) created off C and they have reached the end of their life then they need to be re-integrated back into C. Merging the latest version of A or B into C is the right thing to do.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文