หลังจากgit reset --hard, git statusให้ฉันไฟล์ภายในChanges not staged for commit:ส่วน

ฉันเคยลองgit reset .แล้วgit checkout -- .และgit checkout-index -f -aก็ไม่มีประโยชน์

ดังนั้นฉันจะกำจัดการเปลี่ยนแปลงที่ไม่มีสถานะเหล่านั้นได้อย่างไร

ดูเหมือนว่าจะตีไฟล์โครงการ Visual Studio เท่านั้น แปลก. ดูวางนี้: http://pastebin.com/eFZwPn9Z มีอะไรพิเศษกับไฟล์เหล่านั้นคือใน. gitattributes ฉันมี:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

นอกจากนี้ยังมีการตั้งค่าที่ผิดพลาดในระดับโลกของฉันautocrlf .gitconfigนั่นอาจจะเกี่ยวข้องอย่างใด?

ฉันมีปัญหาเดียวกันและมันก็เกี่ยวข้องกับ.gitattributesไฟล์ อย่างไรก็ตามประเภทไฟล์ที่ก่อให้เกิดปัญหาไม่ได้ระบุไว้ใน.gitattributesแต่ประเภทของไฟล์ที่ก่อให้เกิดปัญหาที่ไม่ได้ระบุไว้ใน

ฉันสามารถแก้ไขปัญหาได้ด้วยการเรียกใช้

git rm .gitattributes
git add -A
git reset --hard

มติ !!!

ฉันได้แก้ไขปัญหานี้โดยใช้ขั้นตอนต่อไปนี้

1) ลบทุกไฟล์ออกจากดัชนีของ Git

git rm --cached -r .

2) เขียนดัชนี Git ใหม่เพื่อรับการขึ้นบรรทัดใหม่ทั้งหมด

git reset --hard

โซลูชันเป็นส่วนหนึ่งของขั้นตอนที่อธิบายไว้ในไซต์ git https://help.github.com/articles/dealing-with-line-endings/

Git จะไม่รีเซ็ตไฟล์ที่ไม่ได้อยู่ในที่เก็บ คุณสามารถ:

$ git add .
$ git reset --hard

ขั้นตอนนี้จะทำการเปลี่ยนแปลงทั้งหมดซึ่งจะทำให้ Git ตระหนักถึงไฟล์เหล่านั้นและทำการรีเซ็ต

หากวิธีนี้ใช้ไม่ได้ผลคุณสามารถลองซ่อนและวางการเปลี่ยนแปลงของคุณ:

$ git stash
$ git stash drop

หากคุณใช้ Git สำหรับ Windows นี่น่าจะเป็นปัญหาของคุณ

ฉันมีปัญหาเดียวกันและที่เก็บถาวรฮาร์ดรีเซ็ตสะอาดหรือแม้กระทั่งพวกเขาทั้งหมดยังคงทิ้งการเปลี่ยนแปลง สิ่งที่กลายเป็นปัญหาคือโหมดไฟล์ x ที่ไม่ได้ตั้งอย่างถูกต้องโดย git นี่คือ "ปัญหาที่ทราบ" กับ git สำหรับ windows การเปลี่ยนแปลงในเครื่องจะแสดงในสถานะ gitk และ git เป็นโหมดเก่า 100755 โหมดใหม่ 100644 โดยไม่มีความแตกต่างของไฟล์จริง

การแก้ไขคือการละเว้นโหมดไฟล์:

git config core.filemode false

ข้อมูลเพิ่มเติมที่นี่

โอเคฉันได้แก้ปัญหาแล้ว

ดูเหมือนว่า.gitattributesไฟล์ที่มี:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

ทำให้ไฟล์โครงการไม่ปรากฏขึ้น ฉันไร้เหตุผลทำไมจึงเป็นเช่นนั้นและฉันหวังว่าบางคนจะรู้วิธีที่จะทำให้เรามีคำอธิบายที่ดี

การแก้ไขของฉันคือการลบไฟล์เหล่านี้และเพื่อเพิ่มautocrlf = falseภายใต้[core]ใน.git/configใน

สิ่งนี้ไม่ได้มีค่าเท่ากับสิ่งเดียวกันกับการกำหนดค่าก่อนหน้านี้อย่างที่มันต้องการให้ทุก ๆ dev ต้องมี autocrlf = falseที่จะมี ฉันต้องการค้นหาวิธีแก้ไขที่ดีกว่า

แก้ไข:

ฉันแสดงความคิดเห็นเส้นที่ใส่ร้ายป้ายสีพวกเขาและมันทำงาน อะไรนะ ... ฉันไม่แม้แต่ ... !

สาเหตุที่เป็นไปได้ # 1 - การวางบรรทัดฐานการสิ้นสุดบรรทัด

สถานการณ์หนึ่งที่สิ่งนี้สามารถเกิดขึ้นได้คือเมื่อไฟล์ที่มีปัญหาถูกตรวจสอบลงในที่เก็บโดยไม่มีการกำหนดค่าที่ถูกต้องสำหรับการจบบรรทัด (1) ส่งผลให้ไฟล์ในที่เก็บมีการสิ้นสุดของบรรทัดที่ไม่ถูกต้อง หากต้องการยืนยันให้ตรวจสอบว่าgit diffแสดงเฉพาะการเปลี่ยนแปลงในตอนท้ายบรรทัด (อาจไม่สามารถมองเห็นได้ตามค่าเริ่มต้นให้ลองgit diff | cat -vดูการขึ้นบรรทัดใหม่ตามตัวอักษร)^Mอักษร)

ต่อจากนั้นอาจมีบางคนเพิ่ม.gitattributesหรือแก้ไขการcore.autocrlfตั้งค่าเพื่อทำให้บรรทัดสุดท้ายของบรรทัดสิ้นสุด (2) ตาม.gitattributesGit หรือการกำหนดค่าระดับโลก Git ได้นำการเปลี่ยนแปลงในท้องถิ่นไปใช้กับสำเนาการทำงานของคุณซึ่งใช้บรรทัดที่ลงท้ายด้วยการทำให้เป็นมาตรฐานที่ร้องขอ น่าเสียดายด้วยเหตุผลบางอย่างgit reset --hardไม่ได้ยกเลิกการเปลี่ยนแปลงบรรทัดมาตรฐานเหล่านี้

สารละลาย

วิธีแก้ปัญหาที่การตั้งค่าการจบสายภายในเครื่องจะไม่สามารถแก้ปัญหาได้ ทุกครั้งที่ไฟล์ถูก "เห็น" โดยคอมไพล์มันจะลองและนำมาตรฐานมาใช้ใหม่ซึ่งจะทำให้เกิดปัญหาเดียวกัน

ตัวเลือกที่ดีที่สุดคือให้ git ใช้การปรับมาตรฐานที่ต้องการโดยการทำให้บรรทัดที่ลงท้ายด้วย repo กลับมาเป็น.gitattributesปกติและจับการเปลี่ยนแปลงเหล่านั้น - ดูที่การพยายามแก้ไขจุดสิ้นสุดของบรรทัดด้วย git filter-branch แต่ไม่มีโชคแต่มีโชคไม่

หากคุณต้องการลองและย้อนกลับการเปลี่ยนแปลงของไฟล์ด้วยตนเองดูเหมือนว่าวิธีที่ง่ายที่สุดคือการลบไฟล์ที่แก้ไขแล้วบอก git ให้ทำการกู้คืนแม้ว่าฉันจะทราบว่าวิธีนี้ไม่ทำงานอย่างสม่ำเสมอ 100% ของ เวลา ( คำเตือน: อย่ารันสิ่งนี้หากไฟล์ที่ถูกดัดแปลงของคุณมีการเปลี่ยนแปลงอื่นนอกเหนือจากการสิ้นสุดบรรทัด !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

โปรดทราบว่าหากคุณไม่ทำให้บรรทัดที่สิ้นสุดในที่เก็บเป็นปกติในบางจุดคุณจะยังคงพบปัญหานี้ต่อไป

สาเหตุที่เป็นไปได้ # 2 - ไม่รู้สึกตัวพิมพ์เล็ก - ใหญ่

สาเหตุที่สองที่เป็นไปได้คือการคำนึงถึงขนาดตัวพิมพ์บน Windows หรือ Mac OS / X ตัวอย่างเช่นสมมติว่ามีพา ธ ดังต่อไปนี้อยู่ในที่เก็บ:

/foo/bar

ตอนนี้มีคนบน Linux ยอมรับไฟล์ลง/foo/Bar(อาจเป็นเพราะเครื่องมือสร้างหรือสิ่งที่สร้างไดเรกทอรีนั้น) และผลักดัน บน Linux ตอนนี้เป็นจริงสองไดเรกทอรีแยก:

/foo/bar/fileA
/foo/Bar/fileA

การตรวจสอบธุรกรรมซื้อคืนนี้ออกมาบน Windows หรือ Mac อาจส่งผลให้มีการปรับเปลี่ยนfileAที่ไม่สามารถตั้งค่าใหม่เพราะในแต่ละรีเซ็ตคอมไพล์ในการตรวจสอบของ Windows ออก/foo/bar/fileAแล้วเนื่องจาก Windows เป็นกรณีตายเขียนทับเนื้อหาของfileAด้วย/foo/Bar/fileAผลในการให้พวกเขาได้รับการ "ปรับเปลี่ยน"

อีกกรณีหนึ่งอาจเป็นไฟล์แต่ละไฟล์ที่มีอยู่ใน repo ซึ่งเมื่อเช็กเอาต์ในระบบไฟล์ที่ไม่ตรงตามตัวพิมพ์เล็กและใหญ่ก็จะทับซ้อนกัน ตัวอย่างเช่น:

/foo/bar/fileA
/foo/bar/filea

อาจมีสถานการณ์คล้ายกันอื่น ๆ ที่อาจทำให้เกิดปัญหาดังกล่าว

คอมไพล์ในกรณีที่ระบบไฟล์ insensitive จริง ๆ ควรตรวจสอบสถานการณ์นี้และแสดงข้อความเตือนที่เป็นประโยชน์ แต่ในปัจจุบันมันไม่ได้ (อาจมีการเปลี่ยนแปลงในอนาคต - ดูการสนทนานี้และแพทช์ที่นำเสนอที่เกี่ยวข้องในรายชื่อผู้รับจดหมาย git.git)

สารละลาย

การแก้ปัญหาคือการนำกรณีของไฟล์ในดัชนี git และกรณีในระบบไฟล์ Windows ในการจัดตำแหน่ง สิ่งนี้สามารถทำได้บน Linux ซึ่งจะแสดงสถานะที่แท้จริงของสิ่งต่าง ๆ หรือบน Windows ด้วยยูทิลิตี้โอเพนซอร์สที่มีประโยชน์มากGit-Unite Git-UniteGit-Unite จะนำการเปลี่ยนแปลงกรณีที่จำเป็นไปใช้กับดัชนี git ซึ่งสามารถส่งไปยัง repo ได้

(1) นี่เป็นไปได้มากที่สุดที่บางคนใช้ Windows โดยไม่มี.gitattributesคำจำกัดความใด ๆสำหรับไฟล์core.autocrlfที่เป็นfalseปัญหา

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

หากคำตอบอื่น ๆ ใช้งานไม่ได้ให้ลองเพิ่มไฟล์แล้วทำการรีเซ็ต

$ git add -A
$ git reset --hard

ในกรณีของฉันสิ่งนี้ช่วยได้เมื่อมีไฟล์ว่างมากมายที่คอมไพล์กำลังติดตาม

สาเหตุอื่นสำหรับสิ่งนี้อาจเป็นระบบไฟล์แบบไม่ตรงตามตัวพิมพ์ใหญ่ - เล็กเล็ก หากคุณมีหลายโฟลเดอร์ใน repo ของคุณในระดับเดียวกับที่ชื่อแตกต่างกันไปตามแต่ละกรณีคุณจะได้รับผลกระทบนี้ เรียกดูที่เก็บซอร์สโดยใช้เว็บอินเตอร์เฟส (เช่น GitHub หรือ VSTS) เพื่อให้แน่ใจ

สำหรับข้อมูลเพิ่มเติม: https://stackoverflow.com/a/2016426/67824

คุณสามารถstashเก็บการเปลี่ยนแปลงของคุณจากนั้นปล่อยที่เก็บ:

git stash
git stash drop

วิธีการเหล่านี้ไม่เหมาะกับฉันเลยทางออกเดียวคือให้กำจัด repo ทั้งหมดและโคลนซ้ำ ซึ่งรวมถึงการ stashing, รีเซ็ต, เพิ่มแล้วรีเซ็ต, การตั้งค่า clrf, ความไวของตัวพิมพ์เล็กและตัวน้อย

เรียกใช้คำสั่งclean :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

.gitattributesตรวจสอบของคุณ

ในกรณีของฉันฉันมี*.js text eol=lfอยู่ในนั้นและตัวเลือกคอมไพล์เป็นcore.autocrlftrue

มันนำฉันไปสู่สถานการณ์เมื่อคอมไพล์แปลงไฟล์ของฉันสิ้นสุดโดยอัตโนมัติและป้องกันไม่ให้ฉันแก้ไขได้และgit reset --hard HEADไม่ทำอะไรเลย

ฉันแก้ไขด้วยการแสดงความคิดเห็น*.js text eol=lfในของฉัน.gitattributesและไม่แสดงความคิดเห็นหลังจากนั้น

ดูเหมือนว่ามันเป็นแค่เวทย์มนตร์คอมไพล์

ฉันพบปัญหาที่คล้ายกันนี้.gitattributesด้วย แต่สำหรับกรณีของฉันเกี่ยวข้องกับ LFS ของ GitHub แม้ว่าสิ่งนี้จะไม่ตรงกับสถานการณ์ของ OP แต่ฉันคิดว่าเป็นโอกาสที่จะแสดงให้เห็นว่า.gitattributesไฟล์ทำอะไรและเหตุใดจึงสามารถนำไปสู่การเปลี่ยนแปลงแบบไม่มีการจัดฉากในรูปแบบของความแตกต่าง "phantom"

ในกรณีของฉันมีไฟล์อยู่ในที่เก็บของฉันเหมือนตั้งแต่เริ่มต้น ในความมุ่งมั่นเมื่อเร็ว ๆ นี้ฉันได้เพิ่มgit-lfs trackกฎใหม่โดยใช้รูปแบบที่อยู่ในความเข้าใจย้อนหลังกว้างไปหน่อยและจบลงด้วยการจับคู่ไฟล์โบราณนี้ ฉันรู้ว่าฉันไม่ต้องการเปลี่ยนไฟล์นี้; ฉันรู้ว่าฉันไม่ได้เปลี่ยนไฟล์ แต่ตอนนี้มันอยู่ในการเปลี่ยนแปลงแบบไม่สเตจของฉันและจำนวนเงินที่จ่ายในการเช็คเอาต์หรือรีเซ็ตยากในไฟล์นั้นไม่สามารถแก้ไขได้ ทำไม?

ส่วนขยาย GitHub LFS ทำงานเป็นหลักผ่านการใช้ประโยชน์จากตะขอที่gitให้การเข้าถึงผ่านทาง.gitattributesไฟล์ โดยทั่วไปรายการใน.gitattributesระบุวิธีการจับคู่ไฟล์ควรประมวลผล ในกรณีของ OP มันเกี่ยวข้องกับการสิ้นสุดบรรทัดปกติ ในของฉันมันเป็นไปได้หรือไม่ที่จะให้ LFS จัดการกับที่เก็บไฟล์ ในทั้งสองกรณีไฟล์จริงที่gitเห็นเมื่อคำนวณ a git diffไม่ตรงกับไฟล์ที่คุณเห็นเมื่อคุณตรวจสอบไฟล์ ดังนั้นหากคุณเปลี่ยนวิธีการประมวลผลไฟล์ผ่าน.gitattributesรูปแบบที่ตรงกับมันจะปรากฏเป็นการเปลี่ยนแปลงที่ไม่คงที่ในรายงานสถานะแม้ว่าจะไม่มีการเปลี่ยนแปลงในไฟล์จริงๆ

ทั้งหมดที่กล่าวว่า "คำตอบ" ของคำถามคือหากการเปลี่ยนแปลงใน.gitattributesไฟล์เป็นสิ่งที่คุณต้องการจะทำคุณควรเพิ่มการเปลี่ยนแปลงและดำเนินการต่อไป ถ้าไม่เช่นนั้นให้แก้ไข.gitattributesเพื่อแสดงสิ่งที่คุณอยากทำ

อ้างอิง

1. ข้อมูลจำเพาะของ GitHub LFS - คำอธิบายที่ยอดเยี่ยมเกี่ยวกับวิธีการเชื่อมต่อเข้ากับcleanและsmudgeการเรียกใช้ฟังก์ชันเพื่อแทนที่ไฟล์ของคุณในgitวัตถุด้วยไฟล์ข้อความธรรมดาที่มีแฮช

2. gitattributes เอกสาร - รายละเอียดทั้งหมดเกี่ยวกับสิ่งที่มีอยู่เพื่อกำหนดวิธีการgitประมวลผลเอกสารของคุณ

ผมมีปัญหาเหมือนกัน. ฉันทำgit reset --hard HEADแต่ยังทุกครั้งที่ฉันทำgit statusฉันเห็นไฟล์บางไฟล์ที่ถูกแก้ไข

ทางออกของฉันค่อนข้างง่าย ฉันเพิ่งปิด IDE ของฉัน (นี่คือ Xcode) และปิดบรรทัดคำสั่งของฉัน (นี่คือเทอร์มินัลใน Mac OS ของฉัน) และลองอีกครั้งและใช้งานได้

แต่ฉันก็ไม่สามารถที่จะค้นหาสิ่งที่เกิดจากปัญหา

ฉันเชื่อว่ามีปัญหาเกี่ยวกับ git สำหรับ Windows ที่ git สุ่มเขียนบรรทัดที่ไม่ถูกต้องในการชำระเงินและวิธีแก้ปัญหาเพียงอย่างเดียวคือชำระเงินสาขาอื่นและบังคับให้ git เพิกเฉยต่อการเปลี่ยนแปลง จากนั้นชำระเงินที่สาขาที่คุณต้องการทำงานจริง

git checkout master -f
git checkout <your branch>

โปรดทราบว่าการดำเนินการนี้จะยกเลิกการเปลี่ยนแปลงใด ๆ ที่คุณอาจทำโดยเจตนาดังนั้นให้ทำเช่นนี้ต่อเมื่อคุณมีปัญหานี้ทันทีหลังจากเช็คเอาต์

แก้ไข: ฉันอาจจะโชคดีจริง ๆ ในครั้งแรก ปรากฎว่าฉันได้รับอีกเล็กน้อยหลังจากเปลี่ยนสาขา ปรากฎว่าไฟล์คอมไพล์ถูกรายงานว่ามีการแก้ไขหลังจากเปลี่ยนสาขากำลังเปลี่ยน (เห็นได้ชัดว่าเนื่องจากคอมไพล์ไม่ได้ใช้บรรทัด CRLF ที่ลงท้ายด้วยไฟล์อย่างเหมาะสม)

ฉันอัพเดตเป็น git ล่าสุดสำหรับ Windows และหวังว่าปัญหาจะหายไป

ปัญหาที่คล้ายกันแม้ว่าฉันจะแน่ใจได้เฉพาะบนพื้นผิว อย่างไรก็ตามมันอาจช่วยใครซักคน: สิ่งที่ฉันทำ (FWIW ใน SourceTree): stashed ไฟล์ที่ไม่มีข้อผูกมัดแล้วทำการฮาร์ดรีเซ็ต

เช่นเดียวกับคำตอบอื่น ๆ ที่ชี้ให้เห็นปัญหาคือเนื่องจากการแก้ไขอัตโนมัติในตอนท้ายบรรทัด ฉันพบปัญหานี้กับไฟล์ * .svg ฉันใช้ไฟล์ svg สำหรับไอคอนในโครงการของฉัน

ในการแก้ปัญหานี้ฉันขอให้ git รู้ว่าไฟล์ svg ควรได้รับการปฏิบัติเป็นไบนารีแทนที่จะเป็นข้อความโดยเพิ่มบรรทัดด้านล่างลงใน. gitattributes

* .svg ไบนารี

ในสถานการณ์ที่คล้ายคลึงกัน เป็นผลมาจากความทรมานเป็นเวลาหลายปีกับโปรแกรมเมอร์หลายคนที่สามารถเข้ารหัสสิ่งที่แตกต่างกันของปลายบรรทัด (. asp , .js, .css ... ไม่ใช่สาระสำคัญ) เป็นไฟล์เดียว เวลาที่ผ่านมาปฏิเสธ. gitattributes การตั้งค่าสำหรับ repo ซ้ายautorclf = trueและsafecrlf = warnและ

ปัญหาล่าสุดเกิดขึ้นเมื่อทำการซิงโครไนซ์จากไฟล์เก็บถาวรด้วยปลายเส้นที่แตกต่างกัน หลังจากการคัดลอกจากไฟล์เก็บถาวรในสถานะ git หลายไฟล์จะถูกเปลี่ยนด้วยบันทึกย่อ

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

เคล็ดลับจากการทำให้บรรทัดสุดท้ายของการทำงานใน Git เป็นปกติ? ช่วย

git add -u

ความเป็นไปได้อีกอย่างหนึ่งที่ฉันพบคือแพคเกจหนึ่งในที่เก็บจบลงด้วยการถอด HEAD หากไม่มีคำตอบที่นี่ช่วยได้และคุณพบข้อความสถานะ git เช่นนี้คุณอาจมีปัญหาเดียวกัน:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

การเข้าไปในpath/to/packageโฟลเดอร์ a git statusควรให้ผลลัพธ์ดังต่อไปนี้:

HEAD detached at 7515f05

และคำสั่งต่อไปนี้ควรแก้ไขปัญหาที่masterสาขาในประเทศของคุณควรจะถูกแทนที่:

git checkout master

และคุณจะได้รับข้อความว่าสาขาในพื้นที่ของคุณจะมีภาระผูกพันบางอย่างอยู่ด้านหลังสาขาระยะไกล git pullและคุณควรจะออกจากป่า!

ด้วยเหตุผลบางอย่าง

git add .

ไม่ทำงานแต่

$ git add -A

ทำงานออกมา!