git-filter-branch - عبر الإنترنت في السحابة

برنامج:

اسم

git-filter-branch - إعادة كتابة الفروع

موجز

طائرة نفاثة فرع التصفية [--مرشح البيئة ] [--مرشح الشجرة ]
[--مرشح الفهرس ] [--مرشح الوالدين ]
[--مرشح الرسالة ] [--مرشح الالتزام ]
[--tag-name-filter ] [--عامل تصفية الدليل الفرعي ]
[--تقليم-فارغ]
[--إبداعي ] [-د ] [-و | --قوة]
[--] [ ...]

الوصف

يتيح لك إعادة كتابة سجل مراجعة Git عن طريق إعادة كتابة الفروع المذكورة في ملف
الخيارات>، وتطبيق مرشحات مخصصة على كل مراجعة. يمكن لهذه المرشحات تعديل كل شجرة
(على سبيل المثال، إزالة ملف أو تشغيل إعادة كتابة Perl على جميع الملفات) أو معلومات حول كل منها
يقترف. بخلاف ذلك، جميع المعلومات (بما في ذلك أوقات الالتزام الأصلية أو معلومات الدمج)
سيتم الحفاظ عليها.

سيقوم الأمر بإعادة كتابة الملف فقط إيجابي المراجع المذكورة في سطر الأوامر (على سبيل المثال، إذا كنت
pass أ..ب، فقط b سيتم إعادة كتابتها). إذا لم تحدد أي مرشحات، فسيتم تنفيذ الالتزامات
يتم إعادة الالتزام بها دون أي تغييرات، والتي لن يكون لها أي تأثير في العادة. ومع ذلك، هذا
قد يكون مفيدًا في المستقبل للتعويض عن بعض أخطاء Git أو ما شابه، وبالتالي فإن مثل هذا
الاستخدام مسموح.

ملحوظة: يكرم هذا الأمر ملف .git/info/grafts والمراجع الموجودة في مساحة الاسم refs/replace/.
إذا كان لديك أي طعوم أو مراجع بديلة محددة، فسيؤدي تشغيل هذا الأمر إلى إجرائها
دائمة.

تحذير! سيكون للسجل المُعاد كتابته أسماء كائنات مختلفة لجميع الكائنات و
لن تتقارب مع الفرع الأصلي. لن تكون قادرًا على الدفع بسهولة و
توزيع الفرع المعاد كتابته فوق الفرع الأصلي. من فضلك لا تستخدم هذا
الأمر إذا كنت لا تعرف الآثار الكاملة، وتجنب استخدامه على أي حال، إذا كان بسيطا
الالتزام الفردي سيكون كافيًا لإصلاح مشكلتك. (راجع "الاسترداد من المنبع".
قسم "REBASE" في git-rebase(١) لمزيد من المعلومات حول إعادة الكتابة المنشورة
تاريخ.)

تأكد دائمًا من صحة النسخة المعاد كتابتها: المراجع الأصلية، إذا كانت مختلفة عنها
سيتم تخزين تلك المعاد كتابتها في مساحة الاسم المراجع/الأصلي/.

لاحظ أنه بما أن هذه العملية مكلفة جدًا للإدخال/الإخراج، فقد تكون إعادة التوجيه فكرة جيدة
الدليل المؤقت خارج القرص مع -d الخيار، على سبيل المثال على tmpfs. يقال تسارع
ملحوظ جدا.

فلاتر
يتم تطبيق المرشحات بالترتيب كما هو موضح أدناه. ال الحجة دائما
تم تقييمها في سياق الصدفة باستخدام وحدة التقييم الأمر (مع استثناء ملحوظ لـ
مرشح الالتزام لأسباب فنية). قبل ذلك، كان متغير البيئة $GIT_COMMIT
سيتم تعيينه ليحتوي على معرف الالتزام الذي تتم إعادة كتابته. أيضًا، GIT_AUTHOR_NAME،
GIT_AUTHOR_EMAIL، GIT_AUTHOR_DATE، GIT_COMMITTER_NAME، GIT_COMMITTER_EMAIL، و
يتم أخذ GIT_COMMITTER_DATE من الالتزام الحالي وتصديره إلى البيئة
من أجل التأثير على هويات المؤلف والملتزم بالتزام الاستبدال الذي أنشأه
بوابة الالتزام(١) بعد تشغيل المرشحات.

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

A رسم خريطة تتوفر وظيفة تأخذ وسيطة "معرف sha1 الأصلي" وتخرج a
"معرف sha1 المعاد كتابته" إذا تمت إعادة كتابة الالتزام بالفعل، و"معرف sha1 الأصلي"
خلاف ذلك؛ ال رسم خريطة يمكن أن تقوم الوظيفة بإرجاع معرفات متعددة في أسطر منفصلة إذا كان مرشح الالتزام الخاص بك
المنبعثة ارتكابات متعددة.

OPTIONS

--env-filter
يمكن استخدام هذا المرشح إذا كنت بحاجة فقط إلى تعديل البيئة التي يتم فيها الالتزام
سوف تنجز. على وجه التحديد، قد ترغب في إعادة كتابة المؤلف/الملتزم
متغيرات بيئة الاسم/البريد الإلكتروني/الوقت (انظر بوابة الالتزام(١) للتفصيل). لا
ننسى لإعادة تصدير المتغيرات.

--مرشح الشجرة
هذا هو المرشح لإعادة كتابة الشجرة ومحتوياتها. يتم تقييم الحجة
في Shell مع تعيين دليل العمل على جذر الشجرة المسحوبة. الجديد
يتم بعد ذلك استخدام الشجرة كما هي (تتم إضافة الملفات الجديدة تلقائيًا، وتتم إزالة الملفات المختفية تلقائيًا
- لا ملفات .gitignore ولا أي قواعد تجاهل أخرى HAVE أي تأثير!).

--index-filter
هذا هو عامل التصفية لإعادة كتابة الفهرس. إنه مشابه لمرشح الشجرة ولكنه يفعل ذلك
لا تحقق من الشجرة، مما يجعلها أسرع بكثير. كثيرا ما تستخدم مع git rm
--cached --ignore-unmatch...، راجع الأمثلة أدناه. بالنسبة لحالات الشعر، انظر تحديث بوابة-
مؤشر(1).

--parent-filter
هذا هو عامل التصفية لإعادة كتابة القائمة الأصلية للالتزام. سوف يستقبل الوالد
سلسلة على stdin ويجب إخراج السلسلة الأصلية الجديدة على stdout. السلسلة الأصلية هي
بالصيغة الموضحة في بوابة الالتزام(1): فارغ للالتزام الأولي، "-p
parent" للالتزام العادي و"-pparent1 -pparent2 -pparent3..." للدمج
ارتكب.

--msg-filter
هذا هو عامل التصفية لإعادة كتابة رسائل الالتزام. يتم تقييم الحجة في
Shell مع رسالة الالتزام الأصلية عند الإدخال القياسي؛ يتم استخدام الإخراج القياسي
كرسالة الالتزام الجديدة.

--commit-filter
هذا هو عامل التصفية لتنفيذ الالتزام. إذا تم تحديد هذا الفلتر، فسيكون كذلك
دعا بدلا من طائرة نفاثة الالتزام شجرة الأمر، مع وسيطات النموذج "
[(-ص )...]" ورسالة السجل على stdin. ومن المتوقع معرف الالتزام
على ستدوت.

كامتداد خاص، قد يصدر مرشح الالتزام معرفات التزام متعددة؛ في هذه الحالة،
الأطفال المعاد كتابتهم في الالتزام الأصلي سيكونون جميعًا آباءً.

يمكنك استخدام رسم خريطة وظيفة الراحة في هذا الفلتر، وغيرها من وسائل الراحة
وظائف أيضا. على سبيل المثال، الدعوة Skip_commit "$ @" سوف يترك التيار
الالتزام (ولكن ليس تغييراته! إذا كنت تريد ذلك، استخدم طائرة نفاثة rebase في حين أن).

يمكنك أيضًا استخدام git_commit_non_empty_tree "$@" بدلاً من git Commit-tree "$@" إذا
أنت لا ترغب في الالتزام مع أحد الوالدين وهذا لا يحدث أي تغيير في
شجرة.

--tag-name-filter
هذا هو عامل التصفية لإعادة كتابة أسماء العلامات. عند اجتيازه، سيتم استدعاؤه لكل
مرجع العلامة الذي يشير إلى كائن تمت إعادة كتابته (أو إلى كائن علامة يشير إلى كائن
كائن إعادة كتابته). يتم تمرير اسم العلامة الأصلي عبر الإدخال القياسي، والعلامة الجديدة
الاسم متوقع على الإخراج القياسي.

لا يتم حذف العلامات الأصلية، ولكن يمكن الكتابة فوقها؛ استخدم "--tag-name-filter cat"
لتحديث العلامات ببساطة. في هذه الحالة، كن حذرًا للغاية وتأكد من حصولك على
يتم الاحتفاظ بنسخة احتياطية من العلامات القديمة في حالة فشل التحويل.

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

--مرشح الدليل الفرعي
انظر فقط إلى السجل الذي يمس الدليل الفرعي المحدد. سوف تحتوي النتيجة
هذا الدليل (وهذا فقط) هو جذر المشروع الخاص به. يتضمن القسم المسمى "Remap
إلى الجد".

- فارغة
ستؤدي بعض أنواع المرشحات إلى إنشاء التزامات فارغة، مما يترك الشجرة دون تغيير. هذا
التبديل يسمح لـ git-filter-branch بتجاهل مثل هذه الالتزامات. رغم ذلك، هذا التبديل فقط
ينطبق على الالتزامات التي لها والد واحد فقط، وبالتالي ستستمر عمليات الدمج
نقاط. كما أن هذا الخيار غير متوافق مع استخدام --commit-filter. رغم أن
تحتاج فقط إلى استخدام الوظيفة git_commit_non_empty_tree "$ @" بدلا من البوابة
مصطلح شجرة الالتزام "$@" في مرشح الالتزام الخاص بك لتحقيق ذلك.

--إبداعي
استخدم هذا الخيار لتعيين مساحة الاسم حيث سيتم تخزين الالتزامات الأصلية. ال
القيمة الافتراضية هي المراجع / أصلي.

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

-f ، - القوة
طائرة نفاثة فرع التصفية يرفض البدء بدليل مؤقت موجود أو عندما يكون هناك
هي بالفعل مراجع تبدأ بـ المراجع/الأصلي/، إلا إذا اضطر.

...
الحجج ل طائرة نفاثة قائمة المراجعة. تتم إعادة كتابة كافة المراجع الإيجابية التي تتضمنها هذه الخيارات.
يمكنك أيضًا تحديد خيارات مثل --الكل، ولكن يجب عليك استخدام -- لفصلهم عن
ال طائرة نفاثة فرع التصفية خيارات. يتضمن القسم المسمى "إعادة رسم خريطة للسلف".

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

أمثلة

لنفترض أنك تريد إزالة ملف (يحتوي على معلومات سرية أو حقوق الطبع والنشر
انتهاك) من جميع الالتزامات:

git filter-branch --tree-filter 'rm filename' HEAD

ومع ذلك، إذا كان الملف غائبًا عن شجرة بعض الالتزامات، فسيظهر اسم ملف rm بسيط
تفشل لتلك الشجرة والالتزام. وبالتالي قد ترغب بدلاً من ذلك في استخدام اسم الملف rm -f كملف
النصي.

باستخدام --index-filter مع طائرة نفاثة rm ينتج نسخة أسرع بكثير. كما هو الحال مع استخدام rm
filename, git rm --cached filename سوف يفشل إذا كان الملف غائبًا عن شجرة a
يقترف. إذا كنت تريد "نسيان الملف تمامًا"، فلا يهم متى تم إدخاله
التاريخ، لذلك نضيف أيضًا --ignore-unmatch:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

الآن، سوف تحصل على التاريخ المعاد كتابته محفوظًا في HEAD.

لإعادة كتابة المستودع ليبدو كما لو كان foodir/ هو جذر المشروع الخاص به، وتجاهل كل شيء
تاريخ آخر:

git filter-branch --subdirectory-filter foodir -- --all

وبالتالي، يمكنك، على سبيل المثال، تحويل دليل فرعي للمكتبة إلى مستودع خاص بها. لاحظ ال --
الذي يفصل فرع التصفية خيارات من خيارات المراجعة، و--all لإعادة كتابة الكل
الفروع والعلامات.

لتعيين التزام (والذي يكون عادةً على طرف سجل آخر) ليكون أصل ملف
الالتزام الأولي الحالي، للصق السجل الآخر خلف السجل الحالي:

git filter-branch --parent-filter 'sed "s/^\$/-p /"' رأس

(إذا كانت السلسلة الأصلية فارغة - وهو ما يحدث عندما نتعامل مع الالتزام الأولي
- إضافة graftcommit كأحد الوالدين). لاحظ أن هذا يفترض التاريخ بجذر واحد (ذلك
هو أنه لم يحدث أي دمج بدون أسلاف مشتركين). إذا لم يكن الأمر كذلك، استخدم:

git filter-branch --parent-filter \
'اختبار $GIT_COMMIT = && صدى "-ص " || رأس القطة

أو حتى أبسط:

صدى "$commit-id $graft-id" >> .git/info/grafts
git filter-branch $graft-id..HEAD

لإزالة الالتزامات التي كتبها "Darl McBribe" من السجل:

فرع مرشح بوابة - عامل تصفية الالتزام "
إذا [ "$GIT_AUTHOR_NAME" = "دارل مكبريبي" ];
then
Skip_commit "$@";
آخر
شجرة الالتزام git "$@";
رأس فاي

وظيفة Skip_commit يعرف على النحو التالي:

Skip_commit()
{
يحول؛
بينما [ -n "$1" ]؛
do
يحول؛
الخريطة "$1";
يحول؛
منتهي؛
}

يقوم سحر التحول أولاً برمي معرف الشجرة ثم المعلمات -p. لاحظ أن هذا
يعالج الدمج بشكل صحيح! في حالة قيام دارل بالدمج بين P1 وP2، فسيتم ذلك
تم نشره بشكل صحيح وسيصبح كافة توابع الدمج عمليات دمج مع P1 وP2 كـ
والديهم بدلا من الالتزام بالدمج.

ملحوظة التغييرات التي أدخلتها الالتزامات، والتي لا يمكن التراجع عنها لاحقًا
يرتكب، سيظل في الفرع المعاد كتابته. إذا كنت تريد التخلص منها التغييرات سويا
مع الالتزامات، يجب عليك استخدام الوضع التفاعلي لـ طائرة نفاثة rebase.

يمكنك إعادة كتابة رسائل سجل الالتزام باستخدام --msg-filter. على سبيل المثال، طائرة نفاثة معرف svn
سلاسل في مستودع تم إنشاؤه بواسطة طائرة نفاثة إس يمكن إزالتها بهذه الطريقة:

بوابة عامل التصفية --msg-filter '
سيد -e "/^git-svn-id:/d"
'

إذا كنت بحاجة إلى إضافة معتمد من قبل سطور، على سبيل المثال، لآخر 10 عمليات تنفيذ (ليس أي منها عبارة عن دمج)،
استخدم هذا الأمر:

بوابة عامل التصفية --msg-filter '
قطة &&
صدى "Acked-by: Bugs Bunny[البريد الإلكتروني محمي]>"
'الرأس~10..الرأس

يمكن استخدام خيار --env-filter لتعديل هوية المُرسِل و/أو هوية المؤلف. ل
على سبيل المثال، إذا اكتشفت أن التزاماتك لها هوية خاطئة بسبب تكوين خاطئ
user.email، يمكنك إجراء التصحيح، قبل نشر المشروع، مثل هذا:

بوابة مرشح الفرع --env-filter '
إذا كان الاختبار "$GIT_AUTHOR_EMAIL" = "root@localhost"
then
GIT_AUTHOR_EMAIL=[البريد الإلكتروني محمي]
تصدير GIT_AUTHOR_EMAIL
fi
إذا كان الاختبار "$GIT_COMMITTER_EMAIL" = "root@localhost"
then
GIT_COMMITTER_EMAIL=[البريد الإلكتروني محمي]
تصدير GIT_COMMITTER_EMAIL
fi
' -- --الجميع

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

تأمل هذا التاريخ:

د--ه--ف--ز--ح
/ /
أ--ب-----ج

لإعادة كتابة الالتزامات D وE وF وG وH فقط، مع ترك A وB وC بمفردها، استخدم:

فرع مرشح git ... C..H

لإعادة كتابة الالتزامات E،F،G،H، استخدم واحدًا مما يلي:

فرع مرشح git ... C..H --وليس D
فرع مرشح git ... D..H --وليس C

لنقل الشجرة بأكملها إلى دليل فرعي، أو إزالتها من هناك:

git filter-branch --index-filter \
'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
بوابة تحديث الفهرس --معلومات الفهرس &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD

قائمة مراجعة لأي يتقلص A مخزن

يمكن استخدام git-filter-branch للتخلص من مجموعة فرعية من الملفات، عادةً مع بعضها
مزيج من --index-filter و --subdirectory-filter. الناس يتوقعون النتيجة
أن يكون المستودع أصغر من المستودع الأصلي، لكنك تحتاج إلى بضع خطوات إضافية لإتمامه فعليًا
إنه أصغر حجمًا، لأن Git يحاول جاهدًا ألا يفقد العناصر الخاصة بك حتى تطلب منه ذلك. أولاً
تأكد من أن:

· لقد قمت بالفعل بإزالة جميع أشكال اسم الملف، إذا تم نقل النقطة على مدى عمرها.
يمكن أن يساعدك git log --name-only --follow --all -- filename في العثور على عمليات إعادة التسمية.

· لقد قمت بالفعل بتصفية جميع المراجع: استخدم --tag-name-filter cat -- --all عند الاتصال
git-filter-branch.

ثم هناك طريقتان للحصول على مستودع أصغر. الطريقة الأكثر أمانًا هي الاستنساخ، وهذا ما يحافظ عليه
الأصلي الخاص بك سليمة.

· استنساخه باستخدام ملف git clone::///path/to/repo. لن تتم إزالة الاستنساخ
أشياء. يرى استنساخ بوابة(1). (لاحظ أن الاستنساخ بمسار عادي هو مجرد روابط صلبة
كل شئ!)

إذا كنت لا ترغب حقًا في استنساخه، لأي سبب كان، فتحقق من النقاط التالية
بدلاً من ذلك (بهذا الترتيب). وهذا نهج مدمر للغاية، لذلك جعل a دعم أو العودة
لاستنساخه. لقد تم تحذيرك.

· قم بإزالة المراجع الأصلية المدعومة بفرع git-filter: قل git for-each-ref
--format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d.

· انتهاء صلاحية كافة عمليات إعادة التسجيل باستخدام git reflog انتهاء الصلاحية --expire=now --all.

· قم بجمع كافة الكائنات غير المشار إليها باستخدام git gc --Prune=now (أو إذا كان git-gc لديك
ليست جديدة بما يكفي لدعم وسيطات --Prune، استخدم git repack -ad؛ git Prune
في حين أن).

الملاحظات

يتيح لك git-filter-branch إجراء عمليات إعادة كتابة معقدة لسجل Git الخاص بك باستخدام نصوص برمجية shell،
لكن ربما لا تحتاج إلى هذه المرونة إذا كنت ببساطة إزالة غير مرغوب فيه البيانات مثل
الملفات الكبيرة أو كلمات المرور. بالنسبة لتلك العمليات التي قد ترغب في النظر فيها • بفغ
منظف ​​الريبو[1]، بديل يستند إلى JVM لـ git-filter-branch، عادةً ما لا يقل عن 10-50x
أسرع بالنسبة لحالات الاستخدام تلك، وبخصائص مختلفة تمامًا:

· يتم تنظيف أي نسخة معينة من الملف تمامًا مرة. BFG، على عكس
لا يمنحك git-filter-branch الفرصة للتعامل مع الملف بشكل مختلف
بناءً على مكان أو وقت ارتكابها في تاريخك. هذا القيد يعطي
فائدة الأداء الأساسية لـ BFG، وهي مناسبة تمامًا لمهمة التطهير السيئة
البيانات - لا يهمك أين البيانات السيئة هي أنك تريد ذلك فقط ذهب.

· بشكل افتراضي، يستفيد BFG بشكل كامل من الأجهزة متعددة النواة، ويلتزم بالتطهير
أشجار الملفات بالتوازي. يتم تنفيذ عمليات تنظيف git-filter-branch بشكل تسلسلي (على سبيل المثال في ملف
بطريقة واحدة مترابطة)، على الرغم من ذلك is ممكن لكتابة المرشحات التي تشمل خاصة بهم
التوازي، في البرامج النصية التي يتم تنفيذها مقابل كل التزام.

· ال أمر الخيارات[2] أكثر تقييدًا بكثير من فرع git-filter، ومخصصة
فقط لمهام إزالة البيانات غير المرغوب فيها - على سبيل المثال: --strip-blobs-أكبر من 1M.

GIT

جزء من طائرة نفاثة(1) جناح

الملاحظات

1. منظف BFG Repo
http://rtyley.github.io/bfg-repo-cleaner/

2. خيارات الأمر
http://rtyley.github.io/bfg-repo-cleaner/#أمثلة

استخدم git-filter-branch عبر الإنترنت باستخدام خدمات onworks.net