git - كيفية التراجع عن "git add" قبل الالتزام؟




15 Answers

يمكنك التراجع عن git add قبل الالتزام بها

git reset <file>

التي ستزيلها من الفهرس الحالي (قائمة "على وشك الالتزام") دون تغيير أي شيء آخر.

يمكنك استخدام

git reset

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

في الإصدارات القديمة من Git ، تعادل الأوامر المذكورة أعلاه git reset HEAD <file> و git reset HEAD على التوالي ، وستفشل إذا لم يتم تحديد HEAD (لأنك لم تقم بعد بإجراء أي تعهدات في الريبو الخاص بك) أو غامضة (لأنك إنشاء فرع يسمى HEAD ، وهو شيء غبي لا يجب عليك فعله). تم تغيير هذا في Git 1.8.2 ، على الرغم من ذلك ، في الإصدارات الحديثة من Git يمكنك استخدام الأوامر أعلاه حتى قبل إجراء الالتزام الأول:

"git reset" (بدون خيارات أو معلمات) المستخدمة للخطأ عندما لا يكون لديك أي التزام في تاريخك ، لكنه الآن يمنحك فهرس فارغ (لمطابقة غير موجود ارتكاب لا تعمد حتى).

أقوم بإضافة ملفات git عن طريق الخطأ باستخدام الأمر:

git add myfile.txt

لم git commit بعد بتشغيل git commit . هل هناك طريقة للتراجع عن هذا ، لذا لن يتم تضمين هذه الملفات في الالتزام؟

هناك 48 إجابات حتى الآن (بعضها محذوف). من فضلك لا تضيف واحدة جديدة إلا إذا كان لديك بعض المعلومات الجديدة.




إذا قمت بكتابة:

git status

سوف يخبرك git ما يتم عرضه ، وما إلى ذلك ، بما في ذلك الإرشادات المتعلقة بكيفية إلغاء التثبيت:

use "git reset HEAD <file>..." to unstage

أجد git يقوم بعمل جيد من دفع لي للقيام بالشيء الصحيح في مثل هذه الحالات.

ملاحظة: الإصدارات الحديثة من git (1.8.4.x) قد تغيرت هذه الرسالة:

(use "git rm --cached <file>..." to unstage)



إضافة إلى الإجابة المقبولة ، إذا كان ملفك المضاف عن طريق الخطأ ضخمًا ، فستلاحظ على الأرجح أنه حتى بعد إزالته من الفهرس باستخدام " git reset " ، فإنه يبدو أنه يشغل مساحة في دليل .git . لا داعي للقلق ، فالملف لا يزال موجودًا بالفعل في المستودع ، ولكن فقط باعتباره "كائنًا فضفاضًا" ، لن يتم نسخه إلى مستودعات أخرى (عبر النسخ ، الدفع) ، وسيتم استصلاح المساحة في النهاية - على الرغم من ربما ليس قريبا جدا. إذا كنت قلقًا ، فيمكنك تشغيل:

git gc --prune=now

تحديث (ما يلي هو محاولتي لإزالة بعض الالتباس الذي يمكن أن ينشأ عن الإجابات الأكثر تصويتًا):

إذن ، ما هو التراجع الحقيقي للـ git add ؟

git reset HEAD <file> ؟

أو

git rm --cached <file> ؟

بالمعنى الدقيق للكلمة ، وإذا لم أكن مخطئا: لا شيء .

لا يمكن التراجع عن git add - بأمان ، بشكل عام.

دعونا نتذكر أولا ما تفعله git add <file> الواقع:

  1. إذا لم يتم تتبع <file> مسبقًا ، فإن git add تضيفه إلى ذاكرة التخزين المؤقت ، بمحتواه الحالي.

  2. إذا تم بالفعل تتبع <file> ، git add بحفظ المحتوى الحالي (لقطة ، إصدار) إلى ذاكرة التخزين المؤقت. في GIT ، لا يزال يسمى هذا الإجراء باسم إضافة (وليس مجرد تحديث ) ، نظرًا لأن نسختين مختلفتين (لقطات) من الملف يتم اعتبارهما عنصرين مختلفين: وبالتالي ، فإننا بالفعل نضيف عنصرًا جديدًا إلى ذاكرة التخزين المؤقت ، لنكون في النهاية تلتزم في وقت لاحق.

في ضوء ذلك ، فإن السؤال غامض بعض الشيء:

أنا أضيفت الملفات عن طريق الخطأ باستخدام الأمر ...

يبدو أن سيناريو البروتوكول الاختياري هو السيناريو الأول (الملف غير المتتبع) ، ونريد أن يقوم "التراجع" بإزالة الملف (وليس فقط المحتويات الحالية) من العناصر المتعقبة. إذا كانت هذه هي الحالة ، فلا بأس من تشغيل git rm --cached <file> .

ويمكننا أيضًا تشغيل git reset HEAD <file> . هذا الأمر مفضل بشكل عام ، لأنه يعمل في كل من السيناريوهين: فهو يعمل أيضًا على التراجع عندما أضفنا بطريق الخطأ إصدارًا من عنصر تم تتبعه بالفعل.

لكن هناك نوعان من التحذيرات.

أولاً: هناك (كما هو git rm --cached في الإجابة) سيناريو واحد فقط لا يعمل فيه git reset HEAD ، لكن git rm --cached يفعل: مستودع جديد (لا يلتزم). لكن ، في الحقيقة ، هذه قضية غير ذات صلة عمليًا.

ثانيًا: كن على دراية بأن git reset HEAD لا يمكنه استرداد محتويات الملف المخزن مؤقتًا بشكل سحري ، ولكنه يعيدها فقط من HEAD. إذا git add الموجهة لدينا إصدارًا سابقًا غير ملتزم ، فلن نتمكن من استعادته. لهذا السبب ، بالمعنى الدقيق للكلمة ، لا يمكننا التراجع [*].

مثال:

$ git init
$ echo "version 1" > file.txt
$ git add file.txt   # first add  of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add  file.txt   # stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt   
$ git diff  file.txt
-version 2
+version 3
$ git add  file.txt    # oops we didn't mean this
$ git reset HEAD file.txt  # undo ?
$ git diff --cached file.txt  # no dif, of course. stage == HEAD
$ git diff file.txt   # we have lost irrevocably "version 2"
-version 1
+version 3

بالطبع ، هذا ليس حرجًا للغاية إذا ما اتبعنا سير العمل المعتاد البطيء لعمل "git add" فقط لإضافة ملفات جديدة (الحالة 1) ، ونقوم بتحديث محتويات جديدة عبر الالتزام ، git commit -a الأمر.

* (تعديل: ما ورد أعلاه صحيحًا عمليًا ، ولكن لا يزال هناك بعض الطرق غير الملحوظة / الملتوية قليلاً لاستعادة التغييرات التي تم تنظيمها ولكن لم يتم الالتزام بها ثم الكتابة - راجع التعليقات بواسطة Johannes Matokic و iolsmit)




يركض

git gui

وإزالة جميع الملفات يدويا أو عن طريق تحديد كل منهم والنقر على زر unstage من ارتكاب .




لم يتم طرح السؤال بشكل واضح. والسبب هو أن git add لها معنيان:

  1. إضافة ملف جديد إلى منطقة التدريج ، ثم التراجع مع git rm --cached file .
  2. إضافة ملف معدل إلى منطقة التدريج ، ثم التراجع عن git reset HEAD file .

إذا كنت في شك ، استخدم

git reset HEAD file

لأنها تفعل الشيء المتوقع في كلتا الحالتين.

تحذير: إذا قمت بعمل git rm --cached file على ملف تم تعديله (ملف موجود قبل في المستودع) ، فستتم إزالة الملف على git commit ! سيظل موجودًا في نظام الملفات لديك ، ولكن إذا قام شخص آخر بسحب التزامك ، فسيتم حذف الملف من شجرة العمل الخاصة به.

git status ما إذا كان الملف ملفًا جديدًا أو تم تعديله :

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   my_new_file.txt
    modified:   my_modified_file.txt



إذا كنت على التزامك الأولي ولا يمكنك استخدام git reset ، فقم فقط بالإعلان عن "Git bankruptcy" وحذف مجلد .git وابدأ من جديد




يمكن استخدام git remove أو git rm لهذا ، مع العلم - --cached . محاولة:

git help rm



فيما يلي طريقة لتجنب هذه المشكلة المزعجة عند بدء مشروع جديد:

  • قم بإنشاء الدليل الرئيسي لمشروعك الجديد.
  • قم بتشغيل git init .
  • الآن إنشاء ملف .gitignore (حتى لو كان فارغا).
  • قم بتنفيذ ملف .gitignore الخاص بك.

Git يجعل من الصعب حقا القيام git reset إذا لم يكن لديك أي الإلتزامات. إذا قمت بإنشاء التزام أولي صغير فقط من أجل الحصول على واحد ، بعد ذلك يمكنك git add -A و git reset عدة مرات كما تريد من أجل الحصول على كل شيء بشكل صحيح.

ومن المزايا الأخرى لهذه الطريقة أنه إذا واجهت مشكلات نهاية السطر لاحقًا وتحتاج إلى تحديث جميع ملفاتك ، فمن السهل:

  • تحقق من أن الالتزام الأولي. سيؤدي هذا إلى إزالة جميع ملفاتك.
  • ثم تحقق من التزامك الأخير مرة أخرى. سيؤدي ذلك إلى استرداد نسخ جديدة من ملفاتك باستخدام إعدادات نهاية السطر الحالية.



لاحظ أنه في حالة إخفاقك في تحديد المراجعة ، يجب عليك تضمين فاصل. مثال من وحدة التحكم الخاصة بي:

git reset <path_to_file>
fatal: ambiguous argument '<path_to_file>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

git reset -- <path_to_file>
Unstaged changes after reset:
M   <path_to_file>

(نسخة git 1.7.5.4)




لإعادة تعيين كل ملف في مجلد معين (ومجلداته الفرعية) ، يمكنك استخدام الأمر التالي:

git reset *



فقط اكتب git reset فإنه سيتم العودة مرة أخرى وهو كما لو لم تكتب git add . منذ ارتكابك الأخير. تأكد من أنك ارتكبت من قبل.




لملف معين:

  • git reset my_file.txt
  • git الخروج my_file.txt

لجميع الملفات المضافة:

  • git إعادة.
  • بوابة الخروج.

ملاحظة: يؤدي السحب إلى تغيير الشفرة في الملفات والانتقال إلى آخر حالة (التزام) تم تحديثها. إعادة التعيين لا يغير الرموز ؛ انها مجرد إعادة تعيين رأس.




للتراجع عن استخدام إضافة git

git reset filename




git reset filename.txt

سيزيل ملفًا باسم filename.txt من الفهرس الحالي ، منطقة "على وشك الالتزام" ، دون تغيير أي شيء آخر.




git reset filename.txt  

سيزيل ملفًا باسم filename.txt من الفهرس الحالي ، منطقة "على وشك الالتزام" ، دون تغيير أي شيء آخر.




Related