軟體工程師初學者使用Git的不良實踐

聞數起舞 發佈 2020-06-06T07:40:07+00:00

如果一個項目只有一個工程師,那麼他/她為什麼要避免使用原始碼控制,尤其是在他們以前沒有使用原始碼控制的情況下,這是可以理解的。

讓我們討論一下軟體工程領域的初學者和學生最常見的錯誤和不良做法。

眾所周知,Git是一種高效的分布式VCS(版本控制軟體)工具,可以處理任何規模的軟體項目。 它的主要優點在於使多個開發人員或團隊可以獨立工作,而不會干擾其他人的工作。

現在,出現的一個問題是,在大學期間,您將從事單個項目,因此您無需使用原始碼控制系統,因為不涉及任何協作。 如果一個項目只有一個工程師,那麼他/她為什麼要避免使用原始碼控制,尤其是在他們以前沒有使用原始碼控制的情況下,這是可以理解的。 但是,一旦找到工作,就無法避免了。 根據我自己的經驗,許多畢業生一旦被錄用就擁有了Git的第一次經驗,因為他們現在確實需要與多個工程師一起從事多個項目。

在閱讀了Sukru Eraslan等人的"使用Git¹的軟體工程學生的錯誤和不良實踐"之後,我認識到這些錯誤在軟體工程領域的初學者中也很常見。 在本文中,我將討論一些論文的結果,這些結果可以輕鬆地映射到與初學者軟體工程師及其使用Git有關的行業情況。

應用Git工作流程

什麼是Git工作流程? Git工作流程是一種"食譜",描述了如何使用Git來提高工作效率。 有關更多詳細信息,您可以在此處閱讀有關Git工作流程成功的原因。

在前面提到的文章中,與Git工作流程有關的最常見錯誤如下:

· 即使他們創建了功能分支,學生也將所做的更改提交到開發分支而不是功能分支。

· 學生將他們的某些更改提交給所需的功能分支,並將其他更改提交給其他分支。

· 學生需要在其功能分支之一上工作,但他們忘記簽出所需的分支來確保他們在適當的版本中工作。

創建提交

就創建提交而言,許多學生似乎使用不提供信息的消息來提交他們的更改,而沒有遵循GitHub標準。 此外,他們應用了大型提交而不是小型/常規提交,並在提交中添加了不必要的文件,這可能導致分支難以理解。

我也經歷過的另一個糟糕的做法是注釋掉代碼的某些部分,而不是擺脫它們並提交這些更改,即使我們知道Git完全是為了保留代碼的先前版本。

Push Commit

推動提交是學生努力進行的基本操作之一。 他們中的許多人提交了未編譯或未通過測試的代碼。 此外,他們絕望地使用了強制推送,因為他們無法解決如何將其工作合併到團隊資料庫中的問題,這導致其他學生推送的內容丟失。 而且,學生完全不知道他們可以在一次操作中將多個提交推送到其存儲庫中。

合併 Merge

合併是理解Git的最困難的部分之一。 即使是經驗豐富的Git用戶,您也可能會遇到合併衝突,並且解決衝突的過程並不總是很順利。 根據他們的研究,新手似乎有從錯誤分支合併到錯誤分支的趨勢。 此外,當要求他們使用需要的合併工作流時,它們會重新提交以集成代碼(反之亦然)。

Pull

正如預期的那樣,學生沒有進行定期提取Pull,最終他們進行了大量整合自己的更改的提交,從而導致發生衝突的可能性更高和/或進行不必要或不正確的合併。

分支/標記

第一次嘗試學習Git時,分支是另一個令人困惑的部分。 從創建錯誤提交的標籤到不遵循分支/標籤命名約定,我們都熟悉這些問題。 該論文的一些更有趣的結果如下:

· 學生創建一個本地分支機構,稱為"起源/母版"。 該分支有時會推送到遠程,因此遠程跟蹤分支稱為"源/源/主"。

· 學生創建一個名為" HEAD"的分支,該分支是顯示活動工作行的最後一次提交的指針的名稱。 該分支機構有時是本地分支機構,但已被推到偏遠地區,使整個團隊感到困惑。

· 當情況不需要時,學生在新分支上創建一個孤兒提交。

結論

總而言之,我鼓勵您閱讀全文,以了解實現這些結果的環境。 我認為,這些結果在當前的軟體工程行業中是完全有效的,並且許多初學者可能會遇到相同的Git問題。

希望您喜歡閱讀本文並祝您愉快

參考文獻

[1]:Sukru Eraslan等人(2020年1月)。 軟體工程專業學生使用Git的錯誤和不良實踐:https://dl.acm.org/doi/pdf/10.1145/3372356.3372364。

(本文翻譯自Rachel Zane的文章《Poor Practices of Future Software Engineers in Using Git》,參考:https://medium.com/swlh/poor-practices-of-future-software-engineers-in-using-git-e42d37a12b72)

關鍵字: