[點(diǎn)晴永久免費(fèi)OA]項(xiàng)目由多個(gè)人員（公司）開發(fā)，但是不想讓他們互相看到彼此的代碼，除了手動(dòng)合并代碼該怎么辦？
公司的系統(tǒng)由多個(gè)公司共同開發(fā)，但是領(lǐng)導(dǎo)考慮到git做分支會(huì)導(dǎo)致代碼泄露，想尋求一個(gè)方法可以讓各公司可以自己提交發(fā)布自己開發(fā)的部分。目前的方法是各個(gè)公司將代碼寫完后，由我統(tǒng)一手動(dòng)合并發(fā)布，這樣參與的公司越來越多，會(huì)導(dǎo)致忙不過來或者無法及時(shí)發(fā)布的問題。目前是一個(gè)公司開發(fā)一個(gè)模塊就是一個(gè)倉(cāng)庫(kù)，每次其他公司需要合并，我再去拉取他們最新的代碼，然后把改動(dòng)的目錄給手動(dòng)覆蓋到主項(xiàng)目的文件夾中。  唯一丶：
SVN 好像可以給目錄權(quán)限 2 月 3 日來自美國(guó) kumfo：
個(gè)人感覺是不是機(jī)制出啥問題了？這樣來說，各個(gè)公司開發(fā)的東西當(dāng)作一個(gè)獨(dú)立的產(chǎn)品來做不就行了嗎？然后各個(gè)公司的東西都獨(dú)立部署，然后涉及相互調(diào)用部分就提供接口唄，公用一套鑒權(quán)方案。 2 月 3 日來自浙江 git submodule 將單獨(dú)的模塊獨(dú)立出來，用submodule 的形式發(fā)布到一個(gè)新倉(cāng)庫(kù)，成員自行在新倉(cāng)庫(kù)中提交代碼，你只需要維護(hù)公共的就可以了。 這種問題不是在代碼管理層面解決的，而是在系統(tǒng)架構(gòu)層面解決的。舉個(gè)例子，微信上跑了各種小程序，都用了同一套開發(fā)規(guī)范，但是并不各開發(fā)商都把微信的代碼下載下來協(xié)同開發(fā)吧。 做應(yīng)用系統(tǒng)也是一樣的道理，如果應(yīng)用系統(tǒng)的架構(gòu)設(shè)計(jì)中考慮了第三方接入的“接口”那任何第三方都可以在按照規(guī)范開發(fā)的情況下，把程序接入大系統(tǒng)，不需要知道其他人的代碼。框架層只需要發(fā)布一個(gè)規(guī)范，以及一套基礎(chǔ)接口框架就可以了。 說起來簡(jiǎn)單，做起來難，不僅要有大局，還有很多細(xì)節(jié)需要處理。既然你們是買的一套框架，如果這套框架本身不支持插件式，可能要實(shí)現(xiàn)會(huì)有一些難度。 目標(biāo)可以參考各種小程序框架，應(yīng)用市場(chǎng)框架。技術(shù)可以參考微服務(wù)、微前端、插件化（比如 VSCode 就是經(jīng)典中的經(jīng)典）。具體該怎么做，就是具體情況具體分析了。 感覺這種代碼管理方式有問題。 如果有代碼合并，那么下一次fix bug或者開發(fā)新功能，肯定需要拉去全部代碼，不然怎么基于最新代碼做開發(fā)呢？ 我提供一種思路，就是把網(wǎng)站的功能拆分成小模塊，按照模塊來創(chuàng)建倉(cāng)庫(kù)。不同公司維護(hù)不同的模塊。模塊間通過API約定好。 你只需要管理溝通好API，剩下的代碼開發(fā)維護(hù)，由不同的公司維護(hù)不同的代碼倉(cāng)庫(kù)。 前端， 如果樓主只是想解決手動(dòng)合并的問題，那 gitlab pipeline、github actions、jenkins 這種都是合適的自動(dòng)化工具 從描述上看，你的人工工作應(yīng)該是可以自動(dòng)化的。可以，寫一個(gè)網(wǎng)頁(yè)，讓開發(fā)者自己填寫相關(guān)信息，然后自動(dòng)修改對(duì)應(yīng)的文件。如果怕出錯(cuò)，可以加一個(gè)人工審核的步驟，審核通過再提交。 該文章在 2023/3/25 0:27:37 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
