راهنمای مقدماتی گیت (git)

گیت (git) یک سیستم کنترل نسخۀ توزیع شده، متن‌باز و رایگان است. در این تعریف سه عبارت مهم وجود دارد که هر یک را به صورت جدا توضیح می‌دهیم:

• سیستم کنترل: این یعنی گیت یک سیستم نظارت محتوا بوده که قادر به ذخیره محتوا است. البته این محتوا اغلب کدهای برنامه‌نویسی است ولی سایر اشکال محتوا هم می‌تواند باشد؛
• سیستم کنترل نسخه (Version Control System): کدهایی که در گیت ذخیره می‌شوند به مرور زمان تغییراتی در آن‌ها داده می‌شود که بین اهالی نرم‌افزار به نسخه‌های مختلف کد مشهور است. یک برنامه‌نویس یا در تیم‌ها چندین توسعه‌دهنده می‌توانند کدهای ذخیره شده را تغییر دهند یا کدهای جدیدی به آن اضافه کنند. بنابراین گیت راهکاری برای مدیریت نسخه‌های مختلف کد و نگه‌داری تاریخچۀ تغییرات صورت گرفته است؛
• سیستم کنترل نسخۀ توزیع شده (Distributed Version Control System): گیت یک مخزن محلی ذخیره‌سازی کد روی سیستم کاربران دارد که به آن local repository یا به اختصار local repo گفته می‌شود و یک مخزن راه‌دور یا ریموت که روی سرور ذخیره می‌شود و به آن remote repo گفته می‌شود. این یعنی کدها و تغییرات اعمال شده در یک سرور مرکزی ذخیره نمی‌شوند. کدها در بین مخازن محلی سیستم کاربران توزیع شده است. بعداً در این مورد بیشتر توضیح می‌دهیم.

چرا به سیستم کنترل نسخه‌ای مثل گیت نیاز داریم؟

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

نیازمندی‌های پروژه به مرور زمان تغییر می‌کند وامکان انجام تغییرات هم هست. باید راهی وجود داشته باشد تا این تغییرات را جایی ذخیره کنیم که اگر اشتباهاً تغییری دادیم به راحتی بتوانیم به نسخه‌های قبل برگردیم. سیستم‌های کنترل نسخه این توانایی را به ما می‌دهند.

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

شروع کار

به جای اینکه همین ابتدا، حجم زیادی از توضیحات را ارائه دهیم، بهتر است مفاهیم را کم کم در قالب مثال‌ها منتقل کنیم.

دانلود گیت

از این لینک گیت را دانلود و نصب کنید. برای اطمینان از نصب صحیح، دستور زیر را در cmd وارد کنید تا نسخۀ گیت به شما نمایش داده شود:

git --version

ساخت یک مخزن محلی (local git repo)

در جایی از کامپیتور یک فولدر خالی ایجاد کنید مثلا با نام simple-git-demo

فولدر را باز کنید و با دستور پایین یک مخزن محلی یا لوکال در آن ایجاد کنید:

cd simple-git-demo 
git init

روبروی دستور cd باید آدرس آن فولدر را وارد کنید تا Working Folder در cmd به فولدر simple-git-demo تغییر کند. هربار که cmd را ببندید این آدرس را باید مجددا وارد کنید. دستور git init یک مخزن لوکال به فولدر شما اضافه می‌کند. init سرنام initialize است.

اضافه کردن اندکی کد

داخلِ فولدر یک فایل متنی به نام demo.txt ایجاد کنید و متن زیر را به آن اضافه کنید:

Initial Content

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

Staging و commiting

در فرهنگ گیت به اضافه کردن کدها به مخزن لوکال اصطلاحاً commit یا کامت کردن گفته می‌شود. قبل از کامت کردن، آن محتوا در ناحیه staging قرار دارد. staging area منطقه‌ای است که تمام فایل‌های پروژه را برای کامت شدن زیرنظر دارد. اگرفایل‌های پروژه را به این ناحیه اضافه نکنید قادر به کامت کردنشان نخواهید بود. این مکانیزم به توسعه‌دهنده امکان می‌دهد تا کنترل خوبی روی این موضوع که چه فایل‌هایی باید کامت شوند داشته باشد.

Staging

برای استیج کردن یک فایل از دستور زیر استفاده کنید:

git add demo.txt

برای اضافه کردن چندین فایل به صورت همزمان می‌توانید دستور زیر را وارد کنید:

git add file1 file2 file3

برای اضافه کردن تمام فایل‌های موجود در پروژه از دستور پایین استفاده کنید:

git add .

در استفاده از این دستور دقت لازم را داشته باشید چون هر فایل و فولدری در پروژه را به staging area اضافه می‌کند.

Committing

برای کامت کردن از دستور پایین استفاده کنید:

git commit -m "Initial Commit"

initial Commit پیغام کامت است که می‌تواند هر چیز دیگری هم باشد. در انتخاب پیغام دقت لازم را داشته باشید چون بعداً از روی همین کامت‌ها می‌فهمید که در هر نسخه از کد چه چیزهایی وجود دارد. به m- سوئیچ گفته می‌شود. هر دستوری در گیت سوئیچ‌های مختلفی دارد. مثلاً در اینجا به دستور گیت می‌گوییم که قصد نوشتن یک پیغام را داریم بنابراین از سوئیچ m- که مخفف message است استفاده می‌کنیم.

git status و git log

اکنون محتوای demo.txt را تغییر دهید تا به صورت زیر تبدیل شود:

Initial Content 
Adding more Content

status

از git status برای یافتن اطلاعاتی دربارۀ فایل‌های ویرایش شده و فایل‌هایی که در منطقۀ staging قرار دارند استفاده می‌کنیم. این دستور اطلاعات دیگری هم نشان می‌دهد که در اینجا از آن‌ها صرفنظر می‌کنیم:

git status

وضعیت اعلام شده بیان می‌کند که تغییراتی در فایل demo.txt اعمال شده ولی هنوز به staging area اضافه نشده است. با دستور add این فایل را مجددا به منطقۀ staging اضافه می‌کنیم و با دستور commit تغییرات صورت گرفته را کامت می‌کنیم:

git add demo.txt 
git commit -m "demo.txt file is modified"

Log

دستور git log لیست تمام کامت‌های انجام شده تا آن لحظه را از جدید به قدیم به شما نمایش می‌دهد:

git log

این دستور صاحب کامت، تاریخ ارسال و پیام هر کامت را نمایش می‌دهد. با چنین اطلاعاتی به راحتی می‌توانیم بفهمیم چه کسی چه کاری کجا انجام داده است.

Branches (شاخه‌ها یا انشعاب)

تا الان هنوز شاخه یا انشعاب جدیدی ایجاد نکردیم. گیت به صورت پیش‌فرض تمام تغییرات را در شاخۀ master اعمال می‌کند. شاخه چیزی نیست جزء یک اشاره‌گر به آخرین کامت در مخزن گیت. بنابراین شاخۀ مستر ما اکنون اشاره‌گری به کامت آخر (کامت دوم) یعنی “demo.txt file is modified” است. سوال این است که چرا به چندین انشعاب جدا نیاز داشته باشیم؟

انشعاب‌های مختلف برای توسعۀ موازی و همزمان ضروری هستند. برای درک بهتر به این تصویر نگاه کنید:

در شروع کار کامت ۱ و ۲ در شاخۀ مستر اضافه شده است. بعد از کامت ۲ شاخۀ جدیدی به نام Test ایجاد شده که کامت ۳ و ۴ در ادامۀ آن اضافه شده است. به صورت همزمان کامت ۳ و ۴ دیگری به شاخۀ مستر اضافه شده است. به راحتی می‌توانیم ببینیم که بعد از کامت ۲، دو شاخۀ مجزا در توسعۀ کدها شکل گرفته است. این دو شاخه از هم جدا بوده و هر زمان با دستور git merge قابل ادغام هستند. در مورد ادغام بعداً صحبت می‌کنیم.

ساخت یک انشعاب جدید در مخزن لوکال

با دستور زیر یک شاخۀ جدید به نام test ایجاد کنید:

git branch test

دستور فوق شاخۀ test را برای شما ایجاد می‌کند ولی هنوز روی شاخۀ مستر قرار دارید. برای سوئیچ کردن به شاخۀ test باید آن شاخه را checkout کنید به این صورت:

git checkout test

اکنون روی شاخۀ test هستیم و تمام کامت‌ها روی همین شاخه ذخیره خواهد شد. برای فهرست کردن تمام شاخه‌ها از دستور زیر استفاده کنید:

git branch

انجام چند کامت در شاخۀ جدید

با اضافه کردن مقداری محتوای جدید، فایل demo.txt را تغییر دهید:

Initial Content 
Adding more Content 
Adding some Content from test Branch

اکنون stage و کامت کنید:

git add demo.txt 
git commit -m "Test Branch Commit"

این کامت در شاخۀ test اتفاق افتاده و اکنون با یک کامت از شاخۀ مستر جلو افتاده است. دقت کنید شماره‌گذاری کامت‍ها در شاخۀ جدید در ادامۀ کامت‌هایی است که در شاخۀ مستر قرار دارند. در واقع با ساخت هر انشعاب جدید، کامت‌هایی که تا آن لحظه در شاخۀ مستر وجود دارند به ارث برده می‌شود. برای اطمینان از این حرف با دستور git log فهرست کامت‌ها را بررسی کنید.

Merging

اکنون شاخۀ test با یک کامت از مستر جلو افتاده است. فرض کنید می‌خواهیم تمام تغییرات اعمال شده در شاخۀ test را بخواهیم به شاخۀ مستر وارد کنیم. اینجاست که دستور git merge به درد می‌خورد.

برای ادغام کدهای شاخۀ test در شاخۀ مستر قدم‌های زیر را طی کنید:

ابتدا به شاخۀ مستر بروید:

git checkout master

سپس دستور merge را روی شاخۀ test اجرا کنید:

git merge test

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

اکنون مجدداً دستور git log را وارد کنید. همانطور که می‌بینید شاخۀ مستر حالا سه کامت دارد.

مخزن ریموت

تا الان فقط روی مخزن لوکال یا local repo کار می‌کردیم. هر برنامه‌نویس روی مخزن خودش کار می‌کند ولی در نهایت تغییرات را به مخزن ریموت یا remote repo ارسال یا اصطلاحاً پوش (Push) می‌کنند. وقتی کدی در ریموت ریپو قرار می‌گیرد سایر توسعه‌دهندگان می‌توانند ببیند و مجدداً اصلاح کنند.

گیت‌هاب

برای ذخیره ریموت کدها راه‌های مختلفی هست که گیت‌هاب، گیت‌لب و بیت‌باکت از بقیه محبوب‌تر هستند. ما و بسیاری دیگر از توسعه‌دهندگان از گیت‌هاب استفاده می‌کنیم. پس همین حالا به گیت‌هاب بروید و یک حساب جدید درست کنید. بعد از پایان مراحل ثبت‌نام در صفحۀ اصلی روی Start a Project کلیک کنید تا یک مخزن جدید گیت ایجاد شود. یه مخزن جدید نامی اختصاص دهید و دکمۀ Create Repository را بزنید. ما نام git-blog-demo را انتخاب می‌کنیم. این کار یک مخزن ریموت در گیت‌هاب ایجاد می‌کند که در هنگام باز کردن آن با چیزی شبیه تصویر زیر مواجه خواهید شد:

آدرس URL ریپوزیتوری هایلایت شده است. این آدرسی است که برای پوش کردن تغییرات مخزن محلی به آن لازم دارید. برای مطلع کردن مخزن محلی از آدرس مخزن ریموت دستور زیر را وارد کنید:

git remote add origin [repository url]

Git Push

برای پوش کردن کدهای مخزن محلی به مخزن ریموت از این دستوراستفاده کنید:

git push -u origin master

دستور بالا تمام کدهای واقع در شاخۀ مسترِ مخزن محلی (که روی سیستم شما قرار دارد) را به شاخۀ مستر در مخزن ریموت (که روی سرور قرار دارد) منتقل می‌کند.

سایر دستورات

Git Pull

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

git pull origin master

Git Clone

از این دستور برای کپی کردن یک نسخه از مخزن ریموت روی کامپیوتر شخصی استفاده می‌شود. مثلاً از پروژه‌ای در گیت‌هاب خوشتان آمده و دوست دارید آخرین نسخۀ کدها را به کامپیوتر منتقل کنید تا روی آن کار انجام دهید. برای این کار دستور پایین را وارد کنید:

git clone [repository url]

در مقالات بعدی به قسمت‌های دیگری از گیت خواهیم پرداخت.