-
1. شروع به کار
- 1.1 دربارهٔ کنترل نسخه
- 1.2 تاریخچهٔ کوتاهی از گیت
- 1.3 گیت چیست؟
- 1.4 خط فرمان
- 1.5 نصب گیت
- 1.6 اولین راه‌اندازی گیت
- 1.7 کمک گرفتن
- 1.8 خلاصه
-
2. مقدمات گیت
- 2.1 دستیابی به یک مخزن گیت
- 2.2 ثبت تغییرات در مخزن
- 2.3 دیدن تاریخچهٔ کامیتها
- 2.4 بازگردانی کارها
- 2.5 کار با ریموتها
- 2.6 برچسبگذاری
- 2.7 نامهای مستعار در گیت
- 2.8 خلاصه
-
3. شاخه‌سازی در گیت
- 3.1 شاخهها در یک کلمه
- 3.2 شاخه‌سازی و ادغام مقدماتی
- 3.3 مدیریت شاخه
- 3.4 روند کاری شاخه‌سازی
- 3.5 شاخههای ریموت
- 3.6 ریبیسکردن
- 3.7 خلاصه
-
4. گیت روی سرور
- 4.1 پروتکلها
- 4.2 راه‌اندازی گیت در سرور
- 4.3 ساختن کلید عمومی SSH
- 4.4 نصب و راه‌اندازی سرور
- 4.5 دیمن گیت
- 4.6 HTTP هوشمند
- 4.7 گیتوب
- 4.8 گیتلب
- 4.9 گزینه‌های شخصی ثالث میزبانی شده
- 4.10 خلاصه
-
5. گیت توزیع‌شده
- 5.1 روندهای کاری توزیع‌شده
- 5.2 مشارکت در یک پروژه
- 5.3 نگهداری یک پروژه
- 5.4 خلاصه
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
8.2 Customizing Git (سفارشی‌سازی Git) - Git Attributes (ویژگی‌های گیت)
Git Attributes (ویژگی‌های گیت)
برخی از این تنظیمات را می‌توان برای یک مسیر خاص نیز مشخص کرد، به‌طوری که گیت این تنظیمات را فقط برای یک زیرپوشه یا مجموعه‌ای از فایل‌ها اعمال کند. این تنظیمات خاص مسیر به عنوان ویژگی‌های گیت شناخته می‌شوند و یا در یک فایل .gitattributes در یکی از پوشه‌های شما (معمولاً ریشه پروژه‌تان) تنظیم می‌شوند، یا در فایل .git/info/attributes اگر نمی‌خواهید فایل ویژگی‌ها همراه با پروژه‌تان در مخزن ثبت (commit) شود.
با استفاده از ویژگی‌ها، می‌توانید کارهایی مانند مشخص کردن استراتژی‌های ادغام (merge) جداگانه برای فایل‌ها یا پوشه‌های خاص در پروژه‌تان انجام دهید، به گیت بگویید چگونه فایل‌های غیرمتنی را مقایسه (diff) کند، یا گیت را وادار کنید که محتوا را قبل از ثبت کردن یا بیرون کشیدن از مخزن فیلتر کند. در این بخش، درباره برخی از ویژگی‌هایی که می‌توانید روی مسیرهای پروژه گیت خود تنظیم کنید یاد خواهید گرفت و چند مثال عملی از استفاده از این قابلیت را خواهید دید. ==== فایل‌های باینری
یک ترفند جالب که می‌توانید از ویژگی‌های گیت برای آن استفاده کنید، این است که به گیت بگویید کدام فایل‌ها باینری هستند (در مواردی که ممکن است خودش نتواند تشخیص دهد) و دستورالعمل‌های خاصی برای نحوه برخورد با آن فایل‌ها به گیت بدهید.
برای مثال، برخی فایل‌های متنی ممکن است توسط ماشین تولید شده باشند و قابل مقایسه (diff) نباشند، در حالی که بعضی فایل‌های باینری می‌توانند مقایسه شوند.
در اینجا خواهید دید که چگونه به گیت بگویید کدام فایل از کدام نوع است.
Identifying Binary Files (شناسایی فایل‌های باینری)
برخی فایل‌ها به نظر می‌رسند که فایل‌های متنی هستند، اما از هر نظر باید به‌عنوان داده‌های باینری در نظر گرفته شوند.
برای مثال، پروژه‌های Xcode در macOS شامل فایلی هستند که به .pbxproj ختم می‌شود. این فایل در واقع یک مجموعه داده JSON (فرمت داده جاوااسکریپت متنی ساده) است که توسط محیط توسعه (IDE) روی دیسک نوشته شده و تنظیمات ساخت پروژه و موارد مشابه را ثبت می‌کند.
اگرچه از نظر فنی یک فایل متنی است (چون تماماً UTF-8 است)، اما نمی‌خواهید آن را به‌عنوان فایل متنی معمولی در نظر بگیرید، زیرا در واقع یک پایگاه داده سبک است – اگر دو نفر آن را تغییر دهند، نمی‌توانید محتوای آن را ادغام (merge) کنید و مقایسه‌ها (diff) معمولاً مفید نیستند.
این فایل برای استفاده توسط ماشین طراحی شده است.
در حقیقت، شما می‌خواهید آن را مثل یک فایل باینری behand کنید.
برای اینکه به گیت بگویید همه فایل‌های pbxproj را به‌عنوان داده‌های باینری در نظر بگیرد، خط زیر را به فایل .gitattributes خود اضافه کنید:
*.pbxproj binaryحالا گیت دیگر سعی نمی‌کند مسائل مربوط به CRLF را تبدیل یا اصلاح کند؛ همچنین هنگام اجرای git show یا git diff در پروژه‌تان، برای تغییرات این فایل، مقایسه‌ای (diff) محاسبه یا چاپ نخواهد کرد.
Diffing Binary Files (مقایسه فایل‌های باینری)
شما همچنین می‌توانید از قابلیت ویژگی‌های گیت برای مقایسه مؤثر فایل‌های باینری استفاده کنید.
این کار را با گفتن به گیت انجام می‌دهید که چگونه داده‌های باینری شما را به یک فرمت متنی تبدیل کند که بتوان آن را از طریق مقایسه معمولی (diff) بررسی کرد.
ابتدا، از این تکنیک برای حل یکی از آزاردهنده‌ترین مشکلات شناخته‌شده برای بشریت استفاده خواهید کرد: کنترل نسخه اسناد مایکروسافت ورد.
همه می‌دانند که ورد وحشتناک‌ترین ویرایشگر موجود است، اما عجیب اینکه هنوز همه از آن استفاده می‌کنند.
اگر بخواهید اسناد ورد را کنترل نسخه کنید، می‌توانید آن‌ها را در یک مخزن گیت قرار دهید و هر از گاهی آن‌ها را ثبت (commit) کنید؛ اما این چه فایده‌ای دارد؟
اگر به‌طور عادی git diff را اجرا کنید، فقط چیزی شبیه این خواهید دید:
$ git diff
diff --git a/chapter1.docx b/chapter1.docx
index 88839c4..4afcb7c 100644
Binary files a/chapter1.docx and b/chapter1.docx differشما نمی‌توانید مستقیماً دو نسخه را مقایسه کنید، مگر اینکه آن‌ها را بیرون بکشید و به‌صورت دستی بررسی کنید، درست است؟
معلوم می‌شود که با استفاده از ویژگی‌های گیت می‌توانید این کار را به‌خوبی انجام دهید.
خط زیر را در فایل .gitattributes خود قرار دهید:
*.docx diff=wordاین به گیت می‌گوید که هر فایلی که با این الگو مطابقت دارد (.docx) باید از فیلتر "word" استفاده
کند زمانی که شما سعی می‌کنید تفاوت‌هایی را مشاهده کنید که شامل تغییرات است.
فیلتر "word" چیست؟
شما باید آن را تنظیم کنید.
در اینجا شما گیت را پیکربندی می‌کنید تا از برنامه docx2txt برای تبدیل اسناد Word به فایل‌های متنی
قابل خواندن استفاده کند، که سپس به درستی مقایسه می‌شوند.
ابتدا، باید docx2txt را نصب کنید؛ می‌توانید آن را از https://sourceforge.net/projects/docx2txt دانلود کنید.
دستورالعمل‌های موجود در فایل INSTALL را دنبال کنید تا آن را در جایی قرار دهید که شِل شما بتواند آن را پیدا کند.
سپس، یک اسکریپت پوششی (wrapper script) خواهید نوشت تا خروجی را به فرمتی که گیت انتظار دارد تبدیل کند.
فایلی به نام docx2txt در جایی از مسیر خود ایجاد کنید و این محتوا را به آن اضافه کنید:
#!/bin/bash
docx2txt.pl "$1" -فراموش نکنید که به آن فایل chmod a+x بدهید.
در نهایت، می‌توانید گیت را پیکربندی کنید تا از این اسکریپت استفاده کند:
$ git config diff.word.textconv docx2txtحالا گیت می‌داند که اگر بخواهد بین دو نسخه (snapshot) مقایسه‌ای (diff) انجام دهد و برخی از فایل‌ها به .docx ختم شوند، باید آن فایل‌ها را از طریق فیلتر “word” اجرا کند، که به‌عنوان برنامه docx2txt تعریف شده است.
این کار به‌طور مؤثری نسخه‌های متنی خوبی از فایل‌های ورد شما ایجاد می‌کند قبل از اینکه بخواهد آن‌ها را مقایسه (diff) کند.
اینجا یک مثال آورده شده است: فصل اول این کتاب به فرمت ورد تبدیل شده و در یک مخزن گیت ثبت (commit) شده است.
سپس یک پاراگراف جدید به آن اضافه شد.
این چیزی است که git diff نشان می‌دهد:
$ git diff
diff --git a/chapter1.docx b/chapter1.docx
index 0b013ca..ba25db5 100644
--- a/chapter1.docx
+++ b/chapter1.docx
@@ -2,6 +2,7 @@
این فصل درباره شروع به کار با گیت خواهد بود. ما با توضیح برخی از زمینه‌ها در مورد ابزارهای کنترل نسخه شروع خواهیم کرد، سپس به نحوه راه‌اندازی گیت در سیستم شما و در نهایت نحوه تنظیم آن برای شروع کار خواهیم پرداخت. در پایان این فصل شما باید درک کنید که چرا گیت وجود دارد، چرا باید از آن استفاده کنید و باید به طور کامل آماده باشید تا این کار را انجام دهید.
1.1. درباره کنترل نسخه
کنترل نسخه چیست و چرا باید به آن اهمیت دهید؟ کنترل نسخه سیستمی است که تغییرات را در یک فایل یا مجموعه‌ای از فایل‌ها در طول زمان ثبت می‌کند تا بتوانید نسخه‌های خاصی را بعداً به یاد بیاورید. برای مثال‌ها در این کتاب، شما از کد منبع نرم‌افزار به عنوان فایل‌های تحت کنترل نسخه استفاده خواهید کرد، اگرچه در واقع می‌توانید این کار را با تقریباً هر نوع فایلی در یک کامپیوتر انجام دهید.
+آزمایش: 1، 2، 3.
اگر شما یک طراح گرافیک یا وب هستید و می‌خواهید هر نسخه از یک تصویر یا طرح را نگه دارید (که قطعاً می‌خواهید)، استفاده از یک سیستم کنترل نسخه (VCS) بسیار عاقلانه است. این به شما اجازه می‌دهد تا فایل‌ها را به حالت قبلی برگردانید، کل پروژه را به حالت قبلی برگردانید، تغییرات را در طول زمان مقایسه کنید، ببینید چه کسی آخرین بار چیزی را تغییر داده که ممکن است باعث ایجاد مشکل شود، چه کسی یک مشکل را معرفی کرده و چه زمانی، و بیشتر. استفاده از یک VCS همچنین به طور کلی به این معنی است که اگر چیزها را خراب کنید یا فایل‌ها را گم کنید، می‌توانید به راحتی آن‌ها را بازیابی کنید. علاوه بر این، شما تمام این‌ها را با هزینه بسیار کمی دریافت می‌کنید.
1.1.1. سیستم‌های کنترل نسخه محلی
روش کنترل نسخه انتخابی بسیاری از مردم این است که فایل‌ها را به یک دایرکتوری دیگر کپی کنند (شاید یک دایرکتوری با زمان‌مهر، اگر آن‌ها باهوش باشند). این رویکرد بسیار رایج است زیرا بسیار ساده است، اما همچنین به شدت مستعد خطاست. به راحتی می‌توان فراموش کرد که در کدام دایرکتوری هستید و به طور تصادفی به فایل اشتباهی بنویسید یا فایل‌هایی را که نمی‌خواهید کپی کنید.گیت به طور موفقیت‌آمیز و مختصر به ما می‌گوید که رشته "آزمایش: 1، 2، 3." را اضافه کرده‌ایم، که درست است. این کامل نیست – تغییرات فرمت در اینجا نشان داده نمی‌شوند – اما قطعاً کار می‌کند.
یک مشکل جالب دیگر که می‌توانید اینگونه حل کنید، مقایسه فایل‌های تصویری است.
یک راه برای انجام این کار این است که فایل‌های تصویری را از طریق یک فیلتر که اطلاعات EXIF آن‌ها را استخراج
می‌کند، اجرا کنید – متاداده‌ای که با اکثر فرمت‌های تصویری ثبت می‌شود.
اگر شما برنامه exiftool را دانلود و نصب کنید، می‌توانید از آن برای تبدیل تصاویر خود به متن درباره
متاداده استفاده کنید، بنابراین حداقل تفاوت‌ها نمایشی متنی از هر تغییری که اتفاق افتاده است را نشان می‌دهد.
خط زیر را در فایل .gitattributes خود قرار دهید:
*.png diff=exifگیت را پیکربندی کنید تا از این ابزار استفاده کند:
$ git config diff.exif.textconv exiftoolاگر شما یک تصویر را در پروژه خود جایگزین کنید و git diff را اجرا کنید، چیزی شبیه به این را
خواهید دید:
diff --git a/image.png b/image.png
index 88839c4..4afcb7c 100644
--- a/image.png
+++ b/image.png
@@ -1,12 +1,12 @@
ExifTool Version Number : 7.74
-File Size : 70 kB
-File Modification Date/Time : 2009:04:21 07:02:45-07:00
+File Size : 94 kB
+File Modification Date/Time : 2009:04:21 07:02:43-07:00
File Type : PNG
MIME Type : image/png
-Image Width : 1058
-Image Height : 889
+Image Width : 1056
+Image Height : 827
Bit Depth : 8
Color Type : RGB with Alphaشما به راحتی می‌توانید ببینید که اندازه فایل و ابعاد تصویر هر دو تغییر کرده‌اند.
Keyword Expansion (گسترش کلیدواژه)
گسترش کلیدواژه به سبک SVN یا CVS اغلب توسط توسعه‌دهندگانی که به آن سیستم‌ها عادت دارند درخواست می‌شود. مشکل اصلی با این در گیت این است که شما نمی‌توانید فایلی را با اطلاعات مربوط به کامیت پس از اینکه کامیت کرده‌اید، تغییر دهید، زیرا گیت ابتدا checksum فایل را بررسی می‌کند. با این حال، شما می‌توانید متن را هنگام چک‌اوت به یک فایل تزریق کنید و قبل از اینکه دوباره به یک کامیت اضافه شود، آن را حذف کنید. ویژگی‌های گیت به شما دو روش برای انجام این کار ارائه می‌دهد.
اول، شما می‌توانید checksum SHA-1 یک blob را به یک فیلد $Id$ در فایل به طور خودکار تزریق کنید.
اگر این ویژگی را بر روی یک فایل یا مجموعه‌ای از فایل‌ها تنظیم کنید، سپس دفعه بعد که این شاخه را چک‌اوت کنید، گیت
آن فیلد را با SHA-1 blob جایگزین می‌کند.
مهم است که توجه داشته باشید که این SHA-1 مربوط به کامیت نیست، بلکه مربوط به خود blob است.
خط زیر را در فایل .gitattributes خود قرار دهید:
*.txt identیک مرجع $Id$ به یک فایل آزمایشی اضافه کنید:
$ echo '$Id$' > test.txtدفعه بعد که این فایل را بررسی (checkout) می‌کنید، Git مقدار SHA-1 مربوط به blob را در آن قرار می‌دهد:
$ rm test.txt
$ git checkout -- test.txt
$ cat test.txt
$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $با این حال، این نتیجه کاربرد محدودی دارد. اگر از keyword substitution در CVS یا Subversion استفاده کرده باشید، می‌دانید که می‌توانستید یک datestamp درج کنید – اما SHA-1 چندان مفید نیست، چون نسبتاً تصادفی است و فقط با نگاه کردن به آن نمی‌توانید تشخیص دهید که یک SHA-1 قدیمی‌تر است یا جدیدتر.
جالب اینجاست که می‌توانید فیلترهای خودتان را برای انجام جایگزینی‌ها روی فایل‌ها هنگام commit/checkout بنویسید.
به این فیلترها clean و smudge گفته می‌شود.
در فایل .gitattributes می‌توانید یک filter برای مسیرهای خاص تعریف کنید و سپس اسکریپت‌هایی تنظیم کنید که فایل‌ها را درست قبل از اینکه checkout شوند (smudge، مراجعه کنید به فیلتر "smudge" در زمان چک‌اوت اجرا می‌شود.) و درست قبل از اینکه staged شوند (clean، مراجعه کنید به فیلتر "clean" در زمان staging اجرا می‌شود.) پردازش کنند.
این فیلترها می‌توانند برای انجام کلی کار جالب تنظیم شوند.
پیام کامیت اصلی برای این ویژگی یک مثال ساده از اجرای تمام کدهای منبع C از طریق برنامه indent قبل
از کامیت را ارائه می‌دهد.
شما می‌توانید این را با تنظیم ویژگی فیلتر در فایل .gitattributes برای فیلتر *.c با
فیلتر "indent" تنظیم کنید:
*.c filter=indentسپس، به گیت بگویید که فیلتر "indent" چه کاری در زمان smudge و clean انجام می‌دهد:
$ git config --global filter.indent.clean indent
$ git config --global filter.indent.smudge catدر این حالت، زمانی که فایل‌هایی با الگوی *.c را commit می‌کنید، Git آن‌ها را پیش از stage شدن از طریق برنامه indent عبور می‌دهد، و سپس قبل از اینکه دوباره آن‌ها را روی دیسک checkout کند، از طریق برنامه cat عبور می‌دهد.
برنامه cat در اصل هیچ کاری انجام نمی‌دهد: هر داده‌ای که دریافت می‌کند را همان‌طور خارج می‌کند.
این ترکیب باعث می‌شود که تمام فایل‌های سورس C پیش از commit شدن از فیلتر indent عبور کنند.
یک مثال جالب دیگر مربوط به گسترش کلیدواژه $Date$ به سبک RCS است.
برای اینکه این کار به‌درستی انجام شود، به یک اسکریپت کوچک نیاز دارید که یک نام فایل را دریافت کند، تاریخ آخرین commit پروژه را تشخیص دهد و آن تاریخ را در فایل وارد کند.
در ادامه، یک اسکریپت کوچک Ruby آمده است که این کار را انجام می‌دهد:
#! /usr/bin/env ruby
data = STDIN.read
last_date = `git log --pretty=format:"%ad" -1`
puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')تمام کاری که این اسکریپت انجام می‌دهد این است که تاریخ آخرین commit را از دستور git log دریافت می‌کند، آن را در هر رشته‌ی $Date$ که در stdin می‌بیند جایگذاری می‌کند، و نتیجه را چاپ می‌کند — پیاده‌سازی آن در هر زبانی که با آن راحت هستید باید ساده باشد.
می‌توانید این فایل را با نام expand_date ذخیره کرده و آن را در مسیر (path) سیستم خود قرار دهید.
حالا باید یک فیلتر در Git تنظیم کنید (که مثلاً dater نام دارد) و به آن بگویید هنگام checkout فایل‌ها از فیلتر expand_date برای smudge کردن استفاده کند.
برای clean کردن هنگام commit نیز از یک عبارت Perl استفاده خواهید کرد تا آن قسمت را پاک‌سازی کند:
$ git config filter.dater.smudge expand_date
$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'این قطعه کد Perl، هر چیزی را که در رشته‌ی $Date$ ببیند حذف می‌کند، تا فایل را به حالت اولیه‌اش برگرداند.
حالا که فیلترتان آماده است، می‌توانید آن را با تنظیم یک ویژگی (attribute) در Git برای آن فایل آزمایش کنید؛ ویژگی‌ای که فیلتر جدید را فعال می‌کند، و فایلی بسازید که شامل کلیدواژه‌ی $Date$ باشد:
date*.txt filter=dater$ echo '# $Date$' > date_test.txtاگر شما آن تغییرات را کامیت کنید و دوباره فایل را چک‌اوت کنید، می‌بینید که کلیدواژه به درستی جایگزین شده است:
$ git add date_test.txt .gitattributes
$ git commit -m "Test date expansion in Git"
$ rm date_test.txt
$ git checkout date_test.txt
$ cat date_test.txt
# $Date: Tue Apr 21 07:26:52 2009 -0700$می‌توانید ببینید که این تکنیک چقدر برای کاربردهای سفارشی‌سازی‌شده قدرتمند است.
با این حال، باید مراقب باشید؛ چون فایل .gitattributes در ریپازیتوری commit می‌شود و همراه با پروژه منتقل می‌گردد، اما driver (در این مثال، dater) چنین نیست، بنابراین ممکن است فیلتر در همه‌جا کار نکند.
زمانی که این فیلترها را طراحی می‌کنید، باید طوری باشند که در صورت عدم وجود یا بروز خطا، به‌صورت «شکست محترمانه» (fail gracefully) عمل کنند و پروژه همچنان بدون مشکل اجرا شود.
Exporting Your Repository (خروجی گرفتن از ریپازیتوری)
اطلاعات ویژگی‌های Git (Git attribute data) همچنین به شما این امکان را می‌دهد که هنگام export گرفتن یک آرشیو از پروژه‌تان، کارهای جالبی انجام دهید.
export-ignore
شما می‌توانید به Git بگویید که هنگام تولید یک آرشیو، برخی فایل‌ها یا دایرکتوری‌ها را صادر نکند. اگر دایرکتوری یا فایلی وجود دارد که نمی‌خواهید در آرشیو پروژه‌تان گنجانده شود، ولی می‌خواهید آن را در پروژه‌تان commit کنید، می‌توانید با استفاده از ویژگی export-ignore این فایل‌ها را مشخص کنید.
برای مثال، فرض کنید که برخی فایل‌های تست در دایرکتوری test/ دارید و نیازی به گنجاندن آن‌ها در آرشیو tarball پروژه‌تان ندارید. شما می‌توانید خط زیر را به فایل ویژگی‌های Git خود اضافه کنید:
test/ export-ignoreاکنون، زمانی که شما git archive را اجرا می‌کنید تا یک tarball از پروژه خود ایجاد کنید، آن
دایرکتوری در آرشیو گنجانده نخواهد شد.
export-subst
هنگام صادرات فایل‌ها برای استقرار، می‌توانید پردازش فرمت‌دهی و گسترش کلیدواژه‌های git log را به
بخش‌های انتخاب شده از فایل‌ها که با ویژگی export-subst علامت‌گذاری شده‌اند، اعمال کنید.
به عنوان مثال، اگر می‌خواهید فایلی به نام LAST_COMMIT را در پروژه خود شامل کنید و اطلاعات
متاداده درباره آخرین کامیت به طور خودکار در آن وارد شود زمانی که git archive اجرا می‌شود،
می‌توانید به عنوان مثال فایل‌های .gitattributes و LAST_COMMIT خود را به این صورت
تنظیم کنید:
LAST_COMMIT export-subst$ echo 'Last commit date: $Format:%cd by %aN$' > LAST_COMMIT
$ git add LAST_COMMIT .gitattributes
$ git commit -am 'adding LAST_COMMIT file for archives'زمانی که شما git archive را اجرا می‌کنید، محتوای فایل آرشیو به این صورت خواهد بود:
$ git archive HEAD | tar xCf ../deployment-testing -
$ cat ../deployment-testing/LAST_COMMIT
Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chaconجایگزینی‌ها می‌توانند شامل به عنوان مثال پیام کامیت و هر git notes باشند و git log
می‌تواند کارهای ساده‌ای مانند خط‌پیچی را انجام دهد:
$ echo '$Format:Last commit: %h by %aN at %cd%n%+w(76,6,9)%B$' > LAST_COMMIT
$ git commit -am 'export-subst uses git log'\''s custom formatter
git archive از پردازشگر pretty=format: git log به طور مستقیم استفاده می‌کند
و علامت‌گذاری محاطی $Format: و $
را از خروجی حذف می‌کند.
'
$ git archive @ | tar xfO - LAST_COMMIT
Last commit: 312ccc8 by Jim Hill at Fri May 8 09:14:04 2015 -0700
export-subst از پردازشگر فرمت‌دهی git log به طور مستقیم استفاده می‌کند
و علامت‌گذاری محاطی $Format: و $
را از خروجی حذف می‌کند.آرشیو حاصل برای کارهای استقرار مناسب است، اما مانند هر آرشیو صادراتی برای کارهای توسعه‌ای مناسب نیست.
Merge Strategies (استراتژی ادغام)
شما همچنین می‌توانید از ویژگی‌های Git برای این استفاده کنید که به Git بگویید از استراتژی‌های ادغام مختلف برای فایل‌های خاص در پروژه‌تان استفاده کند. یکی از گزینه‌های بسیار مفید این است که به Git بگویید که هنگام بروز تضاد (conflict)، سعی نکند فایل‌های خاصی را ادغام کند، بلکه به‌جای آن از نسخه‌ی خودتان استفاده کند.
این گزینه مفید است اگر یک شاخه در پروژه‌تان انشعاب پیدا کرده یا تخصصی شده باشد، ولی می‌خواهید تغییرات آن را دوباره ادغام کنید و برخی فایل‌ها را نادیده بگیرید. فرض کنید شما یک فایل تنظیمات پایگاه داده به نام database.xml دارید که در دو شاخه متفاوت است و می‌خواهید شاخه‌ی دیگر را بدون خراب کردن فایل پایگاه داده ادغام کنید. شما می‌توانید ویژگی‌ای به این شکل تنظیم کنید:
database.xml merge=oursو سپس یک استراتژی ادغام جعلی ours را با:
$ git config --global merge.ours.driver trueاگر شاخه‌ی دیگر را ادغام کنید، به‌جای اینکه تضادهای ادغامی با فایل database.xml مشاهده کنید، چیزی شبیه به این خواهید دید:
$ git merge topic
Auto-merging database.xml
Merge made by recursive.در این حالت، database.xml در هر نسخه‌ای که شما در ابتدا داشتید باقی می‌ماند.
