女仆色福利在线观看,中文字幕一级无码,极品乳神小雅在线视频

PR方法（Git操作） 01Fork

首先將官方倉庫 fork 到我們自己的賬號下，點擊一下 fork 按鈕，按照提示操作即可。

回到自己的倉庫中，將倉庫clone到本地。

git clone https://github.com/yourusername/rt-thread.git

如果是較早之前fork的倉庫，可以先和上游的倉庫同步一下：

1. 先在倉庫頁面Update branch

2. 在本地倉庫git fetch & git merge

02Commit & Push

一般來說，一個issue或者PR對應一個新的分支，所以需要創(chuàng)建一個分支

git checkout -b

更改相應的代碼，然后提交代碼

git add .

git commit -m "message"

git push origin test-branch

03Pull Request

在倉庫首頁按操作提起一個PR

04Rollback

如果提交有誤或者需要修改，可以進行回滾，然后重新push

git reset HEAD^（回退到上一個版本）

05CI

查看CI結果，根據(jù)結果對代碼進行修改

功能的修改和增加：以CI（issue 7458）為例 01理解issue

[CI][cppcheck] 需要根據(jù)ignore_format 過濾掉不需要掃描的文件夾 · Issue #7458 · RT-Thread/rt-thread (github.com)https://github.com/RT-Thread/rt-thread/issues/7458

對問題本身的理解十分重要，issue里可能會有其他人對這個需求的或者問題詳細討論和思路的提供，所以仔細查看issue非常重要。

根據(jù)這個issue的描述，主要是添加忽略一些文件和目錄進行靜態(tài)檢查的功能。

具體需求是：

1. 添加對.ignore_format.yml配置文件檢查

2. 如果新更新的文件在dir_path屬性的目錄下或者在file_path屬性中

3. 對這個文件就不啟用靜態(tài)檢查

并且這個issue中也提供了一種思路：

1. 遍歷一下ignore_format.yml文件找到所有需要忽略的文件夾，搞個大數(shù)組，然后過濾

2. 參考一下

https://github.com/RT-Thread/rt-thread/blob/master/tools/file_check.py

02代碼定位

代碼定位是對功能的修改和增加的第一步，對于Bug fix來說，代碼定位可能比較困難，但是對于功能的修改和增加來說，是比較簡單的。

首先可以看出來這個issue的工作主要是CI這塊，那么我們需要先了解github的CI工具：Github Action。最好的文檔肯定就是GitHub Actions文檔 - GitHub 文檔。我們不需要全部了解之后再動手，只要了解一些基本概念之后就可以先動手。

根據(jù)文檔的描述，我們可以了解到github workflow使用yml來描述，并且放在了.github/workflow目錄下，所以第一步可以定位到.github/workflow下的static_code_analysis.yml。

在這個目錄我們可以看到static_code_analysis.yml是直接在yaml中用shell編寫工作流程，而還有其它文件如file_check.yml使用調(diào)用其它Python腳本來完成工作流程。所以基本可以確定我們需要修改或者增加的地方就在.github/workflow和tools/ci下。

03代碼閱讀

在這里，我們參考file_check.yml的實現(xiàn)。所以需要先理解file_check.yml的整體實現(xiàn)。

file_check.yml主要先使用shell按照了Pyhon腳本中必須使用的庫然后直接調(diào)用Python腳本，我們直接跳入這個被調(diào)用的腳本查看。

代碼閱讀個人比較喜歡也覺得比較快速的方式是：先了解代碼的某一部分（需要控制精度）的大致結構和功能，不關注其具體實現(xiàn)，之后再深入理解具體實現(xiàn)。在這個過程中有需要去猜測別人是如何寫的代碼，并且在一步步閱讀代碼的過程當中驗證和糾正自己的想法。

我們來看file_check.py。

我們可以先忽略使用的click命令行庫，或者也可以從命名和使用方式猜測出它們的功能。

因為這個文件比較簡單，所以我們可以猜測函數(shù)的入口就是check()。主函數(shù)里的邏輯是十分簡單的，可以看到通過checkout.get_new_file()獲得了一個文件列表，然后傳遞給了FormatCheck和LicenseCheck，它們又分別調(diào)用了自身的check函數(shù)，最后根據(jù)它們返回值判斷是否檢查出錯誤。

所以我們可以猜測checkout.get_new_file()獲得的文件列表是需要檢查的文件列表，而FormatCheck和LicenseCheck執(zhí)行各自的檢查邏輯，我們可以不用關注。

而get_new_file的就需要深入代碼看具體實現(xiàn)，具體的邏輯也比較簡單。

1. 通過git命令獲得新增和修改的文件列表

2. 然后遍歷這個文件列表

3. 遍歷這個文件列表中的文件路徑的每一層目錄，看是否存在.ignore_format.yml文件

4. 然后根據(jù).ignore_format.yml的屬性來判斷當前文件是否需要被檢查

所以我們實現(xiàn)的重點就是對需要檢查的代碼進行靜態(tài)代碼檢查。

04功能增加

首先，因為獲得需要檢查的文件列表這個功能是可能會被多次利用，可以先提取出來作為一個獨立功能，并且可以做一些優(yōu)化（在獲得新增和修改的文件列表時的寫法可以優(yōu)化）。

其次，最重要的就是利用cppcheck完成靜態(tài)代碼檢查的功能：

1. 從文件列表中再一次過濾出C/C++相關文件

2. 然后使用cppcheck逐個檢查文件列表，并且捕獲標準錯誤流

 1classCPPCheck:
 2def__init__(self,file_list):
 3self.file_list=file_list
 4defcheck(self):
 5file_list_filtered=[fileforfileinself.file_listiffile.endswith(('.c','.cpp','.cc','.cxx'))]
 6logging.info("Starttostaticcodeanalysis.")
 7check_result=True
 8forfileinfile_list_filtered:
 9result=subprocess.run(['cppcheck','--enable=warning','performance','portability','--inline-suppr','--error-exitcode=1','--force',file],stdout=subprocess.PIPE,stderr=subprocess.PIPE)
10logging.info(result.stdout.decode())
11logging.info(result.stderr.decode())
12ifresult.stderr:
13check_result=False
14returncheck_result
15@click.group()
16@click.pass_context
17defcli(ctx):
18pass
19@cli.command()
20defcheck():
21"""
22staticcodeanalysis(cppcheck).
23"""
24format_ignore.init_logger()
25#getmodifiedfileslist
26checkout=format_ignore.CheckOut()
27file_list=checkout.get_new_file()
28iffile_listisNone:
29logging.error("checkoutfilesfail")
30sys.exit(1)
31#usecppcheck
32cpp_check=CPPCheck(file_list)
33cpp_check_result=cpp_check.check()
34ifnotcpp_check_result:
35logging.error("staticcodeanalysis(cppcheck)fail.")
36sys.exit(1)
37logging.info("checksuccess.")
38sys.exit(0)
39if__name__=='__main__':
40cli()

05功能測試

完成代碼的修改之后最重要的就是通過測試，最基本也是最簡單的測試就是功能測試。所以我們可以給這次的修改安排三個測試：

修改cppcheck會出現(xiàn)錯誤的文件：

case 1：不將文件加入.ignore_format.yml，CI報錯

case 2：將文件加入.ignore_format.yml的file_path，CI不報錯

case 3：將文件加入.ignore_format.yml的dir_path，CI不報錯

PR心得

這次PR的提交有以下兩個小心得。

01仔細溝通

第一點，也是最重要的一點就是和主動社區(qū)的前輩進行交流，對issue的問題和需求進行討論。在這個PR被merge之前我就完成了其余兩版，但是因為缺乏溝通，不是很適合當前的RT-Thread。

02Github Action 本地測試

在修改CI部分時，每次都需要推送到遠端才能執(zhí)行相關的action，這樣比較麻煩?？梢允褂?span style="color:rgb(0,112,192);">nektos/act: Run your GitHub Actions locally 工具在本地跑Github action。