Git در سال‌های اخیر محبوبیت زیادی پیدا کرده است. سیستم کنترل نسخه‌ای (version control system) که در پروژه‌های بزرگ متن باز همچون لینوکس، با هزاران همکار و مشارکت کننده، توسط تیم‌هایی با اندازه‌های مختلف، توسعه دهندگانی که تنها کار می‌کنند و حتی دانش‌آموزان مورد استفاده قرار گرفته است.

افراد مبتدی با دیدن این همه دستور و نشانه‌ای که git فراهم کرده است، معمولا وحشت می‌کنند. اما شما برای شروع لازم نیست با تمام آنها آشنایی داشته باشید. شما می‌توانید ابتدا بر دستوراتی که بیش از همه کاربردی هستند مسلط شوید و رفته رفته اطلاعات خود را کامل کنید. این دقیقا همان چیزی‌ست که امروز به شما یاد می‌دهیم. بیایید شروع کنیم!

---

اصول اولیه

Git مجموعه‌ای از دستورات سودمند خط فرمان است که تغییرات ایجاد شده در فایل‌ها را دنبال و ثبت می‌کند (بیشتر برای منابع کد استفاده می‌شود، اما شما می‌توانید هرچیزی که دوست دارید را دنبال کنید). بدین طریق شما می‌توانید نسخه‌های قدیمی‌تر پروژه‌های خود را بازیابی کنید. همچنین می‌توانید مقایسه، تحلیل، ادغام تغییرات و خیلی کارهای دیگر را انجام دهید. این فرآیند تحت عنوان “کنترل نسخه” (version control) شناخته می‌شود. سیستم‌های مختلفی وجود دارند که این کار را انجام می‌دهند. ممکن است نام‌هایی چون SVN، Mercurial، Perforce، CVS، Bitkeeper و … را شنیده باشید.

Git به صورت غیرمتمرکز کار می‌کند؛ به این معنا که به یک سرور مرکزی برای نگهداری نسخه‌های فایل‌های شما وابسته نیست. در عوض به صورت کاملا محلی (locally) داده‌ها را در پوشه‌ای روی دیسک کامپیوتر خودتان ذخیره می‌کند که آن را “مخزن” (repository) می‌نامیم. با این حال شما می‌توانید یک کپی از مخزن خود را به صورت آنلاین داشته باشید، به این ترتیب چند نفر مختلف می‌توانند به سادگی روی یک منبع کد، به صورت مشترک کار کنند. وب‌سایت‌هایی نظیر GitHub و BitBucket بدین منظور استفاده می‌شوند.

۱٫ نصب و راه‌اندازی Git

نصب Git روی دستگاه شما خیلی ساده و سرراست است:

• Linux – به سادگی یک ترمینال جدید باز کنید و git را از طریق package manager مرتبط با سیستم عامل خود نصب کنید. به عنوان مثال برای سیستم‌عامل Ubuntu دستوری که باید اجرا شود این است: sudo apt-get install git
• Windows – پیشنهاد می کنیم از git for windows استفاده کنید که هم یک واسط کاربری گرافیکی (GUI client) و هم یک شبیه‌ساز خط فرمان (BASH comand line) ارائه می‌دهد.
• OS X – آسانترین راه این است که ابتدا homebrew را نصب کنید و سپس دستور brew install git را از طریق ترمینال اجرا کنید.

اگر شما خیلی مبتدی هستید، پس حتما به یک واسط گرافیکی git نیاز خواهید داشت. توصیه می‌کنیم که از GitHub Desktop یا Sourcetree استفاده کنید، اما ابزارهای خوب و رایگان دیگری نیز وجود دارند. در نظر داشته باشید که حتی اگر از یک برنامه با واسط کاربری گرافیکی استفاده کنید، همچنان به دانستن دستورهای پایه‌ای در git احتیاج خواهید داشت، پس در ادامه‌ی این آموزش، تمرکز ما بر همان دستورها خواهد بود.

۲٫ تنظیم و پیکربندی Git

پس از آنکه git را روی کامپیوتر خودمان نصب کردیم، لازم است برخی تنظیمات اولیه را انجام دهیم. گزینه‌های زیادی وجود دارند که می‌توان در مورد آنها صحبت کرد، اما می‌خواهیم مهمترین آنها را تنظیم کنیم: یعنی username و email. یک تزمینال باز کنید و دستورات زیر را اجرا کنید:

$ git config --global user.name "My Name"
$ git config --global user.email myEmail@example.com

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

۳٫ ایجاد یک مخزن جدید – git init

همانطور که قبلا اشاره کردیم، git فایل‌ها و تاریخچه‌هایش را به صورت مستقیم در یک پوشه در پروژه‌ی شما ذخیره می‌کند. برای ایجاد یک مخزن جدید، ترمینال را باز می‌کنیم، به پوشه‌ای که پروژه‌ی ما در آن قرار گرفته است می‌رویم و دستور git init را اجرا می‌کنیم. به این ترتیب Git برای این پوشه‌ی خاص فعال می‌شود و یک پوشه‌ی مخفی (hidden) به نام git. همانجا ایجاد می‌شود که تاریخچه‌ی مخزن و پیکربندی‌ها در آن ذخیره می‌شود.

برای تمرین، یک پوشه به نام git_exercise روی دسکتاپ خود ایجاد کنید، یک ترمینال جدید باز کنید و دستورات زیر را اجرا کنید:

$ cd Desktop/git_exercise/
$ git init

در نتیجه خط فرمان پاسخی شبیه به خطوط زیر را نشان می‌دهد:

Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

این به این معناست که مخزن ما با موفقیت ایجاد شده اما همچنان خالی است. حالا یک فایل متنی ساده به نام hello.txt ایجاد و در پوشه‌ی git_exercise ذخیره می‌کنیم.

۴٫ بررسی وضعیت – git status

وضعیت git یکی از دستورهای دیگری‌ست که باید بدانید. این دستور اطلاعات وضعیت فعلی مخزن را ارائه می‌کند که شامل چیزهایی که به‌روز شده‌اند، جدید هستند، تغییر کرده‌اند و نظیر آن است. اجرای دستور git status روی مخرن جدیدی که ایجاد کردیم، نتیجه‌ای مشابه زیر برمی‌گرداند:

$ git status

On branch master

Initial commit

Untracked files:
  (use "git add ..." to include in what will be committed)

    hello.txt

پیغام بازگشتی نشان می‌دهد که فایل  hello.txt ناشناخته (untracked) است. به این معناست که فایل جدید است و git هنوز نمی‌داند که باید تغییرات این فایل را دنبال کند و یا آنها را نادیده بگیرد. برای تایید فایل جدید لازم است آن را وارد (stage) کنیم.

۵٫ استقرار (git add – (Staging

در git مفهومی تحت عنوان “منطقه شروع عملیات” (staging area) وجود دارد. می‌توانید آن را همچون یک بوم خالی تصور کنید که قرار است تغییراتی که انجام خواهید داد را نگه دارد. در ابتدا خالی است اما شما می‌توانید فایل‌ها را به آن اضافه کنید (و یا حتی چند سطر تنها یا قسمتی از فایل‌ها). این کار با دستور git add انجام می‌شود و در نهایت با استفاده از دستور git commit همه تغییرات اعمال می‌شود.

در مثالی که ما مطرح کردیم، تنها یک فایل وجود دارد، پس آن را اضافه می‌کنیم:

$ git add hello.txt

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

$ git add -A

اگر دوباره وضعیت را بررسی کنیم، این‌بار باید نتیجه‌ای متفاوت از قبل را مشاهده کنیم.

$ git status

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached ..." to unstage)

    new file:   hello.txt

فایل ما برای اعمال آماده است. پیغام وضعیت به ما می‌گوید که چه تغییراتی در مورد فایل‌هایی که در منطقه شروع هستند، اتفاق افتاده است. در مورد مثال ما اضافه شدن فایل جدید است (new file). اما وابسته به اینکه چه تغییراتی پس از آخرین دستور git add اتفاق افتاده است، می‌تواند modified یا deleted باشد.

۶٫ اعمال کردن (git commit – (Commiting

یک commit نشان دهنده‌ی وضعیت مخزن ما در یک نقطه‌ی مشخص از زمان است. مانند یک snapshot است، می‌توانیم به آن برگردیم و یا ببینیم زمانی که آن را گرفتیم، چه چیزی در آن بوده است.

برای ایجاد یک commit جدید، ما باید حداقل یک تغییر اضافه شده در منطقه شروع داشته باشیم (که تنها با دستور git add می‌توان این کار را انجام داد) و سپس دستور زیر را اجرا می‌کنیم:

$ git commit -m "Initial commit."

این دستور یک commit جدید با تمام تغییراتی که در منطقه شروع بود، ایجاد می‌کند (اضافه شدن hello.txt). بخش -m "Initial commit." که در دستور وجود دارد، توضیحات دلخواه کاربر است که تغییرات انجام شده را خلاصه می‌کند.  بسیار خوب خواهد بود که همواره پیغام‌های معناداری برای commit های خود بنویسید.

---

مخزن‌های راه دور (Remote)

در حال حاضر commit ما به صورت محلی است – تنها در پوشه git. وجود دارد. با وجود آنکه یک مخزن محلی به خودی خود سودمند است، در بسیاری از موارد، ما قصد داریم کارهایمان را به اشتراک بگذاریم و آنها را روی یک سرور یا سرویس میزبانی مخزن قرار دهیم.

۱٫ اتصال به مخزن راه دور – git remote add

برای آنکه چیزی را روی مخزن راه دور آپلود کنیم، ابتدا باید به آن متصل شویم. به شما توصیه می‌کنیم که مخزن خالی خود را در GitHub ، BitBucket یا سرویس دیگری که می‌شناسید ایجاد نمایید. ثبت نام و راه‌اندازی اولیه ممکن است کمی زمان ببرد، اما تمام این سرویس‌ها راهنماهای گام به گامی برای کمک به شما دارند.

برای متصل کردن مخزن محلی‌مان به مخزنی که در GitHub ایجاد کرده‌ایم، دستور زیر را در ترمینال اجرا می‌کنیم:

# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/.../awesome-project.git

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

۲٫ آپلود به سرور – git push

حالا زمان آنست که commit های محلی خود را به سرور منتقل کنیم. این فرآیند push نامیده می‌شود و هر زمان که بخواهیم مخزن راه دور را به‌روز کنیم، انجام می‌شود.

دستور git برای انجام این عمل git push است و دو پارامتر می‌گیرد – نام مخزن راه دور (که در اینجا آن را origin نامیدیم) و نام شاخه (branch) ای که می‌خواهیم داده‌ها به آن وارد شوند (شاخه‌ی پیش‌فرض برای هر مخزن master نام دارد). در مورد شاخه‌ها بعدتر توضیح می‌دهیم.

$ git push origin master

Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/.../awesome-project.git
 * [new branch]      master -> master

وابسته به سرویسی که از آن استفاده می‌کنید، شما باید هویت خودتان را تایید کنید تا push از آن طریق انجام شود. اگر همه‌چیز درست باشد، وقتی از طریق مرورگر وارد مخزن راه دوری که ایجاد کرده‌اید می‌شوید، فایل hello.txt باید آنجا موجود باشد.

۳٫ کپی گرفتن (Cloning) از یک مخزن – git clone

به این ترتیب و در این نقطه، دیگران می‌توانند مخزن راه دور شما در Github را ببینند و مرور کنند. آنها می‌توانند با استفاده از دستور git clone یک نسخه‌ی کامل از پروژه‌ی شما را به صورت محلی برای خود داشته باشند:

$ git clone https://github.com/.../awesome-project.git

یک مخزن محلی به صورت خودکار ایجاد می‌شود که با نسخه github به عنوان یک مخزن راه دور پیکربندی شده است.

۴٫ گرفتن تغییرات از سرور – git pull

اگر شما مخزن خود را به‌روز کنید، دیگران می‌توانند تغییرات شما را با تک دستور pull دانلود کنند:

$ git pull origin master

From https://github.com/.../awesome-project
 * branch            master     -> FETCH_HEAD
Already up-to-date.

در مثال ما، از آنجایی که تغییری از زمان کپی گرفتن ایجاد نشده است، هیچ تغییری برای دانلود وجود ندارد.

---

شاخه‌ها (Branches)

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

• همانطور که در حال انجام کارهایتان هستید، نسخه‌ی باثبات (stable) از کد شما آسیبی نخواهد دید.
• ویژگی‌های زیادی می‌توانند با اطمینان توسط افراد مختلف به طور همزمان توسعه داده شوند.
• توسعه‌دهندگان می‌توانند هر کدام روی شاخه‌ی مربوط به خود کار کنند، بدون آنکه این ریسک وجود داشته باشد که تغییرات آنها روی کد دیگران و یا تغییرات دیگران روی کد آنها اثر بگذارد.
• وقتی در مورد بهترین روش مطمئن نیستید، می‌توانید نسخه‌های متفاوتی از یک ویژگی در شاخه‌های مختلف داشته باشید و بعدتر آنها را با هم مقایسه کنید.

۱٫ ایجاد شاخه‌های جدید – git branch

شاخه‌ی پیش‌فرض در هر مخزن  master نامیده می‌شود. برای ایجاد شاخه‌های جدید از دستور git branch <name> استفاده کنید:

$ git branch amazing_new_feature

به این ترتیب تنها یک شاخه‌ی جدید ایجاد شده است که در این لحظه دقیقا عین همان شاخه‌ی master ما است.

۲٫ جابه‌جا شدن بین شاخه‌ها – git checkout

حالا اگر مجدد دستور git branch را اجرا کنیم، خواهیم دید که دو گزینه در دسترس هستند:

$ git branch
  amazing_new_feature
* master

شاخه‌ی فعلی که با علامت ستتاره مشخص شده، شاخه‌ی master است. با این حال ما تصمیم داریم روی ویژگی جدیدمان کار کنیم، پس نیاز داریم که به شاخه‌ی دیگری برویم. این عمل با دستور git checkout انجام می‌شود که یک پارامتر هم به عنوان نام شاخه‌ای که می‌خواهیم به آن منتقل شویم، انتظار دارد.

$ git checkout amazing_new_feature

۳٫ ادغام شاخه‌ها – git merge

“ویژگی جدید شگفت‌انگیز” ما تنها یک فایل متنی به نام feature.txt خواهد بود. ما آن را ایجاد می‌کنیم، اضافه می‌کنیم و در نهایت commit می‌کنیم.

$ git add feature.txt
$ git commit -m "New feature complete."

ویژگی جدید ما کامل شده است، حالا می‌توانیم به شاخه‌ی master بازگردیم.

$ git checkout master

حالا چنانچه پروژه خود را در file browser باز کنیم، متوجه می‌شویم که فایل feature.txt ناپدید شده است. علت این است که ما به شاخه‌ی master برگشته‌ایم و چنین فایلی در اینجا ایجاد نشده بود. برای آوردن آن فایل، لازم است که با دستور git merge دو شاخه را با هم ادغام کنیم. بنابراین تغییراتی که در شاخه‌ی amazing_new_feature ایجاد شده بودند در نسخه‌ی اصلی پروژه اعمال می‌شوند.

git merge amazing_new_feature

شاخه‌ی master به‌روز شده است. شاخه‌ی awesome_new_feature دیگر مورد نیاز نیست و می‌توانیم آن را حذف کنیم.

git branch -d amazing_new_feature

---

کمی حرفه‌ای‌تر

در آخرین بخش از این آموزش، می‌خواهیم نگاهی به تکنیک‌ها و روش‌هایی پیشرفته‌تر داشته باشیم که به احتمال زیاد، سودمند و کاربردی خواهند بود.

۱٫ بررسی تفاوت و تمایز بین commit ها

هر commit دارای یک id منحصر به فرد است که مجموعه‌ای از اعداد و حروف است. برای اینکه لیستی از commit ها و id های آنها را ببینیم می‌توانیم از دستور git log استفاده کنیم:

$ git log

commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date:   Mon May 30 17:15:28 2016 +0300

    New feature complete

commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date:   Mon May 30 16:30:04 2016 +0300

    Added content to hello.txt

commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date:   Sat May 28 17:52:14 2016 +0300

    Initial commit

همانطور که می‌بینید، id ها واقعا طولانی هستند. اما هنگامی که می‌خواهید با آنها کار کنید، نیازی به کپی کردن تمام رشته نیست و معمولا چند کاراکتر و نشانه‌ی اول کافی هستند.

برای اینکه ببینیم چه چیزی در یک commit جدید بوده است، دستور git show [commit] را اجرا می‌کنیم:

$ git show b10cc123

commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date:   Mon May 30 16:30:04 2016 +0300

    Added content to hello.txt

diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -۰,۰ +۱ @@
+Nice weather today, isn't it?

برای دیدن اختلاف بین هر دو commit از دستور git diff با ترکیب [commit-from]..[commit-to] استفاده می‌کنیم (نمونه‌ی آن را در زیر می‌بینید):

$ git diff 09bd8cc..ba25c0ff

diff --git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -۰,۰ +۱ @@
+Nice weather today, isn't it?

ما اولین commit را با آخرین مقایسه کردیم؛ پس همه‌ی تغییراتی که تا به حال انجام شده است را می‌بینیم. معمولا استفاده از دستور git difftool راحت‌تر است چرا که به شکل گرافیکی تمام تفاوت‌ها را به صورت نظیر به نظیر نمایش می‌دهد.

۲٫ بازگرداندن یک فایل به نسخه قبلی (Reverting)

git این امکان را به ما می‌دهد که هر فایل دلخواه را به حاتی برگردانیم که در یک commit مشخص بوده است. این کار با دستور git checkout انجام می‌شود، که قبلا از آن برای جابه‌جایی بین شاخه‌ها استفاده کرده بودیم، اما در عین حال برای جابه‌جایی بین commit ها کاربرد دارد (این در git شایع است که یک دستور برای چند کار ظاهرا غیر مرتبط استفاده شود).

در مثال زیر می‌خواهیم فایل hello.txt را به وضعیتی برگردانیم که در اولین commit داشت. بدین منظور باید id آن commit که می‌خواهیم به آن برگردیم و همچنین مسیر کامل فایل خود را ارائه کنیم.

$ git checkout 09bd8cc1 hello.txt

۳٫ اصلاح یک commit

اگر شما متوجه شدید که اشتباهی در پیغام commit خود داشته‌اید، یا اینکه فراموش کردید یک فایل را اضافه کنید و درست بعد از commit به یاد آوردید، در این صورت به آسانی می‌توانید با دستور  git commit --amend آن را اصلاح کنید. این دستور تمام چیزهایی که در آخرین commit بودند را به منطقه شروع عملیات برمی‌گرداند و تلاش می‌کند که یک commit جدید ایجاد کند. به این ترتیب این شانس به شما داده می‌شود که پیغام commit خود را اصلاح کنید و یا فایل‌های بیشتری را به منطقه‌ی شروع اضافه کنید.

برای اصلاحات پیچیده‌تر که در آخرین commit نیستند (یا اینکه شما تغییرات خود را push کرده‌اید)، باید از دستور git revert استفاده کنید. این دستور تمام تغییراتی که در آن commit ایجاد شده‌اند را برعکس کرده و یک commit جدید ایجاد می‌کند که کاملا مخالف قبلی است.

جدیدترین commit با نام مستعار HEAD قابل دسترسی است.

$ git revert HEAD

برای سایر commit ها بهتر است از id آن‌ها استفاده کنیم.

$ git revert b10cc123

هنگامی که به commit های گذشته بازمی‌گردید، این نکته را به یاد داشته باشید که امکان بروز ناسازگاری در ادغام محتمل است. چنین چیزی زمانی اتفاق میفتد که فایل در یکی دیگر از commit های اخیر نیز دچار تغییر شده است و حالا Git نمی‌تواند خطوط صحیح برای بازگشت را پیدا کند، چرا که آنها دیگر وجود ندارند.

۴٫ برطرف کردن ناسازگاری ادغام (Resolving Merge Conflicts)

جدا از سناریویی که در بخش قبل شرح داده شد، ناسازگاری‌ها معمولا هنگام ادغام شاخه‌ها و یا زمانی که کارهای فرد دیگری را pull می‌کنیم رخ می‌دهند. گاهی اوقات این ناسازگاری‌ها توسط git به طور خودکار اداره و کنترل می‌شوند اما در مواقع دیگر، فردی که با آن مواجه شده باید تصمیم بگیرد (و معمولا انتخاب کند) که کدام کد را نگه دارد و کدام را حذف کند.

اجازه دهید مثالی را مطرح کنیم که در آن می‌خواهیم دو شاخه با نام‌های john_branch و tim_branch را با هم ادغام کنیم. جان و تام هر دو در یک فایل، تابعی نوشته‌اند که تمام اعضای یک آرایه را نمایش می‌دهد.

جان از یک حلقه‌ی for استفاده کرده است:

// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
    console.log(arr[i]);
}

تام استفاده از forEach را ترجیح داده است:

// Use forEach to console.log contents.
arr.forEach(function(item) {
    console.log(item);
});

هر دوی آنها کد خود را در شاخه‌ی مربوطه commit کرده اند. حالا اگر بخواهند دو شاخه را با هم ادغام کنند، با پیغام خطایی که در زیر می‌آید مواجه می‌شوند:

$ git merge tim_branch 

Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.

git به صورت خودکار قادر به ادغام شاخه‌ها نبود، پس حالا توسعه‌دهندگان باید به صورت دستی ناسازگاری را برطرف (resolve) کنند. اگر آن‌ها فایلی را که ناسازگاری در آن رخ داده باز کنند، خواهند دید که git نشانگری را روی خطوطی که ناسازگار هستند اضافه کرده است.

<<<<<<< HEAD
// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
    console.log(arr[i]);
}
=======
// Use forEach to console.log contents.
arr.forEach(function(item) {
    console.log(item);
});
>>>>>>> Tim's commit.

بالای ===== ما commit جاری HEAD را خواهیم داشت و پایین آن بخش ناسازگار را داریم. به این ترتیب به وضوح می‌توانیم تفاوت‌ها را ببینیم و تصمیم بگیریم که کدام نسخه بهتر است و یا آنکه چیز جدیدی بنویسیم. در این مثال ما روش دوم را انتخاب می‌کنیم و تمام کد را بازنویسی می‌کنیم. سپس نشانگرها را حذف می‌کنیم تا به git اعلام کنیم که کارمان انجام شده است.

// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());

وقتی همه‌چیز انجام شد، باید یک commit ادغام انجام دهیم تا فرآیند به اتمام برسد.

$ git add -A
$ git commit -m "Array printing conflict resolved."

همانطور که می‌بینید این روند کاملا خسته کننده است و می‌تواند در پروژه‌های بزرگ بسیار دشوار باشد. بسیاری از توسعه دهندگان ترجیح می‌دهند برای رفع ناسازگاری‌ها از یک واسط گرافیکی (GUI client) استفاده کنند که کارها را خیلی ساده‌تر می‌کند. برای اجرای یک واسط گرافیکی از دستور git mergetool استفاده کنید.

۵٫ راه‌اندازی gitignore.

در بسیاری از پروژه‌ها، فایل‌ها یا پوشه‌هایی وجود دارند که ما هرگز نمی‌خواهیم آن‌ها را commit کنیم. ما با ایجاد یک فایل gitignore. مطمئن می‌شویم که آن‌ها به صورت تصادفی در دستور git add -A ما قرار نمی‌گیرند:

1. به صورت دستی یک فایل متنی با عنوان gitignore. ایجاد کنید و آن را در پوشه‌ی پروژه‌ی خود ذخیره نمایید.
2. درون آن، نام فایل‌ها / پوشه‌هایی که می‌خواهید نادیده گرفته شوند، لیست کنید. هر کدام را در یک خط جدید بنویسید.
3. خود فایل gitignore. باید اضافه، commit و push شده باشد، درست به مانند هر فایل دیگری که در پروژه وجود دارد.

در زیر مثال‌های خوبی از فایل‌هایی که باید نادیده گرفته شوند می‌آوریم:

• log files
• task runner builds
• the node_modules folder in node.js projects
• folders created by IDEs like Netbeans and IntelliJ
• personal developer notes

محتوای فایل gitignore. که تمام موارد بالا را دربربگیرد، شبیه به این می‌شود:

*.log
build/
node_modules/
.idea/
my_notes.txt

قرار دادن / در آخر بعضی خطوط، به این معناست که این یک پوشه است و ما هر چیزی درون آن است به طور تو در تو نادیده می‌گیریم. علامت * شبیه به یک wild card عمل می‌کند.

---

جمع‌بندی

به پایان آموزش‌مان در مورد git رسیدیم! تمام تلاش خود را انجام دادیم که تنها مهمترین اطلاعاتی که شما نیاز دارید را در کوتاهترین و مختصرترین شکل ممکن در اختیارتان قرار دهیم.

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

• مستندات رسمی git که شامل یک کتاب کامل و درس‌های ویدئویی می‌شود – اینجا را ببینید.
• مجموعه‌ای از آموزش‌ها و مقالات Atlassian – اینجا را ببینید.
• لیستی از واسط‌های گرافیکی برای git – اینجا را ببینید.
• Git cheat sheet در یک فایل PDF – اینجا را ببینید.
• ابزار آنلاین برای ایجاد فایل‌های gitignore. – اینجا را ببینید.

---

منبع: Learn Git in 30 Minutes
ترجمه: سیدمحمدحسین طباطبایی بالا