我正在研究在一周或兩周內可以有一百多個提交的功能分支。一旦我的拉取請求被接受，我希望在這些每日提交的貢獻圖中獲得每日標記，但是當該拉取請求被“壓縮并合并”時，它看起來就像在貢獻圖中顯示為單個提交.
這是預期的行為，還是我的提交因其他原因而丟失？
uj5u.com熱心網友回復：
是的，它們顯示為單個提交。那是因為 GitHub 只計算最終在默認分支上的提交，并且當您壓縮 PR 時，您最終會在默認分支上進行一次提交。
我個人并不擔心我的貢獻圖，所以這對我來說并不重要。但是，我也不使用壓縮和合并，因為我用良好的提交訊息撰寫了漂亮的、可平分的提交，而壓縮和合并會破壞它。如果不將貢獻者所做的作業減少到單個提交對您來說很重要，那么您將需要一個合并策略，其目標不是明確地破壞歷史記錄。
uj5u.com熱心網友回復：
是的，這是預期的行為。你只合并了一個提交。這就是擠壓和合并的重點。
我不推薦壁球合并。它需要仔細考慮所有關于分支如何開發的提交歷史，并將其搗碎成一個方便但同質的糊狀物。
我正在研究在一周或兩周內可以有一百多個提交的功能分支。
我會說這是真正的問題。功能分支不應該經常有超過一百次提交。你的特性太大了，或者你做了很多提交來修復以前的提交，或者你有很多來自更新分支的偶然合并提交，或者以上所有。
使用rebase而不是更新您的分支merge。git rebase main重寫你的分支，就好像它一直寫在最新版本的 main 之上。這會洗掉除了“我更新了我的分支”之外什么都不說的合并提交，并且可以更輕松地查看分支上已完成的作業。您可以更改git pull為執行變基而不是合并，git pull --rebase默認情況下通過設定pull.rebase. 請參閱git-config和Git 分支 - 變基。
將大特征分解為一系列較小的特征。這是一項超出本答案范圍的技能，但通常一個大的變化可以分解為一系列較小的重構。
消除偶然的修復提交。如果您需要修復上一次提交中的某些內容，請不要使用git commit --amend.
對于一般清理，請執行互動式 rebase 并單獨壓縮您的偶然提交。使用fixup.
$ git rebase -i master
pick abcd1234 feature: do that thing
fixup 1234dcba whoops, had a typo in that thing
fixup b33fdead docs: document that thing
fixup afdcefff test: test that thing
fixup deadb33f fix that thing
pick efga1389 feature: did another thing
你有六次提交，但你只真正做了兩件事。現在，您將只有兩次提交才能做兩件事。
使用這些技術，您可以將 PR 簡化為一些經過深思熟慮的提交，每個提交都向審閱者和未來的開發人員傳達重要資訊，他們想知道為什么要這樣撰寫代碼。
有關更多資訊，請參閱重寫歷史記錄。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/330374.html
標籤：github
上一篇：??Android 12 高斯模糊-RenderEffect??
下一篇：在WPFMVVM中打開主視窗