2022年，繼續(xù)做開源的朋友

利用開源軟件，和利用并

回饋開源社區(qū)，檔次和境界是不一樣的。哈佛商學(xué)院教授 Frank Nagle 的一項新研究發(fā)現(xiàn)， 回饋開源軟件能給自家

企業(yè)帶來更多的競爭優(yōu)勢。通過貢獻(xiàn)代碼，程序員能更深入的理解系統(tǒng)結(jié)構(gòu)和功能，這能帶來巨大的競爭優(yōu)

勢，還有助于改善公司形象，有利于招募優(yōu)秀人才，能增加公司研發(fā)效率。當(dāng)然回饋開源軟件對低技術(shù)公司意義不大。

本文就說說參與社區(qū)貢獻(xiàn)的幾點注意事項。大家，2022年就可以多參與社區(qū)的貢獻(xiàn)，我們一起做開源的朋友！

1、 熟悉已有的詳細(xì)資料

OpenHarmony Docs文檔倉、Gitee幫助站點都提供了豐富的資料，介紹如何把開源代碼倉Fork到本人的倉庫下，如何提交Pull Request來貢獻(xiàn)代碼。可以通過下述鏈接了解更多信息：

OpenHarmony貢獻(xiàn)流程

Gitee Fork + PullRequest 模式

2、Fork個人倉里創(chuàng)建分支

把開源倉代碼fork到個人倉后，就可以把代碼下載到本地工作機器上進(jìn)行開發(fā)了。通常建議，創(chuàng)建不同的分支來解決不同的issue或特性開發(fā)。如果沒有創(chuàng)建分支，直接在master分支上進(jìn)行開發(fā)，并提交Pull Request后，由于Committer代碼審核者需要時間來審核代碼，在這個期間，我們是無法提交PR代碼解決其他問題的。如果有不同的分支，則可以使用不同的分支來提交PR同時解決不同的問題。界面上創(chuàng)建分支如下圖所示：

現(xiàn)在Gitee已經(jīng)支持了可以多次fork代碼倉到本人倉，如下圖所示。但是使用不同的分支，依舊是效率更優(yōu)的工作方式。

3、更新Fork個人倉代碼

當(dāng)其他開發(fā)者提交的PR被Committer合入后，我們之前Fork到本人倉的代碼就與最新代碼不同步了。可以界面上操作，如下圖所示。但是，如果存在未合入的PR，這種界面上刷新是不允許的。

另外，界面上的操作沒有辦法刷新創(chuàng)建的其他分支的代碼，可以使用git命令行來更新代碼。如下所示，⑴處的命令行查看遠(yuǎn)程分支，⑵處增加遠(yuǎn)程分支，然后可以執(zhí)行⑶來拉取遠(yuǎn)程分支代碼，遠(yuǎn)程master分支的代碼合并到本地當(dāng)前分支。其中-r選擇等于–rebase，屬于變基操作，可以自行搜索rebase查詢更多的信息。這些命令的輸出，如下圖所示。

⑴ git remote -v ⑵ git remote add remote_origin --mirror=fetch https://gitee.com/openharmony/kernel_liteos_m.git ⑶ git pull -r remote_origin master

4、學(xué)會解決沖突

我們提交PR的時候，代碼是最新的，隨著其他開發(fā)者提交的PR的合入，可能存在沖突，導(dǎo)致我們的PR存在沖突，如下圖所示。這一般是因為自己的本地做的提交和服務(wù)器上的提交有差異，并且這些差異中的文件改動，Git不能自動合并，那么就需要用戶手動進(jìn)行合并。

怎么來解決沖突？需要參考上面的小節(jié)來更新Fork個人倉代碼，由于存在沖突，更新會失敗，更新后解決沖突，重新提交即可。下面介紹下步驟。當(dāng)執(zhí)行⑴處變基rebase更新代碼因沖突失敗時，會提示哪些文件存在沖突。⑵處查看本地更改，然后根據(jù)本地代碼和最新代碼的沖突的實際情況，修復(fù)沖突。如⑶的例子，BUILD.gn文件存在沖突，編輯解決沖突。然后使用git add 添加到更改。解決完畢沖突后，執(zhí)行⑷繼續(xù)應(yīng)用補丁。最后重新推送代碼即可，注意需要使用-f表示強制推送。

git remote -v git remote add remote_origin --mirror=fetch https://gitee.com/openharmony/kernel_liteos_m.git ⑴ git pull -r remote_origin master ⑵ git status ⑶ vi testsuits/sample/kernel/mem/BUILD.gn git add testsuits/sample/kernel/mem/BUILD.gn ⑷ git rebase --continue ⑸ git push origin XXX:XXX -f

關(guān)于如何處理代碼沖突，也可以參考Gitee幫助站點如何處理代碼沖突了解更多信息。

5、追加amend提交

通常一個PR只能用于解決一個單一的問題，只需要提交一個git commit。如果需要解決多個問題，需要提交多個PR。經(jīng)常由于提交的代碼由于需要再次修改，導(dǎo)致一個PR包含多個git commit，如下圖所示。這樣不規(guī)范的提交會導(dǎo)致git log提交日志信息非常多，后續(xù)查看提交修改時，非常不方便。

解決這個問題的方式就是提交代碼時，使用amend追加方法。本地再次修改后，執(zhí)行⑴git commit提交時，注意需要添加–amend選項，此時會彈出窗口讓修改git message信息。⑵處提交追加的代碼，注意需要添加-f選項強制提交。

⑴ git commit --amend ⑵ git push origin XXX:XXX -f

關(guān)于如何追加提交，也可以參考Gitee幫助站點修改最后一次提交了解更多信息。

6、cherry-pick提交

當(dāng)合入一個PullRequest之后，有時我們想要把這個PullRequest上一個或者多個提交重新拿出來提交為一個新的PullRequest，然后合并到新的目標(biāo)分支。這時就可以使用Cherry Pick 功能。關(guān)于cherry-pick提交，可以參考Gitee幫助站點cherry-pick提交了解更多信息。

7、Git message規(guī)范

需要注意git message規(guī)范，可以參考Git Commit message 編寫指南。

小結(jié)

因為時間的關(guān)系，以后逐漸補充吧，有啥問題隨時留言給我。謝謝。

Git IoT 輕量級操作系統(tǒng) LiteOS

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。