1. 開工前的思考為什么要先搞定項目管理平臺Day 2 的學(xué)習(xí)內(nèi)容正式從本地代碼走向團(tuán)隊協(xié)作。昨天還在折騰 Flutter SDK 和 OpenHarmony 環(huán)境的時候我就意識到一個問題Flutter 工程結(jié)構(gòu)復(fù)雜、依賴鏈長再加上 Flutter 對 OpenHarmony 的適配分支本身就處于快速迭代期如果沒有一個順手的管理平臺代碼很容易變成一團(tuán)亂麻——改了什么不知道、哪里出了問題回溯不了、多人協(xié)作時更是災(zāi)難。所以 DAY 2 的核心任務(wù)很明確打通 AtomGit 這個項目管理平臺把 Flutter for OpenHarmony 的工程接入進(jìn)去順便把項目管理的整套工作流搭建起來。為什么選 AtomGit一句話總結(jié)它是國內(nèi)可以直接訪問、體驗接近 GitHub 的代碼托管平臺而且 Push 代碼時不用操心網(wǎng)絡(luò)問題。對于 OpenHarmony 開發(fā)這種動不動要拉大倉庫、同步上游源碼的場景平臺的可訪問性和穩(wěn)定性是第一位的。先說說這天的學(xué)習(xí)目標(biāo)了解 AtomGit 平臺的核心能力代碼托管、Issue 管理、Pull Request、WebIDE 等創(chuàng)建適配 OpenHarmony 的 Flutter 工程并成功推到遠(yuǎn)端配置項目基礎(chǔ)信息建立分支管理和協(xié)作規(guī)范掌握本地 Git 工作流與平臺功能的配合方式整個過程走下來有一個很深的體會項目管理平臺不是裝個軟件、建個倉庫就完事了。真正高效的項目管理是把工具的機制和團(tuán)隊的習(xí)慣融合在一起。這篇筆記會把 DAY 2 的實操過程和思考完整記錄下來包括踩過的坑和最后穩(wěn)定下來的工作流模式。適合誰來參考準(zhǔn)備在 OpenHarmony 上跑 Flutter、需要團(tuán)隊協(xié)作或長期維護(hù)項目的開發(fā)者以及想知道 AtomGit 到底怎么用的同學(xué)。如果你是打算一個人單干、純研究性質(zhì)的項目平臺也照樣能用只是你可以跳過部分團(tuán)隊協(xié)作配置。2. AtomGit 核心能力與選型分析2.1 AtomGit 能做什么和 GitHub/Gitee 比有什么不一樣AtomGit 是國內(nèi)開源的代碼托管平臺由開放原子開源基金會牽頭建設(shè)和 OpenHarmony 本身就是同一生態(tài)體系。實際操作下來它在以下幾個方面和 GitHub / Gitee 的體驗做了取舍首先速度真的快。無論是 HTTPS 克隆還是推送AtomGit 在國內(nèi)網(wǎng)絡(luò)環(huán)境下都很順暢。我在這一天里反復(fù) clone、push 了無數(shù)次沒有一次因為網(wǎng)絡(luò)中斷而重試——這對于拉取 OpenHarmony 相關(guān)大倉庫的場景來說體驗提升是實打?qū)嵉?。GitHub 動輒連接超時Gitee 高峰期偶爾也會卡AtomGit 目前的表現(xiàn)非常穩(wěn)定。其次功能完整度不輸主流平臺。AtomGit 提供了倉庫管理、Issue 系統(tǒng)、Pull Request、里程碑、Wiki、WebIDE、CI/CD 等一套完整的項目管理能力。和 GitHub 的騰飛工作流相比AtomGit 的 MRMerge Request即合并請求機制完全夠用。權(quán)限體系也做得比較細(xì)支持私有倉庫、團(tuán)隊分組、分支保護(hù)規(guī)則這類功能。再者和 OpenHarmony 生態(tài)強相關(guān)。AtomGit 本身就是開源領(lǐng)域的基礎(chǔ)設(shè)施項目之一國內(nèi)不少開源項目都托管在上面。如果做 OpenHarmony 相關(guān)的開發(fā)把代碼放在 AtomGit從生態(tài)歸屬感和社區(qū)協(xié)作角度看都比較自然。對比一下三個平臺的場景差異對比維度AtomGitGitHubGitee國內(nèi)訪問速度非常流暢不穩(wěn)定較好但高峰擁堵私有倉庫免費免費(有限額)免費MR/PR 流程支持支持支持OpenHarmony 相關(guān)項目較多且集中分散部分CI 能力支持強大支持社區(qū)生態(tài)快速成長中全球最大國內(nèi)成熟2.2 學(xué)習(xí)場景下的平臺選擇思路我們得想清楚一個問題DAY 2 選擇 AtomGit到底是為了什么目的在學(xué)習(xí)場景下代碼托管平臺承擔(dān)的角色不僅是“備份代碼”更要作為學(xué)習(xí)和項目的記錄載體。我在實際使用中發(fā)現(xiàn)AtomGit 很適合這種用途Issue 可以當(dāng)作學(xué)習(xí)筆記的追蹤工具比如我需要完成“Flutter 側(cè)與 OpenHarmony 側(cè)的雙向通信 Demo”就建一個 Issue把需求、參考鏈接、截止時間全部放進(jìn)去讓學(xué)習(xí)任務(wù)化。PR/MR 流程可以幫助理解開源協(xié)作模式哪怕是個人項目我也建議走分支開發(fā) MR 合并的流程提前養(yǎng)成專業(yè)習(xí)慣。里程碑功能可以做學(xué)習(xí)階段規(guī)劃把 Day 1 到 Day 30 的學(xué)習(xí)任務(wù)掛到里程碑下每周看一下進(jìn)度。所以選擇 AtomGit 不只是“用個平臺存代碼”而是要在上面長出一個比較規(guī)范的項目管理體系。這一天的學(xué)習(xí)后半段我明顯感覺到代碼還是那個代碼但當(dāng)項目有了結(jié)構(gòu)化的管理方式后整個學(xué)習(xí)節(jié)奏和心理狀態(tài)都變了——每天該做什么、做了什么、遇到什么問題一眼就能看清。2.3 平臺賬號準(zhǔn)備與倉庫規(guī)劃動手操作之前先做簡單準(zhǔn)備AtomGit 支持通過手機號注冊也支持掃碼登錄整體流程不到五分鐘就能搞定。注冊后建議順手完善個人主頁信息包括頭像、個人簡介、常用技能標(biāo)簽這在后續(xù)參與開源協(xié)作時會讓對方更快了解你的背景。倉庫規(guī)劃很關(guān)鍵。我當(dāng)時把倉庫分成了三類學(xué)習(xí)倉庫存放每天的練習(xí)代碼、筆記、Demo對應(yīng) DAY 2 里創(chuàng)建的 Flutter for OpenHarmony 工程工具倉庫存放自己封裝的一些輔助腳本、環(huán)境配置模板團(tuán)隊/協(xié)作倉庫多人參與的正式項目DAY 2 只需要建立第一個——學(xué)習(xí)倉庫。倉庫命名建議清晰但不要太長我用的名稱是flutter_oh_day2_demo一眼能看出用途和階段。如果未來要做成系列也可以考慮一個總倉庫 子目錄的方式。3. 創(chuàng)建倉庫與本地 Flutter 工程初始化3.1 AtomGit 倉庫創(chuàng)建的關(guān)鍵參數(shù)在 AtomGit 上新建倉庫主要會遇到幾個配置項倉庫名稱、描述、可見性公開/私有、初始化選項是否添加 README、.gitignore、License。我個人的建議是名稱盡量用項目語義比如flutter_oh_sample不要用test、aaa這類無意義名字描述寫清楚技術(shù)棧和用途比如 “Flutter application adapted for OpenHarmony, showcasing basic interaction”可見性學(xué)習(xí)階段可以公開方便以后在簡歷里展示但如果涉及個人敏感配置或公司業(yè)務(wù)果斷選私有初始化選項建議勾選 README 和 .gitignoreAtomGit 會根據(jù)倉庫語言推薦對應(yīng)的模板這里有一個點要注意如果勾選了初始化 README那么遠(yuǎn)端倉庫會有一次初始提交。第一次 push 本地代碼前需要先拉取合并否則會提示遠(yuǎn)端有更新。我在這次操作時就是先讓 AtomGit 生成了 README 和 .gitignore然后本地執(zhí)行g(shù)it pull origin master --allow-unrelated-histories合并掉兩段不相關(guān)的提交歷史。3.2 本地 Flutter 工程初始化細(xì)節(jié)Flutter for OpenHarmony 工程的初始化方式和標(biāo)準(zhǔn)的 Flutter 工程略有不同。如果你是使用 OpenHarmony 的 Flutter SDK 分支例如從 Gitee 上 openharmony 相關(guān)組織拉取的 flutter 代碼倉需要用對應(yīng)的 flutter 命令來創(chuàng)建項目而不是直接用官方的 flutter。整個初始化流程如下把 OpenHarmony 適配版的 Flutter SDK 路徑配置好確保命令flutter --version輸出的是適配版本執(zhí)行flutter create生成新工程例如flutter create --org com.example --platforms ohos flutter_oh_demo注意--platforms參數(shù)OpenHarmony 適配版的 Flutter SDK 通常支持ohos這個平臺標(biāo)識。如果你的 SDK 版本不支持該參數(shù)可以直接創(chuàng)建后用 DevEco Studio 打開再手動補充 ohos 目錄的工程配置。創(chuàng)建出來的工程包含標(biāo)準(zhǔn)的 Flutter 目錄結(jié)構(gòu)lib、pubspec.yaml 等同時會有 OpenHarmony 側(cè)的相關(guān)配置目錄。這塊和傳統(tǒng) Android/iOS 工程最大的區(qū)別是OpenHarmony 側(cè)的工程文件主要供 DevEco Studio 使用。有一個經(jīng)驗值得在這里說出來創(chuàng)建工程時最好把包名和 org 想清楚后邊改了很麻煩。OpenHarmony 的 HAP 包名和應(yīng)用標(biāo)識跟 Android 的 applicationId 還不是一回事一旦簽了字、生了成再改會涉及簽名配置和配置文件的聯(lián)動修改特別浪費時間。初始化完成后先在本地跑一次flutter build hap --debug具體命令取決于你使用的 Flutter SDK 版本和插件確認(rèn)工程能正常構(gòu)建再初始化 Git 提交。好的做法是“本地全綠才推遠(yuǎn)端”避免把無法構(gòu)建的半成品推到遠(yuǎn)端給協(xié)作者添亂。3.3 第一批提交應(yīng)該包含什么第一次提交建議把以下內(nèi)容納入版本管理工程主體代碼lib 目錄下的 Dart 代碼、ohos 目錄下的 OpenHarmony 工程配置pubspec.yaml這是 Flutter 項目的依賴清單必須提交README.md寫清楚項目的用途、環(huán)境要求、怎么構(gòu)建、怎么跑.gitignore排除構(gòu)建產(chǎn)物build 目錄、.hvigor 緩存目錄、.idea 目錄等.gitignore這塊容易踩坑標(biāo)準(zhǔn) Dart/Flutter 的 gitignore 模板有時候不覆蓋 OpenHarmony 構(gòu)建產(chǎn)生的目錄。我實際使用后發(fā)現(xiàn)至少需要額外加上這些# OpenHarmony build outputs **/ohos/.hvigor/ **/ohos/build/ **/ohos/.cxx/ **/ohos/.clangd/ **/ohos/oh_modules/如果不排除掉這些目錄build 一次之后 Git 狀態(tài)會攪成一團(tuán)倉庫大小也失真。這塊在 Flutter 官方模板里是沒有的屬于 OpenHarmony 適配工程的實際經(jīng)驗自行補充即可。再有一點pubspec.lock要不要提交對于 Flutter 應(yīng)用項目答案是提交。應(yīng)用項目需要鎖定依賴版本保證構(gòu)建可復(fù)現(xiàn)只有庫項目通常不提交pubspec.lock因為要允許下游靈活解析依賴版本。這個規(guī)則很多剛開始用 Flutter 的同學(xué)容易搞混。4. 本地 Git 初始化與首次推送實操4.1 完整的 Git 配置過程假設(shè)中央倉庫已經(jīng)建好本地工程也已經(jīng)創(chuàng)建完畢接下來把兩者連接起來。我在實際操作中按下面這個順序執(zhí)行以倉庫地址示例為準(zhǔn)實際操作時替換為你自己的地址cd flutter_oh_demo git init git add . git commit -m chore: initial commit for Flutter OpenHarmony demo git remote add origin https://atomgit.com/yourname/flutter_oh_demo.git git fetch origin git merge origin/master --allow-unrelated-histories --no-edit git push -u origin master這個順序里fetch和merge兩步的前提是你在創(chuàng)建倉庫時勾選了“初始化 README”。如果你的倉庫是空倉庫沒有做任何初始化那可以直接git push -u origin master不需要合并操作。說一下為什么我額外走了fetch merge而不是直接push --forceforce push 會把遠(yuǎn)端初始化的 README 覆蓋掉雖然第二次 push 體驗更順滑但這種習(xí)慣不好——如果當(dāng)時遠(yuǎn)端已經(jīng)有協(xié)作者的提交一個--force就能把別人的代碼全沖掉。寧可多敲兩行命令也別養(yǎng)成強推的習(xí)慣。4.2 Push 后立刻要做的三件事首次推送成功后我建議不要急著去寫功能代碼先把倉庫打磨好第一件完善 README。很多人的 README 就一行標(biāo)題其實這是很虧的。一個合格的 README 至少要寫清楚這個項目是干什么的一句話說清楚核心價值環(huán)境依賴Flutter SDK 版本、OpenHarmony 版本、DevEco Studio 版本如何構(gòu)建和運行命令行 IDE 兩種方式項目結(jié)構(gòu)說明簡單列一下目錄含義已知問題或 Roadmap第二件設(shè)置分支保護(hù)。在 AtomGit 的倉庫設(shè)置 → 分支設(shè)置里把 master 設(shè)成保護(hù)分支要求合并請求merge request必須經(jīng)過審核才能合入。即使是個人項目這一步也能幫你養(yǎng)成規(guī)范習(xí)慣后面多人協(xié)作時直接受益。具體設(shè)置項看平臺版本一般有“允許合并方式和保護(hù)分支”的選項。第三件建立項目和標(biāo)簽體系。創(chuàng)建好里程碑給計劃中的功能建好 Issue把接下來要做的 Demo 任務(wù)全部可視化。這一天的計劃我是這么拆的Issue 1完成 Flutter OpenHarmony 工程構(gòu)建驗證Issue 2實現(xiàn) Dart 調(diào)用 OpenHarmony 系統(tǒng)能力獲取設(shè)備信息Issue 3實現(xiàn) OpenHarmony 側(cè)通過事件通道向 Flutter 側(cè)傳遞數(shù)據(jù)Issue 4整理項目 README 與開發(fā)文檔每個 Issue 關(guān)聯(lián)到一個里程碑“DAY 2 ~ DAY 5基礎(chǔ)開發(fā)能力”這樣整體節(jié)奏很清楚。4.3 開發(fā)分支策略的初步選擇“分支策略”聽起來很高級其實說白了就是確定幾件事長期存在的分支有哪些、新功能從哪個分支出、合并到哪個分支、出問題怎么回滾。DAY 2 階段的項目規(guī)模很小不需要上 Git Flow 那種重量級流程用最簡單的主干開發(fā) 短分支模式就夠了master主分支保持可發(fā)布狀態(tài)受保護(hù)feature/*功能分支比如feature/basic-ui、feature/device-infofix/*修復(fù)分支比如fix/build-hvigor-cache操作上一般流程是這樣git checkout master git pull origin master git checkout -b feature/device-info # ... 開發(fā)、提交 ... git push -u origin feature/device-info然后在 AtomGit 網(wǎng)頁端發(fā)起 Merge RequestMerge 到 master。整個過程工具鏈比較自然不需要額外裝插件。5. 使用 WebIDE 與平臺集成功能提高效率5.1 WebIDE瀏覽和快速修改的利器AtomGit 提供了基于 Web 的 IDE在倉庫頁面就可以直接打開。這個功能特別適合以下場景你只是想快速瀏覽代碼不想把整個倉庫 clone 到本地你出差在外手頭沒有開發(fā)環(huán)境但想臨時改一行注釋或文檔Code Review 時覺得某個文件有問題直接在線改完再提交我在 DAY 2 測試 WebIDE 時發(fā)現(xiàn)它支持語法高亮、文件樹、Git 面板提交、推送、分支切換前端體驗已經(jīng)比較接近桌面編輯器了。對于 Dart 代碼還有基本的語法提示。不過說實話WebIDE 對于大型 Flutter 工程還是不適合做完整開發(fā)——因為無法在本機跑模擬器、無法調(diào)試。5.2 Release 管理與下載中心實戰(zhàn)提交代碼之后可以把當(dāng)前版本打一個 tag 發(fā)一個 Release。AtomGit 會生成下載鏈接這樣團(tuán)隊成員不需要 clone 整個倉庫也能在頁面上下載對應(yīng)版本的源碼 zip 包。Release 也有助于回溯問題。比如某一天代碼改崩了你只看 Git log 很難定位到底是哪個版本開始出問題但如果有 Release 體系每個版本對應(yīng)一份歸檔配合提交記錄就可以快速 diff 出問題所在。這個習(xí)慣建議從 Day 1 就開始養(yǎng)成不要等出了問題才想起打標(biāo)簽。5.3 Issues Pull Request 聯(lián)動的日常復(fù)盤DAY 2 比較有收獲的一個環(huán)節(jié)是把 AtomGit 的 Issue 和 MR 跑通了一條閉環(huán)流程。以“實現(xiàn)設(shè)備信息獲取”為例在 Issues 里新建 Issue寫清楚需求背景和驗收標(biāo)準(zhǔn)本地新建feature/device-info分支開發(fā)調(diào)試提交代碼并推送遠(yuǎn)端在 AtomGit 上創(chuàng)建 Merge Request并在描述里關(guān)聯(lián)對應(yīng) Issue合并后平臺上自動將 Issue 標(biāo)記為已完成這套機制最大的價值是“上下文持續(xù)存在”。兩周后回來看這個 MR能清楚知道當(dāng)時為什么要這么寫、解決了什么問題、和哪個 Issue 相關(guān)。對 OpenHarmony 這種還在快速演進(jìn)的技術(shù)棧來說回溯能力尤其重要——有些問題現(xiàn)在能跑但升級 SDK 后可能就崩了那時候翻歷史記錄就知道該從哪里查起。6. 團(tuán)隊協(xié)作流程和權(quán)限管理的進(jìn)階配置6.1 添加成員與團(tuán)隊分組如果你不是單機開發(fā)趁項目還小就把團(tuán)隊結(jié)構(gòu)建好。在 AtomGit 上有兩種組織方式個人倉庫直接邀請成員或者是創(chuàng)建組織再統(tǒng)一管理倉庫。實際建議只要超過兩個人就建組織Group。組織的好處是可以按項目分組管理倉庫成員權(quán)限統(tǒng)一管控比如Owner完全權(quán)限管理成員、倉庫設(shè)置、計費信息Admin管理項目配置但不能改組織設(shè)置Developer常規(guī)開發(fā)權(quán)限推分支、提 MRReporter只讀權(quán)限瀏覽、下載代碼按這個模型學(xué)習(xí)階段你是 Owner如果導(dǎo)師或同學(xué)要參與給 Developer 權(quán)限就夠了不用把倉庫鑰匙全交出去。6.2 分支保護(hù)規(guī)則和數(shù)據(jù)安全分支保護(hù)不是擺設(shè)尤其在共享倉庫中。我建議至少對 master 分支開啟以下規(guī)則禁止直接 Push必須走 MR 合并合并前要求流水線通過如果有 CI合并前要求至少一名成員評審有一個常被忽略的點保護(hù)分支也要考慮 MR 合入后的推送方式。AtomGit 支持“合并但不刪除源分支”和“合并后自動刪除源分支”。我建議勾選自動刪除后將不再保留習(xí)慣養(yǎng)成后遠(yuǎn)端分支列表始終干干凈凈。再補充一個安全建議嵌入在代碼里的敏感信息API Key、簽名密碼、內(nèi)網(wǎng)地址不要以明文形式提交到倉庫。一旦提交到歷史里即便后面刪除文件Git 歷史里仍然可以翻到。如果已經(jīng)失誤提交除了清理歷史還要考慮輪換相關(guān)密鑰。AtomGit 的網(wǎng)頁端設(shè)置有倉庫 Secrets 之類功能的話盡量用平臺提供的變量管理方式保存敏感值不要寫在代碼里。6.3 倉庫規(guī)范文檔化把約定變成準(zhǔn)繩團(tuán)隊協(xié)作時除了代碼本身還需要一套約定的文檔把這個節(jié)奏穩(wěn)定下來。我在 AtomGit 的項目 Wiki 里記錄了以下內(nèi)容Git 分支命名規(guī)范feature/功能名、fix/問題名、docs/文檔名Commit Message 格式采用 Conventional Commits 風(fēng)格比如feat: add device info channel、fix: resolve build error on OpenHarmony合并請求模板要求描述變更目的、測試方式、影響范圍代碼風(fēng)格規(guī)范比如 Dart 統(tǒng)一使用 flutter_lints 默認(rèn)規(guī)則這些“軟”的東西早期建立比團(tuán)隊變大以后再推行要容易得多。等習(xí)慣了這套流程去參與開源項目也會無縫銜接——因為主流社區(qū)都是同一套玩法。7. 實際體驗中的問題排查與心得7.1 首次合并歷史沖突的處理第一次 push 就碰到遠(yuǎn)端 README 與本地提交歷史不關(guān)聯(lián)的問題。由于 AtomGit 初始化時生成了 README產(chǎn)生了一次提交本地 git init 后的倉庫則是另一套毫無關(guān)聯(lián)的提交歷史直接git push會被拒。具體的處理命令前面已經(jīng)寫過了git fetch origin git merge origin/master --allow-unrelated-histories --no-edit git push -u origin master--allow-unrelated-histories這個參數(shù)允許合并兩個沒有共同祖先的提交歷史。如果項目一直在同一倉庫演進(jìn)一般用不到但首次接入遠(yuǎn)端時很常見。7.2 誤提交構(gòu)建產(chǎn)物到倉庫在把 OpenHarmony 構(gòu)建產(chǎn)物ohos/build、.hvigor誤提交之后的處理辦法是先修改.gitignore然后從 Git 索引中移除這些文件git rm -r --cached ohos/build ohos/.hvigor git add . git commit -m chore: remove build outputs from version control git push origin master從緩存移除后再提交遠(yuǎn)端倉庫就會徹底刪掉這些文件。該命令影響面廣操作前先git status確認(rèn)一下文件列表不要出現(xiàn)把源碼目錄當(dāng)構(gòu)建產(chǎn)物刪除的誤操作。7.3 克隆遠(yuǎn)程倉庫速度慢時的對策有些 OpenHarmony 相關(guān)依賴倉庫體量不小克隆慢可能不只是網(wǎng)絡(luò)問題?？梢赃@樣組合應(yīng)對只克隆需要的分支git clone -b master --single-branch repo-url使用--depth 1做淺克隆只拉最新一次提交需要完整歷史時再--unshallow如果倉庫內(nèi)包含子模塊記得git submodule update --init --recursive但在 AtomGit 上操作起來整體速度是要好于 GitHub 的至少我測下來這一天的 pull/push 都非?？臁Ｈ绻惆l(fā)現(xiàn)某個 repo 特別慢先看是不是倉庫本身塞了大量二進(jìn)制資產(chǎn)。7.4 協(xié)作時不規(guī)范提交記錄的處理團(tuán)隊協(xié)作一段時間后commit 記錄會變得五花八門。有的信息是 “fix”有的是 “update”根本看不出來干了什么。要規(guī)范化辦法是讓 MR 合入時使用 squash 合并把功能分支上的所有提交壓縮成一個提交再合入 master。這樣主干歷史非常干凈每個功能只有一個 commit。命令行的變基操作也很有用。在本地分支上把零零碎碎的提交整合好再推送git rebase -i HEAD~5或者只是修改最近一次 commit 信息git commit --amend不過 amend 和 rebase 都是在改動歷史如果分支已經(jīng)被別人拉取過不要隨便改寫否則會讓協(xié)作者一頭霧水。這條經(jīng)驗不只是 AtomGit 通用是所有 Git 協(xié)作的通用準(zhǔn)則。7.5 我的幾條實際操作心得第一項目初期就要寫好 README 和規(guī)范文檔。不要等代碼寫完了再補。早期的文檔幫我們理清思路也方便后來加入的伙伴快速理解項目。第二推送代碼前先在本地跑一次 build。Flutter 工程編譯問題如果不提前發(fā)現(xiàn)推到 CI 上只會浪費更多時間。OpenHarmony 的構(gòu)建比較吃資源我一般先跑 debug 編譯快速驗證再跑 release。第三每次 MR 關(guān)聯(lián) Issue。這個習(xí)慣后來幫我省了很多事。有一次開發(fā)中遇到 OpenHarmony 上 Flutter 頁面偶現(xiàn)黑屏我直接通過關(guān)聯(lián)的 Issue 追溯到前一天的代碼改動半小時就鎖定了疑似問題這種事在正式團(tuán)隊里可以讓你少加很多班。第四多看平臺更新。AtomGit 本身功能迭代也很快偶爾逛一下官方文檔和更新日志會發(fā)現(xiàn)一些新特性可以提升效率。8. 后續(xù)學(xué)習(xí)中繼續(xù)深入的方向DAY 2 的核心已經(jīng)完成項目上了 AtomGit 平臺本地和遠(yuǎn)端工作流打通基礎(chǔ)的項目管理規(guī)范也開始運轉(zhuǎn)起來了。后續(xù)還有幾個比較明確的方向會在此基礎(chǔ)上繼續(xù)展開接入自動構(gòu)建流水線利用平臺 CI 能力在每次推送后自動跑 Flutter analyze 和 build并在 MR 頁面直接看到檢查結(jié)果。這塊等 DAY 3 或 DAY 4 可以重點突破。單元測試與自動化測試的接入Flutter 側(cè)的 unit test 和 widget test 相對成熟可以放進(jìn) CI 中為每次 MR 提供質(zhì)量門檻。版本發(fā)布流程的固化結(jié)合 Release 功能把構(gòu)建產(chǎn)物HAP 包和版本說明一并歸檔。多端工程結(jié)構(gòu)的梳理Flutter for OpenHarmony 的工程里既有 Dart 代碼又有 OpenHarmony 代碼兩者如何組織、目錄如何隔離也需要在后續(xù)實踐里持續(xù)打磨。最后分享一個 DAY 2 我特別深的感覺工具本身不會讓項目變好但好的工具流會讓每一次代碼變更都變得可追溯、可討論、可回滾。OpenHarmony 生態(tài)還在快速演進(jìn)把項目放在一個穩(wěn)定可控的管理平臺上等于給學(xué)習(xí)過程加了一份保險——哪怕是深夜把代碼改崩了也知道身后還有一份完整的歷史記錄等著你撈自己一把。