我目前在一家小的金融企業幹it，負責乙個專案的版本管理，用svn。
根據svn的思想，目前的具體實踐步驟如下：
1、新需求的開發在trunk下完成。
2、bug可以在trunk下修改，也可以在對應的branch下修改，但是改完後必須互相進行合併（merge）操作，使得trunk和branch下都是bugfixed的**。
3、當專案經理認為trunk下的開發工作已經實現了一定的需求，可以發布一新版本時，經理跟業務部門再次確認即將發布的需求，之後開發組根據最後確定的需求找出各個檔案最新的版本，建立分支。
4、開發組根據建立的新分支進行編譯，並部署給測試人員測試，同時把初始的分支打第乙個標籤tag。
5、當測試人員在測試過程中發現有bug時，及時反饋給開發組，開發組可以在對應的branch下更改**，也可以在trunk下更改，改完後，bug的問題在兩邊都必須解決（通過合併操作實現）。重新編譯，部署給測試人員重測，同時將最新的**再打分支tag。
6、在測試的同時，開發組可以在trunk下繼續進行新需求的開發，之後又可重複步驟3的過程。
7、當測試人員對某個branch下的**（n項需求）完成了嚴格的測試，認為可以通過時，開發組再根據部門的程式上線流程，從其branch下最後的tag中取出相應的服務更新到生產。
[b]現在有如下問題：
發布的版本解決了業務提出的5個需求，測試也是針對這5個需求進行測試，但是測完後即將上線時，業務卻又說只需要發布其中的5個需求中的3個，這時他們又沒時間來得及重測，如何辦？[/b]
乙個方便版本管理員的git log shell指令碼
直接分享 old ifs ifs ifs arr 1 ifs old ifs filename date y m d date h m s touch filename.sql for s in do echo e 033 41 33m s 033 0m if 3 4 then git log af...
修正了版本管理實現中的乙個bug
按先前的方法 copy當前版本資料，修改versionid為系統預留id後再插入，uc的id已不在是原來的id，按versionid過濾後看不到原來的uc資料 之所以這樣做 是想偷懶，直接將歷史記錄維護在主表中 正確的做法是 歷史記錄維護在history表中，主表永遠是當前最新版本資料 系統預留ve...
提供乙個軟體版本管理規則的模板
此規則用於指導規範開發工程師打包軟體產品安裝檔案時的版本設定行為。此規則中的 版本 是指由相關開發工程師所提交的安裝檔案的版本，比如 msi的版本。此規則涉及 軟體 包括且不限於公司下列產品 可根據實際情況填寫 以及相關補丁。軟體的版本由相關開發工程師負責打包及設定。此規則適用於標準產品打包及專案型...