-
1. شروع به کار (getting started)
-
2. مقدمات گیت (git basics chapter)
- 2.1 گرفتن یک مخزن گیت (Getting a Git Repository)
- 2.2 ثبت تغییرات در مخزن (Recording Changes to the Repository)
- 2.3 مشاهده تاریخچه کامیتها (Viewing the Commit History)
- 2.4 بازگرداندن تغییرات (Undoing Things)
- 2.5 کار کردن با ریموت ها (Working with Remotes)
- 2.6 تگ کردن (Tagging)
- 2.7 نام مستعار گیت (Git Aliases)
- 2.8 خلاصه (summary)
-
3. انشعاب‌گیری در گیت (Git Branching)
-
4. گیت روی سرور (Git on the server)
- 4.1 پروتکلها (The Protocols)
- 4.2 راهاندازی گیت روی یک سرور (Getting Git on a Server)
- 4.3 ایجاد کلید عمومی SSH شما (Generating Your SSH Public Key)
- 4.4 نصب و راهاندازی سرور (Setting up server)
- 4.5 سرویسدهنده گیت (Git Daemon)
- 4.6 HTTP هوشمند (Smart HTTP)
- 4.7 گیتوب (GitWeb)
- 4.8 گیتلب (GitLab)
- 4.9 گزینههای میزبانی شخص ثالث (Third Party Hosted Options)
- 4.10 خلاصه (Summary)
-
5. گیت توزیع‌شده (Distributed git)
-
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. سفارشی‌سازی Git (Customizing Git)
-
9. گیت و سیستم‌های دیگر (Git and Other Systems)
-
10. (Git Internals)
- 10.1 ابزارها و دستورات سطح پایین (Plumbing and Porcelain)
- 10.2 اشیا گیت (Git Objects)
- 10.3 مراجع گیت (Git References)
- 10.4 فایلهای بسته (Packfiles)
- 10.5 نگاشت (The Refspec)
- 10.6 پروتکلهای انتقال (Transfer Protocols)
- 10.7 نگهداری و بازیابی دادهها (Maintenance and Data Recovery)
- 10.8 متغیرهای محیطی (Environment Variables)
- 10.9 (Summary)
-
A1. پیوست A: گیت در محیط‌های دیگر (Git in Other Environments)
- A1.1 رابط های گرافیکی (Graphical Interfaces)
- A1.2 Git در ویژوال استودیو (Git in Visual Studio)
- A1.3 Git در Visual Studio Code (Git in Visual Studio Code)
- A1.4 Git در IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine (Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine)
- A1.5 Git در Sublime Text (Git in Sublime Text)
- A1.6 گیت در بش (Git in Bash)
- A1.7 Git در Zsh (Git in Zsh)
- A1.8 Git در PowerShell (Git in PowerShell)
- A1.9 خلاصه (Summary)
-
A2. پیوست B: گنجاندن گیت در برنامه‌های شما (Embedding Git in your Applications)
-
A3. پیوست C: دستورات گیت (Git Commands)
- A3.1 تنظیم و پیکربندی (Setup and Config)
- A3.2 گرفتن و ایجاد پروژهها (Getting and Creating Projects)
- A3.3 نمونهبرداری پایهای (Basic Snapshotting)
- A3.4 انشعاب‌گیری و ادغام (Branching and Merging)
- A3.5 بهاشتراکگذاری و بهروزرسانی پروژهها (Sharing and Updating Projects)
- A3.6 بازرسی و مقایسه (Inspection and Comparison)
- A3.7 عیبیابی (Debugging)
- A3.8 اعمال تغییرات به صورت پچ (Patching)
- A3.9 ایمیل (Email)
- A3.10 سیستم‌های خارجی (External Systems)
- A3.11 مدیریت (Administration)
- A3.12 دستورات سطح پایین گیت (Plumbing Commands)
2.2 مقدمات گیت (git basics chapter) - ثبت تغییرات در مخزن (Recording Changes to the Repository)
ثبت تغییرات در مخزن (Recording Changes to the Repository)
در این مرحله، شما باید یک مخزن _bona fide_Git در ماشین محلی خود داشته باشید، و یک نسخه چک کردن یا کار کردن از تمام فایل های آن در مقابل شما. به طور معمول، شما می خواهید شروع به ایجاد تغییرات و ارسال عکس از آن تغییرات به مخزن خود را هر بار که پروژه به یک دولت شما می خواهید به ثبت برسد.
به یاد داشته باشید که هر فایل در دایرکتوری کاری شما می تواند در یکی از دو حالت باشد: tracked یا untracked. فایل های ردیابی شده، فایل هایی هستند که در آخرین عکس لحظه ای بودند، و همچنین هر فایل جدیدی که مرحله بندی شده است؛ آنها می توانند بدون تغییر، اصلاح شده یا مرحله بندی شوند. به طور خلاصه، فایل های ردیابی شده، فایل هایی هستند که گیت از آن ها آگاه است.
فایل های بدون ردیابی همه چیز دیگری هستند — هر فایل در دایرکتوری کاری شما که در آخرین عکس شما نبود و در منطقه تنظیم شما نیست. هنگامی که شما برای اولین بار یک مخزن را کلان می کنید، تمام فایل های شما ردیابی و بدون تغییر خواهند شد زیرا Git آنها را بررسی کرده و شما چیزی را ویرایش نکرده اید.
همانطور که فایل ها را ویرایش می کنید، گیت آنها را به عنوان اصلاح شده می بیند، زیرا شما آنها را از آخرین ارتقاء خود تغییر داده اید. همانطور که کار می کنید، به طور انتخابی این فایل های اصلاح شده را مرحله بندی می کنید و سپس تمام آن تغییرات مرحله ای را انجام می دهید، و چرخه تکرار می شود.
بررسی وضعیت فایل های شما (Checking the Status of Your Files)
ابزار اصلی که شما برای تعیین اینکه کدام فایل ها در کدام حالت هستند استفاده می کنید دستور git status است.
اگر شما این دستور را مستقیماً بعد از یک کلان اجرا کنید، چیزی شبیه به این خواهید دید:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree cleanاین به این معنی است که شما یک دایرکتوری کاری تمیز دارید؛ به عبارت دیگر، هیچ یک از فایل های ردیابی شده شما اصلاح نشده است.
همچنین گیت هیچ فایل غیر ردیابی شده ای را نمی بیند، در غیر این صورت آنها در اینجا فهرست شده اند.
در نهایت، دستور به شما می گوید که در کدام شاخه هستید و به شما اطلاع می دهد که از همان شاخه در سرور منحرف نشده است.
در حال حاضر، این شاخه همیشه master است، که پیش فرض است؛ شما نگران آن در اینجا نخواهید بود.
انشعاب‌گیری در گیت (Git Branching) شاخه ها و مرجع ها را به طور مفصل بررسی می کند.
|
یادداشت
|
گیت هاب در اواسط سال 2020 نام شاخه پیش فرض را از با این حال، گیت خود هنوز از |
فرض کنید که شما یک فایل جدید به پروژه خود اضافه کنید، یک فایل ساده "README"
اگر این فایل قبلا وجود نداشته باشد و شما git status را اجرا کنید، فایل بدون ردیابی خود را به این شکل می بینید:
$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)شما می توانید ببینید که فایل جدید README شما غیر قابل ردیابی است، زیرا تحت عنوان " فایل های غیر قابل ردیابی " در خروجی وضعیت شما قرار دارد.
Untracked اساساً به این معنی است که Git یک فایل را می بیند که شما در عکس فوری قبلی (تعهد) نداشته اید و هنوز مرحله ای نشده است؛ Git شامل آن در عکس فوری شما نمی شود تا زمانی که به طور صریح به آن بگویید.
این کار را انجام می دهد تا شما به طور تصادفی شروع به اضافه کردن فایل های باینری تولید شده یا فایل های دیگری که شما قصد نداشتید را شامل شوید.
شما می خواهید شروع به شامل 'README' کنید، پس بیایید پرونده را ردیابی کنیم.
دنبال کردن فایل های جدید (Tracking New Files)
برای شروع ردیابی یک فایل جدید، از دستور git add استفاده می کنید.
برای شروع به ردیابی فایل "README" می توانید این را اجرا کنید:
$ git add READMEاگر دستور وضعیت خود را دوباره اجرا کنید، می توانید ببینید که فایل README شما در حال حاضر ردیابی شده و مرحله ای برای انجام شده است:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: READMEمی تونید بفهمید که صحنه سازی شده چون زیر عنوان "تغییراتی که باید انجام بشه" قرار داره.
اگر در این مرحله commit کنید، نسخه فایل در زمانی که شما git add را اجرا کردید همان چیزی است که در تصویر تاریخی بعدی خواهد بود.
ممکن است به یاد داشته باشید که وقتی قبلاً git init را اجرا کردید، سپس git add <files> ` را اجرا کردید — که برای شروع ردیابی فایل ها در دایرکتوری شما بود.
دستور `git add نام مسیر را برای یک فایل یا یک دایرکتوری می گیرد. اگر یک دایرکتوری باشد، دستور تمام فایل های موجود در آن دایرکتوری را به صورت تکراری اضافه می کند.
مرحله بندی فایل های اصلاح شده (Staging Modified Files)
بیایید یک فایل که قبلا ردیابی شده بود را تغییر دهیم.
اگر شما یک فایل ردیابی شده قبلی به نام CONTRIBUTING.md را تغییر دهید و سپس دستور git status خود را دوباره اجرا کنید، چیزی شبیه به این را دریافت می کنید:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdفایل CONTRIBUTING.md در بخش " تغییرات ` که برای commit ` مرحله بندی نشده است" ظاهر می شود — که به این معنی است که فایل ردیابی شده در دایرکتوری کاری تغییر کرده است اما هنوز مرحله بندی نشده است.
برای این کار، شما دستور git add را اجرا می کنید.
git add یک دستور چند منظوره است — شما از آن برای شروع ردیابی فایل های جدید، مرحله بندی فایل ها، و انجام کارهای دیگر مانند علامت گذاری فایل های با تعارض ادغام به عنوان حل شده استفاده می کنید.
ممکن است مفید باشد که به آن بیشتر به عنوان " ` اضافه کردن دقیقا این محتوا به commit بعدی ` " به جای " ` اضافه کردن این فایل به پروژه ` " فکر کنید.
بیایید اکنون add git را اجرا کنیم تا فایل ∀CONTRIBUTING.md` را اجرا کنیم و سپس دوباره status git را اجرا کنیم:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.mdهر دو فایل آماده شده اند و به کامیت بعدی شما منتقل خواهند شد.
در این مرحله، فرض کنید یک تغییر کوچک را به یاد آورده اید که می خواهید قبل از انجام آن در CONTRIBUTING.md ایجاد کنید.
دوباره بازش ميکني و اون تغيير رو ميکني و آماده ي تعهد هستي.
با این حال، بیایید یک بار دیگر وضعیت را اجرا کنیم:
$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdچه خبره؟
حالا CONTRIBUTING.md به عنوان هر دو مرحله ای و غیر مرحله ای فهرست شده است.
چطور ممکنه؟
معلوم شد که گیت یک فایل را دقیقاً همان طور که وقتی دستور git add را اجرا می کنید، مرحله بندی می کند.
اگر شما اکنون commit کنید، نسخه ی CONTRIBUTING.md همان طور که در آخرین باری که دستور git add را اجرا کردید، وارد commit می شود، نه نسخه ی فایل همان طور که در دایرکتوری کاری شما در هنگام اجرا git commit ظاهر می شود.
اگر شما یک فایل را پس از اجرای git add تغییر دهید، باید دوباره git add را اجرا کنید تا آخرین نسخه فایل را اجرا کنید:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.mdخلاصه وضعیت (Short Status)
در حالی که خروجی وضعیت git ` کاملاً جامع است ، اما کاملاً کلمه ای است.
گیت همچنین دارای یک پرچم وضعیت کوتاه است تا بتوانید تغییرات خود را به روشی جمع و جور تر مشاهده کنید.
اگر شما `git status -s یا git status --short را اجرا کنید، خروجی بسیار ساده تر از دستور را دریافت می کنید:
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txtفایل های جدید که ردیابی نشده اند دارای ?? ` در کنار آنها، فایل های جدید که به منطقه مرحله ای اضافه شده اند دارای `A، فایل های اصلاح شده دارای M و غیره هستند.
دو ستون در خروجی وجود دارد - ستون سمت چپ وضعیت منطقه مرحله ای را نشان می دهد و ستون سمت راست وضعیت درخت کار را نشان می دهد.
بنابراین برای مثال در آن خروجی، فایل README در دایرکتوری کار تغییر یافته است اما هنوز مرحله ای نشده است، در حالی که فایل lib/simplegit.rb تغییر یافته و مرحله ای شده است.
Rakefile اصلاح شد، مرحله ای شد و سپس دوباره اصلاح شد، بنابراین تغییراتی در آن وجود دارد که هم مرحله ای و هم غیر مرحله ای است.
فایل های ایگنور شده (Ignoring Files)
اغلب، شما یک کلاس از فایل هایی دارید که نمی خواهید گیت به طور خودکار آنها را اضافه کند یا حتی به شما نشان دهد که آنها ردیابی نشده اند.
این فایل ها به طور کلی به طور خودکار تولید می شوند مانند فایل های لاگ یا فایل هایی که توسط سیستم ساخت شما تولید می شوند.
در چنین مواردی، می توانید یک لیست از فایل ها را با نام .gitignore. ایجاد کنید تا با آنها مطابقت داشته باشد.
در اینجا یک نمونه از فایل .gitignore وجود دارد:
$ cat .gitignore
*.[oa]
*~خط اول به گیت می گوید که تمام فایل هایی که به “.o” یا “.a” ختم می شوند را نادیده بگیرد — فایل های شی و آرشیو که ممکن است محصول ساخت کد شما باشند.
خط دوم به گیت می گوید که تمام فایل هایی را که نام آنها با تایلد (~) پایان می یابد، نادیده بگیرد، که توسط بسیاری از ویرایشگرهای متن مانند Emacs برای علامت گذاری فایل های موقت استفاده می شود.
شما همچنین می توانید یک دایرکتوری log، tmp، یا pid؛ مستندات تولید شده به طور خودکار؛ و غیره را شامل شوید.
تنظیم یک فایل .gitignore برای مخزن جدید قبل از شروع کار به طور کلی ایده خوبی است تا فایل هایی را که واقعاً نمی خواهید در مخزن گیت خود قرار ندهید.
قوانین برای الگوهایی که می توانید در فایل .gitignore قرار دهید عبارتند از:
-
خطوط خالی یا خطوطی که با
#شروع می شوند نادیده گرفته می شوند. -
الگوهای استاندارد گلوب کار می کنند و به طور تکراری در کل درخت کاری اعمال می شوند.
-
شما می توانید الگوها را با یک تراش جلو (
/) شروع کنید تا از تکرار پذیری جلوگیری کنید. -
شما می توانید الگوها را با یک خط کش (
/) به سمت جلو برای مشخص کردن یک دایرکتوری به پایان برسانید. -
شما می توانید یک الگوی را با شروع آن با یک علامت تعجب (`! `).
الگوهای گلوب مانند عبارات منظم ساده شده ای هستند که پوسته ها استفاده می کنند.
یک ستاره (*) با صفر یا بیشتر کاراکترها مطابقت دارد؛ [abc] با هر کاراکتر داخل براکت ها (در این مورد a، b یا c) مطابقت دارد؛ علامت سوال (? `) با یک کاراکتر واحد مطابقت دارد؛ و براکت هایی که کاراکترهای جدا شده توسط یک خط کش ([0-9]) را در بر می گیرد با هر کاراکتر بین آنها مطابقت دارد (در این مورد از 0 تا 9).
شما همچنین می توانید از دو ستاره برای مطابقت با دایرکتوری های آشیانه ای استفاده کنید؛ `a/**/z با a/z، a/b/z، a/b/c/z و غیره مطابقت دارد.
در اینجا یک مثال دیگر از فایل .gitignore وجود دارد:
# ignore all .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in any directory named build
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .pdf files in the doc/ directory and any of its subdirectories
doc/**/*.pdf|
نکته
|
گیت هاب یک لیست کاملا جامع از نمونه های فایل های خوب |
|
یادداشت
|
در مورد ساده، یک مخزن ممکن است یک فایل این فراتر از محدوده این کتاب است که به جزئیات پرونده های متعدد |
مشاهده تغییرات آماده و آماده‌نشده (Viewing Your Staged and Unstaged Changes)
اگر دستور git status برای شما مبهم است - شما می خواهید دقیقا بدانید که چه چیزی را تغییر داده اید، نه فقط اینکه کدام فایل ها تغییر کرده اند - شما می توانید از دستور git diff استفاده کنید.
ما بعداً به جزئیات بیشتری در مورد "git diff" می پردازیم، اما احتمالاً بیشتر از همه برای پاسخ به این دو سوال از آن استفاده خواهید کرد: چه چیزی را تغییر داده اید اما هنوز اجرا نشده اید؟
و تو چه صحنه اي رو بازي کردي که ميخواي انجام بدي؟
اگر چه git status به این سوالات با فهرست کردن اسامی فایل ها پاسخ می دهد، git diff خطوط دقیق اضافه شده و حذف شده را به شما نشان می دهد.
بیایید بگوییم که فایل README را دوباره ویرایش و مرحله بندی می کنید و سپس فایل CONTRIBUTING.md را بدون مرحله بندی ویرایش می کنید.
اگر دستور git status را اجرا کنید، یک بار دیگر چیزی شبیه به این می بینید:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdبرای دیدن اینکه چه چیزی را تغییر داده اید اما هنوز مرحله ای نشده است، با هیچ استدلال دیگری git diff را تایپ کنید:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it'sاین دستور آنچه را که در دایرکتوری کار شما هست با آنچه که در منطقه ی تنظیم شما هست مقایسه می کند. نتیجه به شما می گوید که چه تغییراتی را انجام داده اید که هنوز اجرا نکرده اید.
اگر می خواهید ببینید که چه چیزی را تنظیم کرده اید که در commit بعدی شما قرار خواهد گرفت، می توانید از git diff --staged استفاده کنید.
این دستور تغییرات مرحله ای شما را با آخرین کامیت مقایسه می کند:
$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Projectمهم است که توجه داشته باشید که git diff به خودی خود تمام تغییرات ایجاد شده از آخرین ارتکاب شما را نشان نمی دهد - فقط تغییراتی که هنوز مرحله ای نشده اند.
اگر تمام تغییرات خود را اجرا کرده باشید، git diff هیچ خروجی به شما نخواهد داد.
برای مثال دیگر، اگر فایل CONTRIBUTING.md را مرحله بندی کنید و سپس آن را ویرایش کنید، می توانید از git diff برای دیدن تغییرات در فایل استفاده کنید که مرحله بندی شده اند و تغییراتی که مرحله بندی نشده اند.
اگر محیط ما اینگونه باشد:
$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdحالا شما می توانید از git diff استفاده کنید تا ببینید چه چیزی هنوز اجرا نشده است:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
## Starter Projects
See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test lineو git diff --cached برای دیدن آنچه که تا کنون انجام داده اید (--staged و --cached مترادف هستند):
$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it's|
یادداشت
|
Git Diff in an External Tool
ما به استفاده از دستور |
کامیت کردن تغییراتتان (Committing Your Changes)
حالا که منطقه آماده سازی شما به روشی که می خواهید تنظیم شده، می توانید تغییرات خود را انجام دهید.
به یاد داشته باشید که هر چیزی که هنوز مرحله ای نشده است - هر فایل ای که ایجاد کرده اید یا اصلاح کرده اید که از زمانی که آنها را ویرایش کرده اید اجرا نکرده اید - به این ارتکاب نمی رود.
آنها به عنوان فایل های اصلاح شده در دیسک شما باقی خواهند ماند.
در این مورد، بیایید بگوییم که آخرین باری که شما git status را اجرا کردید، دیدید که همه چیز مرحله ای شده است، بنابراین شما آماده اید که تغییرات خود را انجام دهید.
ساده ترین راه برای commit کردن این است که git commit:
$ git commitاین کار باعث می شود تا ویرایشگر مورد نظر شما را راه اندازی کند.
|
یادداشت
|
این توسط متغیر محیط |
ویرایشگر متن زیر را نمایش می دهد (این مثال یک صفحه نمایش Vim است):
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# new file: README
# modified: CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283Cشما می توانید ببینید که پیام commit پیش فرض شامل آخرین خروجی از دستور git status با یک خط خالی در بالای آن است.
شما می توانید این نظرات را حذف کنید و پیام commit خود را تایپ کنید، یا می توانید آنها را آنجا بگذارید تا به شما کمک کند آنچه را که انجام می دهید به یاد داشته باشید.
|
یادداشت
|
برای یک یادآوری واضح تر از آنچه که تغییر داده اید، می توانید گزینه |
هنگامی که شما از ویرایشگر خارج می شوید، گیت commit شما را با این پیام commit (با حذف نظرات و اختلافات) ایجاد می کند.
در عوض، می توانید پیام commit خود را با دستور commit با مشخص کردن آن پس از یک پرچم -m، مانند این تایپ کنید:
$ git commit -m "Story 182: fix benchmarks for speed"
[master 463dc4f] Story 182: fix benchmarks for speed
2 files changed, 2 insertions(+)
create mode 100644 READMEحالا شما اولين کارتون رو انجام دادين!
شما می توانید ببینید که commit به شما در مورد خود خروجی داده است: به کدام شاخه commit کرده اید (master) ، چه چک سوم SHA-1 commit دارد (463dc4f) ، چه تعداد فایل تغییر کرده است و آمار مربوط به خطوط اضافه شده و حذف شده در commit.
به یاد داشته باشید که ثبت عکس لحظه ای که در منطقه تنظیم خود قرار داده اید را ثبت می کند. هر چیزی که شما تنظیم نکرده اید هنوز در آنجا اصلاح شده است؛ شما می توانید یک تعهد دیگر برای اضافه کردن آن به تاریخچه خود انجام دهید. هر بار که یک commit را انجام می دهید، یک عکس از پروژه خود را ضبط می کنید که می توانید بعداً به آن بازگردید یا با آن مقایسه کنید.
عبور از محدوده استیج (Skipping the Staging Area)
اگر چه می تواند برای ساخت commit ها به طور دقیق به همان شکل که می خواهید مفید باشد، اما منطقه ی مرحله بندی گاهی کمی پیچیده تر از آنچه در جریان کار شما نیاز دارید است.
اگر می خواهید از منطقه مرحله بندی عبور کنید، گیت یک میانبر ساده ارائه می دهد.
اضافه کردن گزینه -a به دستور commit `git باعث می شود که Git به طور خودکار هر فایلی را که قبلاً قبل از انجام commit ردیابی شده است ، مرحله بندی کند ، و به شما اجازه می دهد قسمت add `git را حذف کنید:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'Add new benchmarks'
[master 83e38c7] Add new benchmarks
1 file changed, 5 insertions(+), 0 deletions(-)توجه کنید که در این مورد قبل از اینکه commit کنید، لازم نیست git add را در فایل CONTRIBUTING.md اجرا کنید.
این به این دلیل است که پرچم -a شامل تمام فایل های تغییر یافته است.
این کار راحت است، اما مراقب باشید؛ گاهی اوقات این پرچم باعث می شود تغییرات ناخواسته ای را وارد کنید.
حذف فایل ها (Removing Files)
برای حذف یک فایل از گیت، باید آن را از فایل های ردیابی شده خود حذف کنید (به طور دقیق تر، آن را از منطقه ردیابی شده خود حذف کنید) و سپس commit کنید.
دستور git rm این کار را انجام می دهد، و همچنین فایل را از دایرکتوری کاری شما حذف می کند تا دفعه بعد آن را به عنوان یک فایل غیر ردیابی مشاهده نکنید.
اگر فایل را از دایرکتوری کاری خود حذف کنید، در قسمت " تغییرات برای ارتکاب مرحله ای نشده " (یعنی unstaged) در خروجی وضعیت git ظاهر می شود:
$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: PROJECTS.md
no changes added to commit (use "git add" and/or "git commit -a")Then, if you run git rm, it stages the file’s removal:
$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: PROJECTS.mdدفعه ي بعدي که پيگيري کردي، فايل از بين خواهد رفت و ديگه تعقيب نميشه.
اگر فایل را تغییر داده اید یا قبلاً آن را به منطقه مرحله بندی اضافه کرده اید، باید حذف آن را با گزینه -f اجبار کنید.
این یک ویژگی امنیتی برای جلوگیری از حذف تصادفی داده هایی است که هنوز در یک عکس ثبت نشده اند و نمی توانند از Git بازیابی شوند.
یکی دیگر از کارهای مفید که می توانید انجام دهید این است که فایل را در درخت کار خود نگه دارید اما آن را از منطقه مرحله بندی خود حذف کنید.
به عبارت دیگر، شما ممکن است بخواهید فایل را در هارد دیسک خود نگه دارید اما دیگر Git را دنبال نکنید.
این به ویژه مفید است اگر شما فراموش کرده اید چیزی را به فایل .gitignore خود اضافه کنید و به طور تصادفی آن را مرحله بندی کنید، مانند یک فایل لاگ بزرگ یا یک دسته از فایل های کامپایل شده .a.
برای انجام این کار، از گزینه --cached استفاده کنید:
$ git rm --cached READMEشما می توانید فایل ها، دایرکتوری ها و الگوهای گلوب فایل را به دستور git rm منتقل کنید.
این به این معنی است که شما می توانید کارهایی مانند:
$ git rm log/\*.logتوجه کنید که خط عقب (\) در مقابل * قرار دارد.
این کار لازم است زیرا گیت علاوه بر افزونه نام فایل پوسته شما، افزونه نام فایل خود را نیز انجام می دهد.
این دستور تمام فایل هایی را که دارای پسوند .log در دایرکتوری log/ هستند حذف می کند.
یا، شما می توانید چیزی شبیه به این:
$ git rm \*~این دستور تمام فایل هایی که نامشان با یک ~ به پایان می رسد را حذف می کند.
جا به جایی فایل ها (Moving Files)
برخلاف بسیاری از VCS های دیگر، گیت به طور صریح حرکت فایل را ردیابی نمی کند. اگر شما یک فایل را در گیت تغییر نام دهید، هیچ متا داده ای در گیت ذخیره نمی شود که به آن بگوید شما فایل را تغییر نام داده اید. با این حال، گیت خیلی باهوش است که این موضوع را بعد از وقوع آن تشخیص می دهد — ما کمی بعد با تشخیص حرکت فایل ها سر و کار خواهیم داشت.
بنابراین کمی گیج کننده است که گیت یک دستور mv داشته باشد.
اگر می خواهید یک فایل را در گیت تغییر نام دهید، می توانید چیزی شبیه به این را اجرا کنید:
$ git mv file_from file_toو خوب کار می کنه. در واقع، اگر شما چیزی شبیه به این را اجرا کنید و به وضعیت نگاه کنید، خواهید دید که گیت آن را به عنوان یک فایل تغییر نام می داند:
$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> READMEبا این حال، این معادل اجرای چیزی شبیه به این است:
$ mv README.md README
$ git rm README.md
$ git add READMEگیت متوجه شد که این یک تغییر نام ضمنی است، بنابراین فرقی نمی کند که آیا شما یک فایل را به این طریق یا با دستور mv تغییر نام دهید.
تنها تفاوت واقعی این است که git mv یک دستور به جای سه دستور است — این یک تابع راحتی است.
مهمتر از همه، شما می توانید از هر ابزاری که دوست دارید برای تغییر نام یک فایل استفاده کنید، و بعدا قبل از اینکه commit کنید به add/rm رسیدگی کنید.
