簡體   English   中英

GitHub 貢獻頁面顯示太多更改

[英]GitHub contributions page shows too many changes

我一直在 Stack Overflow Jobs 上設置我的頁面,我注意到在我的一個存儲庫中,我有 3,521,316 個添加和 3,459,307 個刪除,這似乎不正確,所以我決定進行調查。 使用 GitHub 的貢獻頁面,我將更改本地化到1 月 26-27 日,那里說有 30 次提交,其中 3,507,040 次添加和 3,453,801 次刪除。 但是,當我單擊30 commits文本以查看提交時, 只有兩個,總共有 208 個添加和 152 個刪除。 我什至檢查了所有其他分支,看看他們在那個時間范圍內是否有其他提交,但沒有一個。

我想讓我的 SO Jobs 頁面的貢獻計數准確無誤,除了為了准確性而希望它們准確之外,但我不知道為什么它們如此嚴重不正確或如何糾正它們。 我在網上搜索了解決方案,但我發現的一切都是關於沒有出現的貢獻,而不是出現太多的貢獻。

在回顧提交歷史后,有一些大規模提交,我更改了許多巨大的 JSON 數據文件,因此 GitHub 方面似乎沒有錯誤(除了將所有這些更改歸因於一天貢獻者頁面)。 知道實際上有大量的行更改,我開始嘗試找出如何忽略這些文件,並遇到了這個問題,這使我找到了 GitHub 的語言學家項目自述文件的這一部分 經過一番鬼混,我發現通過將文件標記為.gitattributes文件中生成的文件,它們將被排除在差異之外,因此大概它們的行將被排除在總貢獻之外。 截至目前,我的總貢獻尚未得到更正,但語言學家頁面指出更新在優先級較低的隊列中運行,因此可能需要一些時間。

要忽略文件,請在.gitattributes文件中向它添加這些屬性之一。 .gitattributes文件使用與.gitignore文件相同的模式語法。 如果您需要追溯這樣做,您需要添加/修改.gitattributes文件,創建一個提交,然后變基以將其插入過去

*.txt linguist-generated
# `linguist-generated` marks a file as generated, so it won't count toward
# language statistics or commit additions/deletions.

README.txt -linguist-generated
# prepending an attribute with a `-` removes it from the file

/libs/somelibrary.js linguist-vendored
# `linguist-vendored` marks a file as an external file such as a library. This 
# file will still appear in commit diffs, but it won't contribute to the
# repository's language statistics

/docs/** linguist-documentation
# `linguist-documentation` marks a file as documentation. This has the same
# effect as `linguist-vendored`.

/configs/*.json linguist-detectable
/tools/merge_configs.py -linguist-detectable
# `linguist-detectable` marks a file to be counted in language statistics. 
# By default it is enabled for programming languages, so you can use it to 
# either include non-code files, or exclude code files.

我在 GitHub 存儲庫貢獻圖上遇到了同樣的問題,最后我發現了如何解決這個問題。 值得一提的是,語言學家沒有幫助我。

如果第一部分或第二部分出現問題,您可以在此處找到如何撤消rebase 並且請不要忘記保留您的存儲庫的備份。

更改提交的作者姓名

注意:這將重寫存儲庫提交歷史記錄,並且在錯誤提交之后推送的所有提交將在今天推送到{repo-url}/commits/{branch}可見(提交的原始日期不會更改)。

更詳細的源碼

  • 因此,首先,創建存儲庫的備份並保存在某處。

  • 現在你應該找到你的錯誤提交哈希

  • 然后找到該提交之前的提交(較早的提交)。 你可以用git log做到這一點。

  • 復制該提交哈希並執行以下操作:

     git rebase -i earlier_commit_here
  • 將出現文本編輯器。 找到您的錯誤提交並將其旁邊的“pick”一詞更改為“edit”(為此,請按鍵盤上的i按鈕,然后更改文本,按Esc並鍵入:wq以保存並退出)。

  • 現在,您應該將提交的作者更改為類似的內容,無需電子郵件():

     git commit --amend --author="nocontribute <>"
  • 要完成rebase鍵入以下內容:

     git rebase --continue
  • 強制推送歷史:

     git push --force
  • 等待貢獻者的圖表更新(最多 24 小時)。

在我的情況下,我弄亂了我的存儲庫,上面的步驟沒有幫助。 如果您的貢獻者的圖表仍然相同,您可以執行以下操作:

創建一個新的存儲庫並將所有提交移動到它

這些步驟的主要思想是從其他提交中cherry-pickpush錯誤的提交。 因此,如果您有不止一個錯誤提交,請記住這一點。 如果您將所有提交推到一起,它將用“nocontribute”作者計算您的錯誤提交 奇怪但真實。 花了很多時間來確定這一點。

前面的步驟也應該完成才能繼續。

注意:這不僅會重寫存儲庫提交歷史記錄,還會清除您的所有統計信息(因為您將創建一個新存儲庫)。 只有提交將保留。

將提交移動到另一個存儲庫的詳細源

  • 將您當前在 GitHub 上的名稱存儲庫更改為currentname-outdated

  • 創建一個名為currentname的新存儲庫並克隆它(不要忘記重命名您之前克隆的存儲庫名稱)。

  • cd到新克隆的存儲庫目錄並鍵入以下內容:

     git remote add oldrepo https://github.com/path/to/oldrepo
  • 然后更新它:

     git remote update
  • 現在cd到舊的(過時的)存儲庫並保存到提交日志的文件中:

     git log --pretty="format:cp %h" > commits.txt
  • 然后反轉此文件中的行(您可以使用命令行工具(值得一提的是, tail命令沒有按我的預期工作,它在一行中添加了兩次提交)或使用像這樣的在線工具)並將其保存到commits.sh文件。

  • 現在打開commits.sh文件並復制和剪切錯誤的提交以及它之后的所有提交並保存在其他地方。 因此,您將在commits.sh文件中的錯誤提交之前進行提交

  • cherry-pick創建一個新別名:

     alias cp='git cherry pick '
  • cd到您的新存儲庫並執行commits.sh

     sh ../currentname-outdated/commits.sh
  • 將更改推送到存儲庫:

     git push
  • 在此處查看您的貢獻者圖表: {repo-url}/graphs/contributors 檢查一切是否正常。

  • 然后接受你的錯誤提交,挑選它並推送:

     cp bad_commit git push
  • 再次檢查貢獻者的圖表。

  • 如果一切正常,打開剩余的提交,從那里刪除錯誤的提交,並用保存的提交替換commits.sh中的提交(除了錯誤的提交,因為你已經推送了它)。

  • 再次執行commits.sh

     sh ../currentname-outdated/commits.sh
  • 檢查你的圖表。

  • 現在繼續從舊存儲庫中移動其他項目(如問題、標簽、標簽等)。

希望它可以幫助某人。

我檢查了一下,看起來 GitHub 有問題。 我嘗試了一種解決方法並且它有效,請轉到您共享的 GitHub 鏈接(時間范圍為2019 年 1 月 26 日至 27 日之間),然后從右上角的貢獻下拉列表中選擇“ Additions選項,請參閱下面的屏幕截圖在此處輸入圖片說明 現在貢獻圖將重新渲染,現在再次單擊相同的下拉菜單並選擇選項Commits 現在單擊30 commits您現在將找到所有提交。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM