آموزش گیت – قسمت دوازدهم (آخر)

نویسنده : سید ایوب کوکبی ۲۸ اردیبهشت ۱۳۹۸
آموزش گیت - قسمت دوازدهم (آخر)

در این درس که آخرین درس سری آموزشی گیت است شما را با دستورات متفرقه و کاربردی این سورس کنترل آشنا می‌کنیم. کمی از تئوری فاصله می‌گیریم و به جنبه‌های عملی‌تر گیت همچون آماده‌سازی پروژه برای انتشار و بکاپ‌گیری از مخزن خواهیم پرداخت.

در مطالعۀ درس حاضر سعی نکنید همۀ دستورات را به صورت کامل و با تمامی سوئیچ‌های همراه آن فرا بگیرید چون واقعاً گسترده بوده و ممکن است شما را ناامید کند. همین که بفهمید هدف از ساخت هر دستور چه بوده و کجاها به درد می‎خورد کافی است. بعداً وقتی در موقعیت مشابهی قرار گرفتید به خاطر می‌آورید که از کدام دستور استفاده کنید و آن وقت زمان بررسی عمیق‌تر است.

آرشیو کردن مخزن

به فولدر my-git-repo بروید. با دستور پایین مخزن به شکل یک فایل زیپ ذخیره می‌شود:

git archive master --format=zip --output=../website-12-10-2012.zip

یا برای کاربران یونیکس که فرمت فشردۀ tar را ترجیح می‌دهند:

git archive master --format=tar --output=../website-12-10-2012.tar

دستور بالا تمام فایل‌های موجود در شاخۀ مستر به جز فولدر git. را به شکل zip یا tar ذخیره می‌کند. وجود نداشتن فولدر git. در بکاپ به این معناست که کل تاریخچۀ پروژه حذف شده و تنها چیزی که باقی مانده، یک کپی از فایل‎های موجود در فولدر پروژۀ شماست. شما می‌توانید این فایل را برای مشتریان خود ارسال کنید تا بدون نیاز به نصب گیت در سیستم‌شان تست کنند. در واقع یکی از کاربرد مهم این دستور، ارسال نسخه‌ای از پروژه برای مشتری است. کاربرد مهم دیگر، بکاپ‌گیری از ریویژن یا نسخه‌های مهم پروژه است.

تبدیل مخزن به یک باندل

همانند git archive، دستور git bundle مخزن را به یک فایل تبدیل می‎کند ولی این بار تاریخچۀ کامل پروژه نیز همراه آن ذخیره می‎شود. دستور زیر را اجرا کنید:

git bundle create ../repo.bundle master

این کار شبیه پوش کردن شاخۀ مستر به مخزن ریموت است؛ فقط اینجا به جای مخزن ریموت از یک فایل استفاده کرده‌ایم. ما حتی می‌توانیم از دستور git clone برای کلون کردن مخزن از روی باندل ساخته شده استفاده کنیم:

cd ..
git clone repo.bundle repo-copy -b master
cd repo-copy
git log
cd ../my-git-repo

دستور لاگ باید تاریخچۀ کامل پروژه برای شاخۀ مستر را نشان دهد. در اینجا فایل repo.bundle حکمِ origin را دارد. این کار دقیقاً مثل زمانی است که یک مخزن ریموت را به صورت معمول کلون می‌کردیم. باندل (bundle) کردن راهی عالی برای بکاپ‌گیری کامل از پروژه است. با این دستور حتی بدون اتصال شبکه می‌توانید تغییرات را با همکاران خود به اشتراک بگذارید. کافی است تا فایل باندل را داخل فلش مموری بریزید و به سیستم همکارتان منتقل کنید. در حال حاضر به فایل repo.bundle و فولدر repo-copy نیازی نداریم، می‌توانید حذف‌شان کنید.

نادیده گرفتن یک فایل در گیت

به خاطر دارید که گیت فایل‌های جدید را به صورت خودکار تِرَک (Track) نمی‌کرد چون ممکن است کامپایلر چند صد فایل موقت و باینری ایجاد کند که وجودشان در مخزن و اشتراکشان با دیگران ضرورت ندارد یا اصلاً به لحاظ امنیتی اشتراک‌گذاری برخی از فایل‌ها درست نیست. ولی به هر حال موضوع این است که با زدن دستور git status فهرست همۀ این فایل‌های ترک نشده نمایش داده می‌شود و این موضوع ممکن است در پروژه‌های بزرگ گیج‌کننده شود.

برای حل این مشکل می‌توانید فایلی به نام gitignore. در ریشۀ پروژه بسازید و داخلش فایل‌هایی با نام کامل یا پسوند فایل‌های که نمی‌خواهید دنبال شوند را فهرست کنید. گیت از این پس فایل‌های موجود در gitignore را نادیده می‌گیرد، انگار که اصلاً ندیده است. این فایل‌ها دیگر در دستور git status به عنوان untracked files نمایش داده نمی‌شوند. شما هر تعداد از این فایل‌ها در فولدر پروژه ایجاد کنید گیت آن‌ها را نادیده می‌گیرد و در خروجی دستور git status نمایش نمی‌دهد.

برای فهم بهتر موضوع، فایلی به نام notes.txt بسازید تا کامنت‌هایی دربارۀ پروژه را در خود نگه‌داری کند. متنی به آن اضافه کرده و ذخیره‌اش کنید. حالا وضعیت بگیرید:

git status

طبق انتظار، گیت فایل notes.txt را در بخش untracked files نمایش می‌دهد. حالا فایل بدون پسوندی به نام gitignore. در فولدر my-git-repo بسازید (دقیقاً با همین نام، نقطۀ اول آن هم لازم است) و متن زیر را به آن اضافه کنید. کاربران ویندوز در حالت عادی اجازۀ ساخت چنینی فایلی را ندارند چون ویندوز تصور می‌کند شما فقط پسوند یک فایل را وارد کرده‌اید بدون اینکه نامی برای آن انتخاب کرده باشید.

برای حل این مشکل چند راه وجود دارد: یا بنویسید .gitignore. که بعد از اینتر زدن به صورت خودکار نقطۀ آخری برداشته می‌شود. یا در خط فرمان از دستور echo > .gitignore استفاده کنید یا دستور touch .gitignore را در git bash. وارد کنید (مطمئن شوید که فایل‌های مخفی در حال نمایش باشند).

notes.txt

حالا دوباره git status بزنید. متوجه خواهید شد که دیگر اثری از اسم فایل notes.txt در فهرست untracked filesها نیست. ولی خودِ فایل gitignore. به عنوان یک فایل ترک نشده نمایش داده می‌شود. این فایل در اغلب پروژه‌های مبتنی بر گیت وجود دارد، پس بهتر است آن را به مخزن اضافه کنیم:

git add .gitignore
git commit -m "Add .gitignore file"
git status

شما می‌توانید یک فولدر کامل را هم به فایل gitignore. اضافه کنید یا حتی از wildcard * ها برای نادیده گرفتن دستۀ خاصی از فایل‌ها با پسوندی مشخص استفاده کنید. مثلاً این یک gitignore. رایج در پروژه‌های C است:

*.o
*.out
*.exe

محتویات بالا به گیت می‌گوید که از همۀ فایل‌هایی که پسوندشان o, out یا exe است صرفنظر کند. اگر نمی‌دانید برای پروژه‌تان چه فایل‌هایی را نادیده بگیرید سری به سایت gitignore.io یا این صفحه در گیت‌هاب بزنید. با توجه به زبان برنامه‌نویسی و نوع پروژه، فایل gitignore. را به شما تحویل می‌دهند.

بخوانید  آشنایی با گیت (git) - بخش دوم

ذخیره کردن تغییرات کامیت نشده

با دستور stash می‌توان تغییرات کامیت نشده را ذخیره کرد. برای فهم کاربرد این دستور، تغییراتی در فایل style.css بدهید، مثلا تگ h1 آن را به صورت زیر تغییر دهید:

h1 {
  font-size: 32px;
  font-family: "Times New Roman", serif;
}

حالا هنوز کارمان تمام نشده و چیزی را کامیت نکرده‌ایم لازم است یکی از باگ‌های اورژانسی پروژه را برطرف کنیم. اکنون نه می‌خواهیم فیچر ناقص را کامیت کنیم و نه می‌خواهیم تا اینجای کاری که روی فایل css انجام داده‌ایم را از دست بدهید. راه‌حل مشکل، ذخیرۀ موقت تغییرات با دستور git stash (گیت استش) است:

git status
git stash
git status

فایل stye.css قبل از استش به عنوان فایل اصلاح شده در دستور git status ظاهر می‌شود. دستور git stash تغییرات فوق را مخفی کرده و یک نسخۀ تمییز از working directory به ما تحویل می‌دهد. اکنون می‌توانیم به شاخۀ جدیدی برای رفع باگ سوئیچ کنیم بدون اینکه مجبور باشیم یک اسنپ‌شات ناقص را صرفاً برای ذخیرۀ تغییرات جاری تولید یا کامیت کنیم.

فرض کنید باگ اورژانسی را برطرف کرده‌ایم و آماده هستیم تا سراغ ادامۀ کارمان یعنی تغییر فایل css برویم. با دستور پایین می‌توانیم محتوای استش شده را برگردانیم:

git stash apply

اکنون فایل style.css همانند قبل از stash است و می‌توانیم به توسعۀ پروژه ادامه دهیم؛ انگار که اصلاً هیچ وقفه‌ای در کارمان ایجاد نشده است. در درس قبلی آموختید که پچ‌ها حاوی اسنپ‌‌شات‌های کامیت شده هستند ولی استش برعکس آن حاوی تغییرات کامیت نشده است. stash تغییرات کامیت نشده را به صورت داخلی جایی در مخزن گیت ذخیره می‌کند؛ سپس با اجرای دستور git reset –hard محتوای working directory را به آخرین کامیت تغییر می‌دهد. تغییرات استش شده را نه‌فقط روی شاخه‌ای که ایجاد شده بلکه روی هر شاخه دیگری می‌توان اعمال کرد.

افزون بر ذخیرۀ تغییرات کامیت نشده، استش اجازه می‌دهد تا به آسانی اصلاحات انجام گرفته را بین شاخه‌ها جابه‌جا کنید. مثلاً اگر بر اثر اشتباه در شاخه‌ای نادرست مشغول اعمال تغییرات روی پروژه بودید، به راحتی می‌توانید تمام تغییرات اعمال شده را استش کنید، شاخۀ درست را چک‌اوت کنید و سپس دستور git stash apply بزنید تا تغییرات استش شده به شاخۀ جدید منتقل شود. پیش از ادامۀ آموزش، تغییرات اعمال شده در فایل css را ریست می‌کنیم:

git reset --hard

استفاده از Hook

از دیگر ویژگی‌های مهم گیت، قابلیت hook (هوک) است. هوک اسکریپتی است که هر زمان رویداد یا اتفاقی در مخزن پروژه افتاد اجرا می‌شود. در اینجا می‌خواهیم هوکی تعریف کنیم که هر توسعه‌دهنده‌ای به مخزن central-repo.git پوش کرد، نسخۀ جدید سایت منتشر شود.

به فولدر central-repo.git بروید و در فولدر hooks، نام فایل post-update.sample را بعد از حذف پسوند sample به post-update تغییر دهید. اسکریپت پایین هر زمان که شاخه‌ای به central-repo.git پوش کند اجرا می‌شود. محتوای پیش‌فرض فایل post-update را به این صورت زیر تغییر دهید:

#!/bin/sh

# Output a friendly message
echo "Publishing master branch!" >&2

# Remove the old `my-website` directory (if necessary)
rm -rf ../my-website

# Create a new `my-website` directory
mkdir ../my-website

# Archive the `master` branch
git archive master --format=tar --output=../my-website.tar

# Uncompress the archive into the `my-website` directory
tar -xf ../my-website.tar -C ../my-website

exit 0

بررسی اسکریپت‌های shell (شل) مبحث ما نیست ولی با کمی دقت متوجه مفهوم دستوراتش خواهید شد. به طور خلاصه، این اسکریپت از شاخۀ مستر یک آرشیو ساخته و آن را در فولدری به نام my-website ذخیره می‌کند. در دنیای واقعی می‌توان سایت را به طور مستقیم به سرور ارسال کرد. (مثلاً از طریق FTP و …).

برای دیدن عملکرد اسکریپت، شاخه‌ای را به مخزن central-repo.git پوش کنید.

git push ../central-repo.git master

بعد از دریافت شاخۀ مستر توسط مخزن مرکزی، اسکریپت post-update به طور خودکار اجرا شده و ضمن نمایش پیام Publishing master branch، فولدر my-website را می‎سازد و فایل فشردۀ my-website.tar را در آن قرار می‌دهد. این فقط یک مثال ساده از هوک بود. بحث فوق بسیار گسترده و خارج از حوصلۀ این سری آموزشی است.

بخوانید  آموزش گیت - قسمت اول

هر فایل‌ sample. در فولدر hooks به رویداد متفاوتی اختصاص دارد و هر یک از آن‌ها می‌تواند برای انجام خودکار کار بخصوصی به کار روند؛ از ساخت و انتشار نسخه‌های جدید برنامه تا اعمال قوانین در هنگام کامیت، اطمینان از کامپایل شدن پروژه، انتشار وب‌سایت (بدون درگیر شدن با شلوغی‌های FTP) و … . برای کسب اطلاعات بیشتر به مستندات رسمی گیت مراجعه کنید.

مشاهدۀ تفاوت بین دو کامیت

تا الان از دستور git log –stat برای نمایش تغییرات کامیت‌های جدید استفاده می‌کردیم. این دستور فقط تعداد خطوط حذف شده و خطوطی که اضافه شده‌اند را اعلام می‌کند ولی تفاوت محتوایی فایل‌ها را نشان نمی‌دهد. برای دیدن تفاوت در این سطح جزئیات از دستور git diff استفاده می‌کنیم. اجازه دهید تفاوتی که آخرین کامیت یعنی Add a pink block of color با کامیت قبل‌اش دارد را ببینیم:

git diff HEAD~2..HEAD~1

HEAD~1، هِد جاری است که به کامیت Add a pink block of color اشاره می‌کند و HEAD~2 کامیت قبل از آن است. خروجی دستور این است:

index 828dd1a..2713b10 100644
--- a/pink.html
+++ b/pink.html
@@ -۴,۱۰ +۴,۱۷ @@
   <title>The Pink Page</title>
   <link rel="stylesheet" href="style.css" />
   <meta charset="utf-8" />
+  <style>
+    div {
+      width: 300px;
+      height: 50px;
+    }
+  </style>
 </head>
 <body>
   <h1 style="color: #F0F">The Pink Page</h1>
   <p>Only <span style="color: #F0F">real men</span> wear pink!</p>
+  <div style="background-color: #F0F"></div>

   <p><a href="index.html">Return to home page</a></p>
 </body>

تغییرات، مشابه پچی است که در درس قبل ساختیم. دستور git diff واقعاً کاربردهای فراوانی دارد. برای مثال با دستور پایین می‌توانیم تفاوت شاخۀ خودمان و شاخۀ pink-page واقع در مخزن جان را قبل از عمل merge مشاهده کنیم:

git diff master..john/pink-page

این دستور انعطاف‌پذیری بالایی دارد. شما می‌توانید تغییرات کامیت نشده را به صورت کامل مشاهده کنید. تغییراتی در فایل blue.html بدهید و ذخیره کنید. حالا دستور git diff را بدون هیچ آرگومانی بزنید:

git diff

در صورتی که ندانیم چه چیزهایی به استیج اضافه کرده‌ایم، با آرگومان cached– می‌توانیم تفاوت بین اسنپ‌شات استیج شده و آخرین کامیت ارسالی را مشاهده کنیم:

git add blue.html
git diff --cached

در واقع git diff تغییرات استیج نشده را با کامیت آخر مقایسه می‌کند ولی git diff –cached تغییرات استیج شده را با کامیت آخر مقایسه می‌کند. اولی برای وقتی است که بخواهیم بدانیم در working directory یا فولدر پروژه نسبت به آخرین کامیت چه تغییراتی داده‌ایم و دومی برای زمانی است که بخواهیم بدانیم تغییرات استیج شده‌ای که قصد کامیت گرفتن از آن‌ها را داریم با آخرین کامیتِ مخزن چه فرقی دارند.

ریست و چک‌اوت کردن فایل‌ها

ما قبلاً از دستورات git reset و git checkout بارها استفاده کرده‌ایم ولی مشکل اینجاست که این دستورات روی شاخه و کامیت‌ها کار می‌کنند؛ یعنی اگر در کامیتی، چند فایل تغییر کرده باشند با ریست یا چک‌اوت کردن آن کامیت همۀ فایل‌ها تحت تاثیر قرار می‌گیرند ولی گاهی اوقات می‌خواهیم فقط یک فایل بخصوص را چک‌اوت کنیم.

ما اغلب عادت داریم با دستور git reset به کامیت جدیدی در شاخۀ جاری برگردیم و اگر دوست داشتیم با آرگومان hard– محتوای working directory را هم به آن کامیت برمی‌گردانیم ولی وقتی فایلی را به این دستور ارسال می‌کنیم، git reset به جای working directory ناحیه staging را مطابق کامیت بروز می‌کند ولی اشاره‌گر شاخۀ جاری را به کامیت جدید منتقل نمی‌کند. این یعنی می‌توانیم با دستور زیر فایل blue.html را از اسنپ‌شات استیج شده حذف کنیم:

git reset HEAD blue.html
git status

دستور فوق، فایل blue.html که در ناحیۀ استیجینگ قرار دارد را با کامیت ذخیره شده در HEAD مطابقت داده ولی کاری به working directory و شاخۀ جاری ندارد. نتیجه اینکه یک ناحیۀ استیج خواهیم داشت که مطابق آخرین کامیت است و یک working directory که فقط فایل blue.htmlاش تغییر کرده است. به زبان ساده‌تر از این نوع git reset برای unstage کردن یک فایل بخصوص استفاده می‌کنیم:

ارسال یک فایل به دستور git reset در گیت
ارسال یک فایل به دستور git reset

دستور git checkout نیز چنین وضعیتی دارد. معمولاً عادت داشتیم از این دستور برای بروز کردن working directory و سوئیچ کردن بین شاخه‌ها استفاده کنیم. ولی اگر مسیر یک فایل را به آن ارسال کنیم، تمرکزش را فقط روی آن فایل می‌گذارد و اشاره‌گر شاخه را جابه‌جا نمی‌کند. این یعنی جدیدترین یا آخرین نسخۀ یک فایل (در اینجا blue.html) را می‌توانیم چک‌اوت کنیم:

git checkout HEAD blue.html
git status

فایل blue.html اکنون دقیقاً مانند نسخه‌ای است که HEAD به آن اشاره می‌کند. بنابراین حالا یک working directory تمییز داریم. ارسال کردن یک فایل به دستور git checkout آن را به کامیت مشخصی می‌برد.

بخوانید  آموزش گیت - قسمت سوم
ارسال یک فایل به دستور git checkout

پس به طور خلاصه وقتی فایلی را به دستور git reset یا git checkout می‌فرستیم، هر دوی آن‌ها یک اسنپ‌شات کامیت شده را به عنوان رفرنس می‌گیرند. دستور reset فایل را در منطقه استیجینگ قرار می‌دهد و دستور checkout آن فایل را در working directory به نسخۀ رفرنس تغیر می‌دهد.

نام مستعار و دیگر تنظیمات گیت

شاید تایپ کردن git checkout برای سوئیچ کردن بین شاخه‌ها اندکی طولانی و خسته‌کننده باشد. گیت به شما اجازه می‌دهد تا اسامی مستعار (alias) برای این دستورات انتخاب کنید:

git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

با دستورات بالا از این پس می‌توانیم به جای git checkout تنها بنویسیم git co و به همین ترتیب به جای git commit از git ci و به جای git branch از git br استفاده کنیم. گیت این دستورات را در یک فایل کانفیگ عمومی (global) ذخیره می‌کند همانطور که فایل کانفیگ اختصاصی را در مخزن ماری ساختیم (marys-repo/.git/config). در حالت پیش‌فرض تنظیمات global در gitconfig./~ قرار دارد.

کاراکتر ~ یک علامت پرکاربرد در لینوکس است که به معنی home directory است که در ویندوز به فولدر حساب کاربری شما اشاره دارد. خط فرمان ویندوز از این کاراکتر حمایت نمی‌کند. بنابراین یا باید در powershell بنویسید ~ cd یا در Run عبارت‌های %userprofile% یا %homepath% را وارد کنید. این فایل چنین ساختاری دارد:

[user]
    name = Ryan
    email = ryan.example@rypress.com
[alias]
    co = checkout
    ci = commit
    br = branch

مسلماً ایمیل و نامی که در درس‌های اول وارد کرده‌اید با مال من فرق می‌کند. همانطور که می‌بینید تمام aliasها در این فایل ذخیره شده‌اند. شما می‌توانید به طور مستقیم هم این فایل را ویرایش کنید. محتوای زیر را به آن اضافه کنید:

[color]
    status = always
[core]
    editor = gvim

خطوط بالا باعث می‌شود خروجی دستور git status از این پس رنگی ظاهر شود و برای وارد کردن پیامِ کامیت‌ها از ادیتور گرافیکی ویم یعنی gvim استفاده کند. از ادیتورهای دیگر نیز می‌توانید استفاده کنید. مثلاً کاربران Emac می‌توانند emacs و کاربران نت‌پد عبارت notepad.exe را وارد کنند.

گزینه‌های پیکربندی گیت بسیار زیاد است که می‌توانید در راهنمای رسمی‌اش پیدا کنید. ذخیرۀ تنظیمات پیکربندی در یک فایل متنی ساده، انتقال آن را بسیار ساده می‌کند؛ تنها کافی است فایل gitconfig./~ را به سیستم مقصد کپی کنید تا دقیقاً مانند گیت روی سیستم خودتان شود.

جمع‌بندی

در این درس یادگرفتیم چگونه اسنپ‌شات‌ها را اکسپورت کنیم، از مخازن بکاپ بگیریم، فایل‌ها را ignore کنیم، تغییرات موقت را استش کنیم، از هوک برای اتوماسیون فعالیت‌ها بهره گیریم، تفاوت فایل‌ها را مشاهده کنیم، فایل‌های بخصوصی را ریست کنیم و نهایتاً برای دستورات رایج، اسامی مستعار و کوتاه تعریف کنیم.آوردن همۀ دستورات گیت در یک آموزش کوتاه نه مقدور و نه شایسته است. عمده تمرکز این راهنما، آشنایی با عملکرد گیت و داشتن درک درستی از دستورات اصلی آن است. در واقع هدف تقویت فونداسیون فکری شماست نه صرفاً بیان فهرست‌وار دستورات فراوان گیت.

البته ویژگی‌های پیشرفته و دستورات متعدد گیت ممکن است هر انسانی حتی خالق آن لینوس توروالدز را هم سردرگم کند. هر وقت احساس کردید گیت بیشتر از آنکه مفید باشد برای شما دردسر ایجاد کرده احتمالاً در استفاده از دستوراتی که درک درستی از آن‌ها نداشتید زیاده‌روی کرده‌اید. در چنین وضعیتی، به همان دستورات پایه برگردید و سعی کنید با همان‌ها کارتان را پیش ببرید. تا زمانی که درک درستی از دستورات پایۀ گیت پیدا نکرده‌اید سراغ دستورات پیشرفته‌تر نروید.

امیدواریم در این سری آموزشی شما را با مقدمات ابتدایی گیت آشنا کرده باشیم و اکنون با دید بهتری از این ابزار استفاده کنید. کسب دانش در این سطح جزئیات کمک می‌کند تا درک بهتر و دقیق‌تری از گیت داشته باشید و با خیالی آسوده آن را در پروژه‌های خود به کار گیرید. اصل طلایی یادگیری را هم فراموش نکنید؛ تمرین!

چکیدۀ دستورات

  • <git archive –format=zip –output=<file : اکسپورت کردن تنها یک اسنپ‌شات به یک فایل zip به نام <file>؛
  • <git bundle create <branch-name : اکسپورت کردن کل شاخه به همراه تاریخچه به یک فایل (باندل)؛
  • <git clone repo.bundle -b <branch-name : بازتولید پروژه از فایل باندل و چک‌اوت کردن شاخۀ <branch‑name>؛
  • git stash : استش کردن موقت تغییرات برای پاکسازی working directory؛
  • git stash apply : اعمال تغییرات استش شده به working directory؛
  • <git diff ..<commit-id : نمایش تفاوت بین دو کامیت؛
  • git diff : نمایش تفاوت بین working directory و ناحیۀ استیج؛
  • git diff –cashed : نمایش تفاوت بین ناحیۀ استیج و آخرین (جدیدترین) کامیت؛
  • <git reset HEAD <file : آنستیج کردن (Unstage) یک فایل بدون تغییر working directory یا جابه‌جا کردن شاخۀ جاری؛
  • <git checkout <commit-id> <file : بازگردانی یک فایلِ بخصوص به یک کامیت مشخص بدون سوئیچ کردن بین شاخه‌ها؛
  • <git config –global alias. <git-command : ساخت یک میانبر برای دستورات و ذخیرۀ آن در فایل تنظیمات عمومی گیت.

سید ایوب کوکبی

نویسنده و مترجم...

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *