基於同份程式碼不同產品線的解決辦法

文章背景

公司的其中一條產品線其實比較奇怪，給乙方的產品其實都是基於同一個專案，但是彼此之間又或多或少有些區別，例如：包名、圖示、歡迎介面以及一部分使用場景的定製需求。

之前的解決方法：

在一個已經完工的工程下將原來做好的app模組複製成一個新的module，再進行區別程式碼、檔案的修改。
優點
可以共用其他module，程式碼在同一個工程下不需要切換。
缺點
特別明顯，由於是程式碼的複製貼上，若是app部分的程式碼出了問題，有幾個專案就要手動更新幾次程式碼。

現在的解決方式：

在公司從svn升級到git形式的程式碼管理之後，新的寫法在我的腦中冒出來了——
使用git的分支管理進行不同產品線的程式碼管理。

基礎分支為master和develop，develop則是開發分支，還有可能產生dev-開頭的分支，比如為了加入路由而產生的dev-router，為了加入定位功能而產生的dev-location。它們開發完了之後將合併入develop分支，就可以功成身退了。為了確保具體專案分支從develop分支中以merge的方式獲取公共程式碼更改，還有一些需要注意的點：

• 打包一個專案一般需要修改的地方有：

1. data/proxy/UrlCollection.java 中的 BaseUrls
2. global/AppConfig.java 中的 API_UNION_ID
3. res/layout/fragment_main_page.xml 中模組的顯示隱藏
4. mipmap-xhdpi/ic_app.png 應用圖示更改
5. mipmap-xhdpi/login_hospital_logo.png 登入介面圖示更改
6. mipmap-xhdpi/welcome_image.png 歡迎介面更改

• 從develop引申出的具體專案命名規則遵照省份_專案_建立日期的規則進行分支建立
• 包名不得在分支上更改，而是在打包時更改，讓分支保持從develop中merge的能力
• master分支作milestone的用途
• 為了避免merge conflict ，對develop分支中的UrlCollection/AppConfig/fragment_main_page的修改要特別慎重
• 建立一個新專案一般需要修改的地方有：

1. AndroidManifest中的包名 + app/build.gradle 中的applicationId
2. AppContext中的isDebug設為false

新的想法

為了滿足元件化的願景，有了以下想法：

1. 多module 各歸各的專案管理
2. 主專案是完整的 分專案是隻有程式碼的版本