鏈接提交問題 - 最佳實踐 - 優文庫

我們試圖介紹我們希望的一個良好的開發實踐：每個提交必須與問題跟蹤系統中的問題相關聯。（爲了滿足這個要求，創建一個新問題是完全可以接受的。）鏈接提交問題 - 最佳實踐

我們的問題跟蹤器（Redmine）和DVCS（Mercurial）很好地集成在一起，但我們遇到了一個問題：如果開發人員需要提交某些內容離線時？目前，Redmine在線訪問，Mercurial通過TortoiseHG（Windows）或shell（Linux）訪問。

我不知道任何工具（例如，在Windows桌面客戶端，商用或免費的），允許使用的管理平臺脫機（創建問題，而不是僅僅查看它們）的。我們甚至不介意將Redmine數據庫複製到每個開發人員的機器上，但是同步數據庫並不容易。

我們該怎麼辦？我可以看到以下選項：

從Redmine切換到具有脫機支持的問題跟蹤器。 [我不認爲Trac的是好得多]
黑客一起一些解決創造管理平臺下線的問題。 [不知道如何，而不會造成而不是解決問題]
放棄，承諾必須始終指向現有問題的想法。 [但它似乎是這樣一個好主意]
逆向鏈接提交問題。 [這要求開發人員將每個問題的描述寫入臨時位置，稍後將其複製到Redmine，然後手動將新問題與提交相關聯;低效且易出錯]
禁止離線提交（因此禁止脫機工作）。 [看起來很愚蠢，因爲選擇DVCS主要是爲了讓離線工作]

你會推薦什麼？

來源

2012-08-17 max

您是否正在討論一個開發人員在離線時發現錯誤的工作流程。在離線狀態下診斷並解決問題，然後想要提交修復程序（仍處於離線狀態）？這聽起來像開發驅動問題跟蹤系統而不是其他方式？當前問題的優先順序是什麼？ – 2012-08-24 10:53:48

@NickPierpoint：我們正試圖走向問題追蹤者，在可能的情況下推動開發*，但您的例子仍然經常發生 - 例如我旅行時。當然，我不會了解最近的優先級更改;大概有人在辦公室可以解決這些問題，至少我可以對舊問題做一些有用的工作。這種安排看起來是否合理？ – max 2012-08-24 17:43:06

因此，在旅行時，您無法訪問互聯網？沒有辦法聯繫辦公室來解決問題？很難相信你會長時間沒有聯繫 - 如果是這種情況，那麼在當地單獨進行而不能單獨接觸，然後遵循Raghuram的建議，當你重新出現時。 – 2012-08-29 11:46:47

離線處理問題並在本地提交而另一個將問題推向上游（稱爲指定服務器）是一回事。

前者可以在不使用redmine的情況下完成。要麼存在一個現有的redmine問題，要麼需要創建一個新問題並將其與提交相關聯。

在向上遊推送更改之前，問題ID可以更新爲editing the last commit或collapsing multiple commits to one。後者可能是一個更好的選擇，因爲每個問題都會有一個上游提交 - 如果需要，可以輕鬆回滾。

來源

2012-08-17 10:58:29 Raghuram

非常有趣，我不知道我可以編輯提交或摺疊它們。我想這與選項4幾乎完全相同。唯一的區別是，不是追溯性地將問題鏈接到提交，而是追溯編輯提交。不幸的是，我們仍然需要臨時存儲每個提交的信息，然後將其複製/粘貼到redmine並提交消息。 – max 2012-08-17 17:50:28

在我的地方，我們有提交鏈接到具體問題（在bugfixing提交的情況下）。系統很簡單：

在提交消息中，您在方括號內鍵入錯誤號。
當我們做一個發佈時，我們收集自上次發佈以來所做的所有提交。
通過正則表達式，我們提取已修復錯誤的ID。
我們使用此列表更新錯誤數據庫並創建更改日誌。

我認爲這裏的重要教訓是bug數據庫和版本控制系統不一定是明確鏈接的。通過語法約定，它可以很容易地進行聚合並得到一個概述，這使得手動更新錯誤數據庫變得容易（足夠）。

編輯：關於「脫機工作」的一部分。 Mercurial是DVCS，並不意味着經常連接。接受這一點，允許本地提交併在您恢復在線和/或推送時處理錯誤數據庫。

來源

2012-08-17 09:14:55 Mizipzor

但是，如果您無法訪問錯誤數據庫，您如何知道在方括號內寫什麼？如果這個錯誤在數據庫中甚至還沒有發現（當離線時），那該怎麼辦？ – max 2012-08-17 17:54:02

@max與mercurial其易於編輯（未發表）的歷史。團隊中的每個人都有不同的策略。我自己，我通常只是使用像[XXXX]這樣的佔位符，直到我重新聯機並檢查錯誤數據庫中的數字（或報告錯誤以獲取它）。 – Mizipzor 2012-08-20 07:29:39

Redmine有效地具有創建問題的脫機功能：它可以配置爲接受新問題並通過電子郵件發佈更新。大多數電子郵件客戶端都離線工作（將郵件臨時存儲在發件箱中，直到用戶上線）。

電子郵件還可以提供（非常有限）的離線查看模式。如果我通過電子郵件通知每個新問題並進行更新，並自動將這些電子郵件移動到單獨的文件夾中，我可以找到相應的問題編號。

這並不理想，但它可以作爲臨時解決方案，直到redmine添加離線模式。當然，如果這項工作是由太多人完成的，那麼redmine沒有足夠的解決方法來解決衝突的風險（例如，兩個人試圖改變問題狀態）。

DVCS與（集中式）問題跟蹤器的集成還有一個普遍且不可避免的問題。假設兩個開發人員解決某個問題，並將其提交鏈接到它。當他們將他們的提交都推到與redmine綁定的存儲庫時，在解決衝突的過程中，只有其中一個解決方案會被保留。這個問題仍然會與個別提交相關聯，但沒有明確指出其中一個提交實質上已被另一個提交棄用。

來源

2012-08-19 16:29:06 max

鏈接提交問題 - 最佳實踐

回答

相關問題