svn源代碼管理規(guī)范

《svn源代碼管理規(guī)范》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。

1、svn源代碼管理規(guī)范　　篇一：開發(fā)部SVN使用規(guī)范　　XXXX股份有限公司　　開發(fā)部SVN使用規(guī)范　　1、目的：　　本制度為研發(fā)部SVN配置管理的準(zhǔn)則和依據(jù)，所有與SVN配置管理的行為都必須遵照并服從于本制度?！　?、適用范圍：　　本制度適用于研發(fā)部全體員工?！　?、名詞：　　配置管理：是指對項目生存期過程中的各階段產(chǎn)品和最終產(chǎn)品演化和變更的管理。變更控制組：是配置項變更的監(jiān)管組織?！　∨渲庙棧褐改男?yīng)該納入配置管理之下，成為受控的工作產(chǎn)品最小單位項?；€：基線是經(jīng)過正式評審和認可，作為后續(xù)工作依據(jù)的配置項集

2、合。配置審計：配置審計主要是驗證配置項的完整性和配置項的一致性?！　?、職責(zé)：　　變更控制組　　批準(zhǔn)建立基線和標(biāo)識配置項。批準(zhǔn)基線的發(fā)布。評審與批準(zhǔn)基線的更改。批準(zhǔn)由基線庫生成產(chǎn)品。項目經(jīng)理　　協(xié)助配置管理員制定配置管理計劃。定義基線和配置項。提出發(fā)布申請。　　推動項目的配置管理工作。項目組成員　　提交配置項內(nèi)容。配置管理員　　制定和維護配置管理計劃。建立和維護配置管理系統(tǒng)。標(biāo)識配置項。發(fā)布基線。執(zhí)行基線審計?！　?biāo)識、保存并分發(fā)配置狀態(tài)報告。從基線庫發(fā)布產(chǎn)品。質(zhì)量保證人員（QA）　　按照計劃和過程檢查配置管

3、理活動及其工作產(chǎn)品。報告檢查中發(fā)現(xiàn)的問題，追蹤問題直至關(guān)閉。　　5、控制要求和方法：　　操作流程　　版本庫　　本地工作副本　　首先用戶從版本庫通過網(wǎng)絡(luò)“檢出”到本地工作副本中，然后，在本地工作副本中進行增加、修改、刪除文件后“提交”到版本庫中，如果本地工作副本中版本較系統(tǒng)版本過時，用戶使用“更新”功能與系統(tǒng)上版本保持一致?！　ぬ栕?、權(quán)限申請　　1.用戶帳號注冊：新進員工沒有SVN帳號，通過郵件聯(lián)系SVN管理員，郵件正文注明　　申請SVN普通帳號，管理員處理完帳號注冊事宜后，會郵件回復(fù)。　　注：普通帳號，只

4、對個人目錄有讀取權(quán)限。　　2.權(quán)限的申請：根據(jù)員工所參與的項目，SVN管理員對其開放相應(yīng)目錄的讀、寫權(quán)限。3.賬號注銷：員工離職后，對其賬號進行注銷?！　〔僮饕?guī)范　　1.每日進行開發(fā)工作之前更新代碼，下班時提交代碼?！　?.各員工需牢記各自的賬戶和密碼，不得向他人透漏，嚴(yán)禁使用他人賬戶進行SVN各項　　操作?！　?.不要簽出整個目錄，除非特別必要，不應(yīng)同時簽出過多的項。　　4.文件提交時要求必須提交注釋，注明相關(guān)修改信息，日志信息描述的越詳細越好，讓項　　目組其他成員在看到標(biāo)注后不用詳細看代碼就能了解你所做的

5、修改。5.代碼變動及時提交，避免丟失本地修改后無法恢復(fù)。　　6.在提交之前要編譯代碼并修正錯誤。要保證新增加的文件同時被提交，否則只在你本地　　能正常工作，導(dǎo)致其它人不能編譯通過?！　?.提交之前要測試所改變的應(yīng)用，測試改變后的效果是否達到預(yù)期的目的。　　8.多次檢查提交的內(nèi)容。提交之前應(yīng)先做SVN更新或與資源庫同步，注意到SVN關(guān)于沖　　突、錯誤的信息。資源庫同步會告訴你將要提交的內(nèi)容與資源庫內(nèi)容之間的差別，確認它們是不是你真正想要提交的?！　?.如果別人和自己更改的是同一個文件，那么Update時會自動進

6、行合并，如果修改的是　　同一行，那么合并時會產(chǎn)生沖突，這種情況就需要同之前的開發(fā)人員聯(lián)系，兩個人一起協(xié)商解決沖突，解決沖突之后，需要兩人一起測試保證解決沖突之后，程序不會影響其他功能?！　?0.在更新時注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則也是需要重新編譯并　　且完成自己的一些必要測試，再進行提交。這樣既能了解別人修改了哪些文件，同時也能避免SVN合并錯誤導(dǎo)致代碼有錯。　　11.提前宣布修改計劃。當(dāng)你計劃進行修改，需要影響到SVN里的許多文件時，先通過郵　　件或者當(dāng)面通知其他開發(fā)者。例如，修改底層

7、數(shù)據(jù)庫模塊時，有可能影響到業(yè)務(wù)邏輯層調(diào)用數(shù)據(jù)庫模塊的地方。這樣其他開發(fā)者會有準(zhǔn)備，也會對修改提出意見和建議。12.每次提交盡量是一個最小粒度的修改。比如一個小功能提交一次?！　?3.不要提交不能通過編譯的代碼。代碼在提交之前，首先要確認自己能夠在本地編譯。如　　果在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫?！　?4.提交時注意不要提交本地自動生成的文件，提交的文件必須是開發(fā)者共用的程序文件，　　程序編譯中產(chǎn)生的中間文件或文件夾，如/Debug/、/Release/、*.

8、ncb、*.obj、*.o、、/build/、*.class、/classes/、/data/等不要提交到SVN里。15.SVN管理員需對SVN的所有項目定期備份。　　16.SVN的資料不允許公開給其他部門人員，確實要分發(fā)的，必須通過總經(jīng)理同意。　　篇二：源代碼及文檔管理規(guī)范　　第一章總則　　第一條為保障公司源代碼和開發(fā)文檔安全不至于泄露，保證源代碼的完整，明確源代碼控制管理流程，特制定此管理辦法。