تعرض حالة git التعديلات، بينما لا يقوم git checkout - <file> بإزالتها

Question

أرغب في إزالة جميع التغييرات التي أجريت على نسخة العمل الخاصة بي.
جري git status يظهر الملفات المعدلة.
يبدو أن لا شيء أفعله يزيل هذه التعديلات.
على سبيل المثال:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Answer 1

هناك مشاكل متعددة يمكن أن يسبب هذا السلوك:

خط انتهاء التطبيع

كان لدي هذه الأنواع من المشاكل أيضا. ينزل إلى GIT تحويل CRLF تلقائيا إلى LF. يحدث هذا عادة عن نهايات خط مختلطة في ملف واحد. يتم تطبيع الملف في الفهرس، ولكن عندما يقوم GIT بإنهاءه مرة أخرى لفيلمه ضد الملف في شجرة العمل، فإن النتيجة مختلفة.

ولكن إذا كنت ترغب في إصلاح هذا، يجب عليك تعطيل core.autocrlf., ، قم بتغيير كل نهايات السطر إلى LF، ثم تمكنها مرة أخرى. أو يمكنك تعطيلها تماما من خلال القيام:

git config --global core.autocrlf false

بدلاً من core.autocrlf., ، يمكنك أيضا التفكير في استخدام .gitattribute الملفات. بهذه الطريقة، يمكنك التأكد من أن الجميع يستخدمون Repo يستخدمون نفس قواعد التطبيع، مما يمنع نهايات الخط المختلطة في المستودع.

تنظر أيضا في الإعداد core.safecrlf. لتحذير إذا كنت ترغب في تحذير جيت لتحذيرك عندما يتم إجراء تطبيع غير قابل للانعضية.

جيت manpages. قل هذا:

يحمل تحويل CRLF فرصة طفيفة في تفسير البيانات. AutoClf = صحيح سوف يحول CRLF إلى LF أثناء الالتزام و LF إلى CRLF أثناء الخروج. لا يمكن إعادة إنشاء ملف يحتوي على مزيج من LF و CRLF قبل الالتزام عن طريق GIT. بالنسبة للملفات النصية، هذا هو الشيء الصحيح الذي يجب القيام به: إنه يصحح نهايات السطر بحيث يكون لدينا نهايات خط LF فقط في المستودع. ولكن بالنسبة للملفات الثنائية التي يتم تصنيفها عن طريق الخطأ لأن التحويل يمكن أن تفسد البيانات.

أنظمة الملفات غير حساسة للحالة

في نظام ملفات غير حساسة لحالة الأحرف، عندما يكون اسم الملف نفسه مع غلاف مختلف في المستودع، يحاول GIT تسجيل الخروج كلاهما، ولكن ينتهي المرء فقط في نظام الملفات. عندما تحاول GIT مقارنة الجزء الثاني، ستقارنها بالملف الخطأ.

سيكون الحل إما تحويل نظام ملفات غير حساسة غير حساسة، ولكن هذا في معظم الحالات غير ممكن أو إعادة تسميته وارتكاب أحد الملفات على نظام ملفات آخر.

Answer 2

كنت أواجه هذه المشكلة على Windows ولكن لم يكن مستعدا للنظر في تداعيات استخدام config --global core.autocrlf false أنا أيضا لم يكن مستعدا للتخلي عن فروع خاصة أخرى وأجهاده في خبأتي وتبدأ مع استنساخ جديد. أنا فقط بحاجة للحصول على شيء ما. الآن.

هذا عملت بالنسبة لي، على فكرة أنك تترك Git أعد كتابة دليل العمل الخاص بك تماما:

git rm --cached -r .
git reset --hard

(لاحظ أن الجري فقط git reset --hard لم يكن جيدا بما فيه الكفاية ولا كان سهل rm على الملفات قبل reset كما يقترح في التعليقات على السؤال الأصلي)

Answer 3

حل آخر قد يعمل من أجل الناس، لأن أي من خيارات النص يعمل بالنسبة لي:

1. استبدال محتوى .gitattributes مع خط واحد: * binary. وبعد يخبر هذا GIT بمعالجة كل ملف كملف ثنائي لا يستطيع فعل أي شيء به.
2. تحقق من انتهاء هذه الرسالة للملفات المخالفة؛ إذا لم يكن الأمر كذلك git checkout -- <files> لاستعادةها إلى إصدار المستودع
3. git checkout -- .gitattributes لاستعادة .gitattributes ملف إلى حالته الأولية
4. تحقق من أن الملفات لا تزال غير ملحوظة كما تم تغييرها.

Answer 4

بالنسبة للأشخاص الذين يواجهون هذه المشكلة: يمكن أن يكون لها تغييرات FileMode نفس الأعراض. git config core.filemode false سوف إصلاحه.

Answer 5

لقد كان هذا يدفعني إلى الجنون، خاصة أنني لم أستطع إصلاح هذا دون أي من الحلول الموجودة عبر الإنترنت. وهنا كيف حلها. لا يمكن أن تأخذ الاعتمادات هنا لأن هذا هو عمل زميل :)

مصدر المشكلة: كان التثبيت الأولي لجهاز GIT بدون تحويل خط تلقائي على Windows. تسبب ذلك في الالتزام الأولي الخاص بي بالضغط من دون النهاية المناسبة.

ملاحظة: هذا هو الحل المحلي فقط. الرجل التالي استنساخ الريبو ستظل عالقا بهذه المشكلة. يمكن العثور على حل دائم هنا: https://help.github.com/articles/dealing-with-line-endings/#re-normizing-a-Repository..

الإعداد: Xubuntu 12.04 git repo مع مشروع glfw

المشكلة: غير قادر على إعادة تعيين ملفات GLFW. إنهم يظهرون دائما كما تم تعديلها، بغض النظر عما حاولت.

تم حلها:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Answer 6

كان لدي ملف .bat مع نفس المشكلة (تعذر التخلص منه في الملفات غير المتناثرة). GIT Checkout - لم تنجح، ولا أيا من الاقتراحات الموجودة في هذه الصفحة. الشيء الوحيد الذي عمل بالنسبة لي هو القيام به:

git stash save --keep-index

ثم لحذف Stash:

git stash drop

Answer 7

حصلت على نفس المشكلة مرتين!في كلتا المرتين عندما قمت بتخزين بعض التغييرات التي أجريتها ثم حاولت إعادتها مرة أخرى.لم أتمكن من إجراء التغييرات نظرًا لأن لدي الكثير من الملفات التي تم تغييرها - ولكنها ليست كذلك!هم سواء بالضبط.

أعتقد الآن أنني جربت جميع الحلول المذكورة أعلاه دون نجاح.بعد محاولة

git rm --cached -r .
git reset --hard

لقد قمت الآن بتعديل جميع الملفات الموجودة في مستودعي تقريبًا.

عند تغيير الملف يقول لقد حذفت جميع الأسطر ثم أضفتها مرة أخرى.

نوع من القلق.سأتجنب الآن الإخفاء في المستقبل..

الحل الوحيد هو استنساخ مستودع جديد والبدء من جديد.(فعلتها آخر مرة)

Answer 8

كنت قادرا فقط على إصلاح هذا من خلال حذف ملف .gitattributes الخاص بي (الذي يعرف * text=auto و *.c text).

هرب git status بعد حذف التعديلات قد ولت. لم يعودوا حتى بعد وضع. تم وضعه في مكانه.

Answer 9

حاول القيام بذلك

بوابة الخروج -f.

يجب أن يوضح كل التغييرات في الريبو المحلي الحالي

Answer 10

وجود نهايات خط ثابت هو شيء جيد. على سبيل المثال، لن يؤدي إلى زيادة الدمج غير الضرورية، وإن كانت تافهة. لقد رأيت Visual Studio إنشاء ملفات مع نهايات خط مختلطة.

أيضا بعض البرامج مثل BASH (على Linux) تتطلب أن .shs ملفات LF.

للتأكد من حدوث ذلك، يمكنك استخدام Gitattributes. إنه يعمل على مستودع المستودع بغض النظر عن قيمة AutCRLF.

على سبيل المثال، يمكنك الحصول على .gitattributes مثل هذا: * النص = السيارات

يمكنك أيضا أن تكون أكثر تحديدا لكل نوع ملف / ملحق إذا كانت مهمة في قضيتك.

ثم يستطيع AutoClF تحويل نهايات خط برامج Windows محليا.

على C # / C ++ / Java / Ruby / R، نظام Windows / Linux هذا يعمل بشكل جيد. لا توجد مشاكل حتى الآن.

Answer 11

كان لدي نفس الأعراض ولكنها ناتجة عن شيء مختلف.

لم اكن قادرا على:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

حتى علىgit rm --cached app.js علامات أنها محذوفة وفي ملفات غير مستحقة يمكنني رؤية app.js.js. ولكن عندما حاولت rm -rf app.js و peform. git status مرة أخرى، لا يزال يظهر لي الملف في "غير مهذب".

بعد الزوجين من المحاولات مع زميل وجدنا ذلك، أنه كان ناتج عن نخر!

كما Grunt تم تشغيله، ولأن App.js قد تم إنشاؤه من زوجين من ملفات JS الأخرى، اكتشفنا أنه بعد كل عملية مع ملفات JS (أيضا هذا app.js) Sprunt Recreate App.js مرة أخرى.

Answer 12

يمكن أن تحدث هذه المشكلة أيضا عندما يعمل المساهم في Repo على جهاز Linux، أو يتم تغيير Windows باستخدام أذونات Cygwin وملفات الملفات. git يعرف فقط من 755 و 644.

مثال على هذه المشكلة وكيفية التحقق من ذلك:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

لتجنب ذلك، يجب عليك التأكد من إعداد GIT بشكل صحيح

git config --global core.filemode false

Answer 13

هناك الكثير من الحلول هنا وقد جربت بعضها قبل توصلت مع بلدي. على أي حال هنا واحد ...

كانت مشكلتنا هي أنه لم يكن لدينا أي إنفاذ للانتهاءين والمستودع ديك مزيج من DOS / UNIX. والأسوأ من ذلك هو أنه كان في الواقع مصدر مفتوح في هذا الموقف، والتي شاركنا. تم اتخاذ القرار من قبل أولئك الذين لديهم ملكية أساسية لمستودع نظام التشغيل لتغيير جميع الخطوط الجائرات إلى UNIX وتم الالتزام بما شملت .gitattributes لفرض نهايات الخط.

لسوء الحظ، يبدو أن هذا يسبب مشاكل مثيل لها هنا حيث تم بمجرد دمج التعليمات البرمجية قبل إجراء ملفات DOS-2-Unix، سيتم تمييز الملفات إلى الأبد كما تم تغييرها ولا يمكن الرجوع إليها.

خلال بحثي لهذا جئت - https://help.github.com/articles/dealing-with-line-endings/ - إذا واجهت هذه المشكلة مرة أخرى سأبدأ لأول مرة بحدوث ذلك.

---

هنا هو ما فعلته:

1. كنت في البداية أندمت دمج قبل أن أدرك هذه المشكلة وكان لديها لإحباط ذلك - git reset --hard HEAD (ركضت في نزاع دمج. كيف يمكنني إحباط الدمج؟)

2. فتحت الملفات المعنية في VIM وتغييرها إلى UNIX (:set ff=unix). أداة مثل dos2unix يمكن استخدامها بدلا من ذلك

3. ملتزم

4. اندمجت master في (يكون لدى سيد التغييرات DOS-2-UNIX)

   git checkout old-code-branch; git merge master

5. تم حل النزاعات والملفات DOS مرة أخرى لذلك :set ff=unix عندما تكون في VIM. (لاحظ أنني قمت بتثبيت https://github.com/itchyny/lightline.vim. مما سمح لي أن أرى ما هو تنسيق الملف في حالة VIM)

6. ملتزم. كل فرزها!

Answer 14

لقد ارتكبت كل التغييرات ثم فعلت والتراجع عن الالتزام. هذا عملت بالنسبة لي

إضافة بوابة.

جيت ارتكاب -M "ارتكاب عشوائي"

جيت إعادة تعيين رئيس رئيس ~ 1

Answer 15

إذا استنسخ مستودع، فهذا ترى على الفور تغييرات معلقة، فإن المستودع في حالة غير متناسقة. من فضلك لا تعلق * text=auto من .gitattributes ملف. تم وضع ذلك على وجه التحديد لأن مالك المستودع يريد جميع الملفات المخزنة باستمرار مع نهايات خط LF.

كما ذكر بواسطة Hankca، بعد التعليمات حول https://help.github.com/articles/dealing-with-line-endings/ هي الطريقة للذهاب لإصلاح المشكلة. زر سهل:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

ثم دمج (أو طلب سحب) الفرع إلى صاحب الريبو.

Answer 16

القضية التي هربت إليها هي أن ويندوز لا يهتم بأسماح اسم الملف، ولكن git يفعل. لذا قم بتخزين Git إصدارا أقل وأحجة كبيرة من الملف ولكنه يمكن فقط الخروج فقط.

Answer 17

لا شيء آخر في هذه الصفحة عملت. هذا عمل أخيرا بالنسبة لي. لا تظهر أي ملفات غير مقصودة أو مرتبطة.

git add -A
git reset --hard

Answer 18

بالنسبة لي، كانت المشكلة أنه تم فتح Visual Studio عند إجراء الأمر

git checkout <file>

بعد إغلاق Visual Studio، عمل الأمر ويمكنني أخيرا تطبيق عملي من المكدس. لذا تحقق من جميع التطبيقات التي قد تقوم بإجراء تغييرات على التعليمات البرمجية الخاصة بك، على سبيل المثال Sourcetree و SmartGit و Notepad أو المفكرة ++ والمحررين الآخرين.

Answer 19

وافقنا وضعا مماثلا في شركتنا. لم يساعدنا أي من الأساليب المقترحة. نتيجة للبحوث، تم الكشف عن المشكلة. الشيء كان ذلك في GIT كان هناك ملفان، وأسماء التي تختلف فقط في سجل الرموز. رأيتهم أنظمة يونيكس كملفات مختلفة، لكن النوافذ كانت مجنونة. لحل المشكلة، حذفنا أحد الملفات الموجودة على الخادم. بعد ذلك، ساعدت المستودعات المحلية على Windows الأوامر القليلة التالية (بتسلسلات مختلفة):

git reset --hard
git pull origin
git merge

Answer 20

ركضت في هذه المشكلة عدة مرات من قبل. أنا أعمل حاليا على جهاز Windows 10 الذي يوفره صاحب العمل الخاص بي. اليوم، كان سبب هذا السلوك البذائق بالذات هو إيجاد فرع جديد من فرع "تطوير" الخاص بي. لسبب ما، بعد أن أعود إلى فرع "تطوير"، استمرت بعض الملفات العشوائية على ما يبدو وكانت تظهر ك "تعديل" في "حالة الجيت".

أيضا، في تلك المرحلة لم أستطع الخروج من فرع آخر، لذلك كنت عالقا في فرع "تطوير" الخاص بي.

وهذا هو ما فعلته:

$ git log

لقد لاحظت أن الفرع الجديد الذي قمت بإنشائه من "تطوير" في وقت سابق كان يظهر في رسالة "الالتزام" الأولى، يتم الرجوع إليها في النهاية "الرأس -> تطوير، أصل / تطوير، الأصل / الرأس، the-branch-i-cretry- في وقت سابق اليوم".

منذ أن كنت حقا بحاجة إليها، حذفت ذلك:

$ git branch -d The-branch-i-created-earlier-today

كانت الملفات المتغيرة لا تزال تظهر، لذلك فعلت:

$ git stash

هذا حل مشكلتي:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

بالتاكيد $ git stash list سوف تظهر التغييرات المخزنة، وبما أن لدي قلة ولم أكن بحاجة إلى أي من مخبئي، فعلت $ git stash clear لحذف جميع القصارات.

ملاحظة: لم أحاول القيام بما اقترح شخص هنا قبلي:

$ git rm --cached -r .
$ git reset --hard

قد يكون هذا قد عمل كذلك، سأكون متأكدا من تجربته في المرة القادمة التي أجريها في هذه المشكلة.

Answer 21

حلها عن طريق التحرير. جيت / التكوين، مضيفا:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

ثم ذهبت إلى .git / res / heads / name_branch ووضع معرف الالتزام الأخيرenter code here

Answer 22

حلها بهذه الطريقة:

1. انسخ محتويات التعليمات البرمجية الصحيحة التي تريدها
2. حذف الملف الذي يسبب المشكلة (الجهاز الذي لا يمكنك العودة إليه) من القرص. الآن يجب أن تجد كلا الإصدارين من نفس الملف الذي يتم تحديده على أنه تم حذفه.
3. ارتكاب حذف الملفات.
4. قم بإنشاء الملف مرة أخرى بنفس الاسم والصقه في التعليمات البرمجية الصحيحة التي قمت بنسخها في الخطوة 1
5. ارتكب إنشاء الملف الجديد.

---

هذا ما عمل لي.