آموزش جامع Git و GitHub: راهنمای گام به گام برای مبتدیان

آشنایی با گیت و گیت‌هاب

در دنیای پرشتاب برنامه‌نویسی امروز، مدیریت تغییرات کد و همکاری تیمی اهمیت حیاتی دارد. در این راهنما، قصد داریم به دو ابزار بسیار هیجان‌انگیز و کاربردی به نام‌های گیت (Git) و گیت‌هاب (GitHub) بپردازیم. اغلب این دو نام در کنار هم شنیده می‌شوند، اما در واقعیت، گیت و گیت‌هاب دو مفهوم کاملاً متفاوت هستند. به زبان ساده، گیت ابزاری است که روی کامپیوتر شخصی شما اجرا می‌شود و تغییرات فایل‌هایتان را ردیابی می‌کند، در حالی که گیت‌هاب یک پلتفرم آنلاین است که به شما امکان می‌دهد پروژه‌های گیت خود را در فضای ابری ذخیره کرده و با دیگران همکاری کنید. گیت به تنهایی نیز به خوبی کار می‌کند، اما گیت‌هاب کار تیمی، اشتراک‌گذاری و پشتیبان‌گیری را بسیار آسان‌تر می‌سازد. آن‌ها به هم متصل‌اند، اما ماهیتشان کاملاً متفاوت است. می‌توان این‌طور فکر کرد که گیت "قهوه" است و گیت‌هاب "قهوه‌خانه‌ای" است که آن قهوه در آن سرو می‌شود. در ادامه، دقیقاً خواهید دید که این تفاوت‌ها و ارتباطات چگونه عمل می‌کنند.

گیت چیست؟ سیستم کنترل نسخه قدرتمند شما

گیت، یک سیستم کنترل نسخه (Version Control System - VCS) بسیار قدرتمند است که به طور مداوم و ۲۴ ساعته، ۷ روز هفته و ۳۶۵ روز سال، هر تغییری را که در فایل‌هایتان ایجاد می‌کنید، ردیابی و ثبت می‌کند. این یعنی گیت دقیقاً ثبت می‌کند که چه چیزی تغییر کرده، چه زمانی تغییر کرده، چه کسی آن را تغییر داده و حتی در کجا این تغییر رخ داده است. مهم نیست با چه نوع فایلی سروکار دارید؛ می‌تواند یک تصویر، یک فایل متنی، کد جاوااسکریپت، PHP، پایتون یا حتی یک ویدیو باشد. گیت هر یک از این تغییرات را به دقت پیگیری می‌کند.

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

گیت‌هاب چیست؟ پلتفرم همکاری و ذخیره‌سازی ابری

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

این دقیقاً جایی است که گیت‌هاب وارد عمل می‌شود. وقتی پروژه کامل شد، باید کار همه را در یک مکان ترکیب کنید تا تمام آن تغییرات با هم ادغام شوند. برای این منظور، به یک مرکز آنلاین نیاز دارید که همه بتوانند به‌روزرسانی‌های خود را در آن آپلود کنند. شما کارتان را به آنجا push می‌کنید، هم‌تیمی‌تان نیز کار خود را push می‌کند و گیت‌هاب همه آن‌ها را گرد هم می‌آورد. گیت‌هاب به عنوان آن سرور آنلاین مرکزی عمل می‌کند که کل پروژه تیم شما در آن قرار دارد و به این ترتیب، دیدن، ویرایش و اشتراک‌گذاری به‌روزرسانی‌ها در یک مکان واحد و بدون سردرگمی برای همه آسان می‌شود. علاوه بر گیت‌هاب، پلتفرم‌های محبوب دیگری مانند گیت‌لب (GitLab) و بیت‌باکت (Bitbucket) نیز برای میزبانی مخازن گیت شما وجود دارند. با این حال، گیت‌هاب محبوب‌ترین و پرکاربردترین پلتفرم در جامعه توسعه‌دهندگان، به ویژه در پروژه‌های متن‌باز، باقی مانده است.

معماری گیت: از سیستم محلی تا فضای ابری

برای شروع کار با گیت، درک مفهوم اصلی آن و ساختار داخلی یا معماری آن ضروری است. گیت عمدتاً به دو بخش اصلی "محلی" (Local) و "ریموت" (Remote) تقسیم می‌شود. بخش "محلی" به کامپیوتر خود شما اشاره دارد، جایی که تمام کارهایتان را انجام می‌دهید. این همان جایی است که فایل‌ها، کدها و هر تغییری که ایجاد می‌کنید، ذخیره می‌شوند. از سوی دیگر، بخش "ریموت" در فضای ابری قرار دارد. این جایی است که شما کار محلی خود را push یا آپلود می‌کنید. در بیشتر موارد، وقتی از "ریموت" صحبت می‌کنیم، معمولاً منظورمان گیت‌هاب است.

بخش محلی شامل سه مرحله اصلی است:

1. دایرکتوری کاری (Working Directory): پوشه‌ای روی کامپیوتر شما که در آن به صورت فعال روی پروژه کار می‌کنید، کد می‌نویسید، فایل‌های جدید ایجاد می‌کنید یا فایل‌های موجود را تغییر می‌دهید.


2. منطقه Staging (Staging Area): یک فضای میانی و موقت که فایل‌ها پس از اتمام کار در دایرکتوری کاری، در آن قرار می‌گیرند. با دستور git add، تغییرات خود را به اینجا منتقل می‌کنید و اعلام می‌کنید که آماده ذخیره نهایی هستند.


3. مخزن محلی (Local Repository): جایی که تمام نسخه‌های فایل‌ها و تاریخچه کامل تغییرات آن‌ها ذخیره می‌شود. پس از بررسی در منطقه Staging، تغییرات با دستور git commit به صورت دائمی در مخزن محلی ذخیره می‌شوند. این عمل به منزله ثبت یک نسخه ضبط‌شده از تاریخچه پروژه شماست.

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

جریان کار و معماری گیت

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

معماری گیت: محلی و از راه دور

معماری گیت به طور عمده به دو بخش اصلی تقسیم می‌شود: محلی (Local) و از راه دور (Remote). بخش محلی به کامپیوتر شخصی شما اشاره دارد، جایی که تمام کارهای توسعه خود را انجام می‌دهید. این شامل فایل‌ها، کدها و تمام تغییراتی است که شما ایجاد می‌کنید و به صورت محلی ذخیره می‌شوند. از سوی دیگر، بخش از راه دور در فضای ابری قرار دارد. این مکانی است که شما کارهای محلی خود را به آنجا پوش (push) یا آپلود می‌کنید. در بیشتر موارد، وقتی از "از راه دور" صحبت می‌کنیم، معمولاً منظورمان گیت‌هاب (GitHub) است، پلتفرمی آنلاین که امکان ذخیره پروژه‌های گیت در فضای ابری و همکاری با دیگران را فراهم می‌کند. با اینکه گیت به تنهایی کاملاً کاربردی است، گیت‌هاب کار گروهی، اشتراک‌گذاری و پشتیبان‌گیری را بسیار آسان‌تر می‌کند.

گردش کار سه‌مرحله‌ای گیت در سیستم محلی

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

• دایرکتوری کاری (Working Directory): این پوشه‌ای روی کامپیوتر شماست که در آن مشغول کار بر روی پروژه خود هستید. در اینجا کد می‌نویسید، فایل‌های جدید ایجاد می‌کنید، فایل‌های موجود را تغییر می‌دهید و اصلاحات لازم را انجام می‌دهید. تمامی اقدامات شما در این مرحله انجام می‌شود.




• ناحیه آماده‌سازی (Staging Area): وقتی احساس می‌کنید "این نسخه خوب به نظر می‌رسد، می‌خواهم این تغییر را ذخیره کنم"، کار خود را به ناحیه آماده‌سازی منتقل می‌کنید. به عبارت ساده، وقتی کارتان در دایرکتوری کاری به پایان رسید، آماده‌سازی به این معناست که می‌گویید: "تغییرات من آماده هستند و می‌توانند به مرحله بعدی بروند." این مرحله، فضایی موقتی است که فایل‌ها بین دایرکتوری کاری و ذخیره نهایی در مخزن قرار می‌گیرند. این مرحله به شما فرصت می‌دهد تا قبل از نهایی کردن تغییرات، آن‌ها را بررسی، تنظیم یا حتی حذف کنید.




• مخزن محلی (Local Repository): در نهایت، فایل‌های آماده‌شده را به مخزن محلی ارسال می‌کنید. این فرآیند "کامیت" (commit) نامیده می‌شود که به معنای ذخیره دائمی و تأیید تغییرات شماست. کامیت کردن به معنی قفل کردن تغییرات به عنوان یک نسخه ثبت‌شده از تاریخچه پروژه شماست. مخزن محلی، پوشه‌ای خاص روی کامپیوتر شماست که تمام نسخه‌های فایل‌ها و تاریخچه کامل تغییرات آن‌ها را ذخیره می‌کند. در داخل این مخزن، گیت به طور خودکار فایل‌های سیستمی را ایجاد می‌کند که همه چیز، از جمله تغییرات، تاریخچه و کامیت‌ها را ردیابی می‌کنند. این پوشه پنهان (.git) هسته اصلی پروژه شماست و حاوی تمام داده‌های داخلی گیت است.

  
  

همگام‌سازی با مخزن از راه دور

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

دستورات اصلی مدیریت تغییرات

در دنیای برنامه‌نویسی، مدیریت تغییرات پروژه یک اصل اساسی برای حفظ پایداری و سازماندهی کدهاست. گیت (Git) به‌عنوان یک سیستم کنترل نسخه قدرتمند، این امکان را به شما می‌دهد تا تمامی تغییرات اعمال شده روی فایل‌هایتان را به‌دقت ردیابی، مدیریت و در صورت نیاز به نسخه‌های قبلی بازگردانید. در این بخش، به بررسی دستورات اصلی گیت می‌پردازیم که هر برنامه‌نویسی برای کنترل مؤثر پروژه‌های خود به آن‌ها نیاز دارد.

شناسایی و آماده‌سازی تغییرات: `git status` و `git add`

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

پس از ایجاد یا تغییر فایل‌ها، باید به گیت بگویید که قصد دارید این تغییرات را حفظ کنید. اینجاست که دستور git add وارد عمل می‌شود و تغییرات را از محیط کاری (Working Directory) به ناحیه آماده‌سازی (Staging Area) منتقل می‌کند. ناحیه آماده‌سازی، یک مرحله میانی برای بازبینی نهایی قبل از ذخیره‌سازی دائمی است. این دستور انواع مختلفی دارد:

• git add .: تمامی تغییرات (افزودن، اصلاح، حذف) را در دایرکتوری فعلی و زیرشاخه‌های آن به ناحیه آماده‌سازی می‌برد.


• git add -A یا git add --all: تمام تغییرات در کل مخزن را آماده می‌کند.


• git add <file>: فقط یک فایل مشخص را به ناحیه آماده‌سازی منتقل می‌کند.

درک این تفاوت‌ها اهمیت زیادی دارد، مثلاً git add * فقط فایل‌های جدید یا اصلاح‌شده را آماده می‌کند، اما حذف فایل‌ها را نادیده می‌گیرد، در حالی که git add . و git add -A حذف‌ها را نیز شامل می‌شوند.

ثبت دائمی نسخه‌ها و تاریخچه: `git commit` و `git log`

پس از اینکه تغییرات خود را در ناحیه آماده‌سازی بررسی کردید و از صحت آن‌ها اطمینان یافتید، نوبت به ثبت دائمی این تغییرات در مخزن محلی (Local Repository) می‌رسد. این فرآیند با دستور git commit انجام می‌شود. کامیت کردن مانند ذخیره نهایی کار است؛ تأیید می‌کنید که این نسخه از پروژه کامل و صحیح است و می‌خواهید آن را به‌عنوان یک نقطه عطف در تاریخچه پروژه ثبت کنید. پرچمدار -m به شما امکان می‌دهد تا یک پیام کوتاه و توصیفی برای هر کامیت اضافه کنید که توضیح می‌دهد چه تغییراتی انجام شده است. قبل از اولین کامیت، گیت از شما می‌خواهد که هویت خود را با استفاده از دستورات git config --global user.name "Your Name" و git config --global user.email "you@example.com" پیکربندی کنید تا اطلاعات شما در تاریخچه پروژه ثبت شود.

برای مشاهده تاریخچه تمامی کامیت‌ها و ردیابی نسخه‌های مختلف پروژه، از دستور git log استفاده می‌کنیم. این دستور اطلاعات کاملی از هر کامیت شامل ID کامیت، نویسنده، تاریخ و پیام کامیت را نمایش می‌دهد. اگر می‌خواهید تاریخچه را به‌صورت فشرده‌تر و خلاصه‌تر ببینید، می‌توانید از git log --oneline استفاده کنید که هر کامیت را در یک خط با ID کوتاه‌شده نمایش می‌دهد. این IDها برای بازگشت به نسخه‌های قبلی بسیار مفید هستند.

بازگردانی و مدیریت فایل‌ها: `git restore`, `git rm`, `git reset`

گاهی اوقات ممکن است لازم باشد تغییراتی را که هنوز کامیت نشده‌اند لغو کنید یا فایل‌هایی را از مخزن حذف نمایید. دستور git restore به شما کمک می‌کند تا تغییرات محلی (که هنوز به ناحیه آماده‌سازی نرفته‌اند یا از آن خارج شده‌اند) را به وضعیت آخرین کامیت بازگردانید. این دستور برای لغو تغییرات در یک فایل خاص (git restore <file>)، یک دایرکتوری، یا حتی تمامی فایل‌ها (git restore .) بسیار کارآمد است. همچنین، با استفاده از git restore --staged <file> می‌توانید فایلی را از ناحیه آماده‌سازی خارج کنید بدون اینکه تغییرات آن در محیط کاری از بین برود.

برای حذف فایل‌ها از مخزن گیت، از دستور git rm استفاده می‌شود. این دستور هم فایل را از سیستم فایل شما حذف می‌کند و هم حذف آن را برای کامیت بعدی آماده می‌سازد. اگر فایلی دارای تغییرات commit نشده باشد و بخواهید آن را اجباراً حذف کنید، می‌توانید از پرچمدار -f استفاده کنید (git rm -f <file>). در صورتی که بخواهید فایلی را از ردیابی گیت خارج کنید اما آن را از سیستم فایل خود حذف نکنید، git rm --cached <file> گزینه‌ی مناسبی است. برای حذف یک پوشه و تمامی محتویات آن، پرچمدار -r (recursive) را به کار می‌برید: git rm -r <folder>.

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

ذخیره‌سازی موقت تغییرات و لغو ایمن: `git stash` و `git revert`

گاهی در حال کار روی یک ویژگی جدید هستید که هنوز آماده کامیت نیست، اما ناگهان باید به یک شاخه دیگر سوئیچ کنید تا روی موضوعی فوری کار کنید. در چنین شرایطی، git stash راه‌حل شماست. این دستور تغییرات ناتمام شما را موقتاً کنار می‌گذارد و محیط کاری را تمیز می‌کند تا بتوانید به شاخه دیگری بروید. بعد از اتمام کار، با git stash pop می‌توانید تغییرات کنار گذاشته شده را بازگردانید و همزمان از لیست stash حذف کنید. اگر بخواهید تغییرات را بازگردانید اما آن‌ها را در لیست stash حفظ کنید، از git stash apply استفاده کنید. برای مشاهده لیست stashهای ذخیره‌شده، git stash list و برای حذف یک stash خاص، git stash drop به کار می‌روند.

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

شعبه‌بندی و رفع تضادها

قابلیت شعبه‌بندی (Branching) یکی از قدرتمندترین و مهم‌ترین ویژگی‌های گیت است. یک شاخه در گیت مانند یک خط توسعهٔ جداگانه است که در آن می‌توانید به صورت مستقل کار کنید. به طور معمول، شاخهٔ پیش‌فرض در پروژه‌ها، main نامیده می‌شود که نقطهٔ شروع همهٔ کارهاست. این شاخه، خط مرکزی توسعهٔ پروژه شماست.

مفهوم شعبه‌بندی و چرا از آن استفاده می‌کنیم؟

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

گیت دقیقاً به همین صورت کار می‌کند. به جای اینکه تغییرات را مستقیماً در شاخهٔ main اعمال کنید، یک شاخهٔ توسعه (مثلاً development) ایجاد می‌کنید که در آن تمام تغییرات خود را آزمایش و کامیت (commit) می‌کنید. هنگامی که همه چیز پایدار و تأیید شد، آن شاخه را به شاخهٔ main ادغام (merge) می‌کنید. این کار تضمین می‌کند که پروژهٔ اصلی شما ایمن باقی می‌ماند، در حالی که ویژگی‌های جدید می‌توانند بدون خراب کردن چیزی توسعه و آزمایش شوند. به طور خلاصه، شعبه‌بندی در گیت یک مرحلهٔ میانی امن و سازمان‌یافته را فراهم می‌کند که به شما امکان می‌دهد تغییرات را قبل از ادغام آنها در کدهای اصلی، بررسی، آزمایش و مدیریت کنید.

ساخت و ادغام شاخه‌ها

برای مشاهدهٔ شاخه‌های موجود، می‌توانید دستور git branch را در ترمینال اجرا کنید. برای ایجاد یک شاخهٔ جدید، از دستور git branch به همراه نام شاخه استفاده می‌کنیم، مثلاً: git branch development. پس از ایجاد شاخه، برای جابه‌جایی به آن، دستور git checkout development را به کار می‌بریم.

هنگامی که یک شاخهٔ جدید ایجاد می‌شود، دقیقاً وضعیت شاخه‌ای را که در آن بوده‌اید به ارث می‌برد. به عنوان مثال، اگر شاخهٔ development را از main ایجاد کنید، development یک کپی دقیق از main خواهد بود. تغییراتی که در یک شاخه ایجاد می‌کنید، فقط در همان شاخه وجود دارند. وقتی به شاخهٔ main برمی‌گردید، گیت به طور خودکار تغییرات ایجاد شده در شاخهٔ development را پنهان می‌کند و فقط آنچه در شاخهٔ main وجود دارد را به شما نشان می‌دهد. این نشان می‌دهد که گیت چقدر بر فایل‌سیستم شما کنترل دارد.

"ادغام" (Merging) به معنای ترکیب تغییرات دو شاخه در یک شاخه است. این یک مفهوم مهم برای درک نحوهٔ کار شاخه‌هاست. هنگامی که تمام تغییرات نهایی و آزمایش شدند، آنها را به شاخهٔ اصلی برمی‌گردانیم. فرض کنید در شاخهٔ development تغییراتی اعمال کرده و آنها را کامیت کرده‌اید. برای ادغام این تغییرات به شاخهٔ main، ابتدا به شاخهٔ main برمی‌گردید (git checkout main) و سپس دستور git merge development را اجرا می‌کنید. پس از این دستور، تمام تغییرات از شاخهٔ development به شاخهٔ main منتقل می‌شوند.

مدیریت تضادهای ادغام (Merge Conflicts)

گاهی اوقات در طول یک عملیات ادغام، "تضادهای ادغام" (Merge Conflicts) رخ می‌دهند. تضاد ادغام زمانی اتفاق می‌افتد که یک بخش از یک فایل در دو شاخه به صورت متفاوت تغییر کرده باشد. به عنوان مثال، اگر شما فایل one.txt را در شاخهٔ main تغییر دهید و همکار شما دقیقاً همان قسمت از فایل one.txt را در شاخهٔ development تغییر دهد، گیت نمی‌داند که کدام نسخه را باید حفظ کند. در چنین مواردی، گیت فایل را به عنوان دارای تضاد علامت‌گذاری می‌کند و شما باید آن را به صورت دستی حل کنید.

هنگامی که تضادی رخ می‌دهد، گیت قسمت‌های متضاد را در فایل با نشانگرهایی مانند <<<<<<<، ======= و >>>>>>> مشخص می‌کند. شما باید فایل را در یک ویرایشگر متن باز کرده، تصمیم بگیرید که کدام تغییرات را حفظ کنید (یا هر دو نسخه را با هم ترکیب کنید)، و نشانگرهای تضاد را حذف کنید. پس از حل دستی تضاد، باید فایل را ذخیره کرده و سپس دستورات زیر را اجرا کنید تا تغییرات حل شده را کامیت کنید:

• git add . (برای استیج کردن تغییرات حل شده)


• git commit -m "merge conflict resolved" (برای کامیت کردن راه‌حل تضاد)

این فرآیند تضمین می‌کند که پروژهٔ شما حتی در سناریوهای همکاری پیچیده، پایدار و قابل مدیریت باقی می‌ماند.

همکاری با گیت‌هاب و ریموت‌ها

مفهوم ریموت‌ها و اهمیت آن‌ها در گیت‌هاب

گیت به خودی خود یک ابزار قدرتمند است که روی کامپیوتر شما اجرا می‌شود و تغییرات فایل‌هایتان را ردیابی می‌کند. اما گیت‌هاب یک پلتفرم آنلاین است که به شما امکان می‌دهد پروژه‌های گیت خود را در فضای ابری ذخیره کنید و با دیگران همکاری کنید. در واقع، گیت‌هاب همکاری تیمی، اشتراک‌گذاری و پشتیبان‌گیری را بسیار آسان‌تر می‌کند. آن‌ها به هم متصل‌اند، اما کاملاً متفاوت عمل می‌کنند. اگر گیت را "قهوه" در نظر بگیریم، گیت‌هاب "قهوه‌خانه‌ای" است که این قهوه در آن سرو می‌شود. معماری گیت عمدتاً به دو بخش "محلی" (Local) و "ریموت" (Remote) تقسیم می‌شود. بخش محلی به کامپیوتر خود شما اشاره دارد، جایی که تمام کارهای خود را انجام می‌دهید و فایل‌ها و کدهای شما ذخیره می‌شوند. بخش ریموت، در فضای ابری قرار دارد و جایی است که شما کارهای محلی خود را به آنجا "پوش" یا آپلود می‌کنید. در بیشتر موارد، وقتی صحبت از "ریموت" می‌شود، معمولاً منظور گیت‌هاب است.

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

همگام‌سازی پروژه‌ها با ریموت‌ها: git push, git fetch, git pull

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

به طور خلاصه: `git push` تغییرات محلی را به ریموت می‌فرستد. `git fetch` تغییرات ریموت را به مخزن محلی شما می‌آورد (اما آن‌ها را در دایرکتوری کاری شما ادغام نمی‌کند). `git pull` عملیات `fetch` و `merge` را همزمان انجام می‌دهد؛ یعنی بلافاصله دایرکتوری کاری شما را به‌روزرسانی می‌کند. تصور کنید تغییراتی در فایل `three.txt` مستقیماً روی گیت‌هاب ایجاد کرده‌اید. اکنون شعبه اصلی ریموت، به‌روزرسانی جدیدی دارد که شعبه اصلی محلی شما ندارد. در حالی که در شعبه اصلی محلی خود هستید، برای دریافت آخرین تغییرات از ریموت، دستور `git fetch origin main` را اجرا کنید. گیت تغییرات جدید را از مخزن ریموت دریافت می‌کند، اما این به‌روزرسانی‌ها هنوز در سیستم فایل محلی شما ظاهر نمی‌شوند. سپس، `git merge origin/main` را اجرا کنید تا تغییرات ریموت در دایرکتوری کاری محلی شما نیز ادغام شوند. یا به جای این دو دستور، می‌توانید مستقیماً `git pull` را استفاده کنید که هر دو عملیات `fetch` و `merge` را در یک دستور انجام می‌دهد، به این معنی که تمام تغییرات جدید ریموت، فوراً در فایل‌های محلی شما ظاهر می‌شوند. این سه دستور جزو پرکاربردترین عملیات گیت هستند و برای بیشتر کارهای روزمره توسعه کافی‌اند.

مدیریت همکاری تیمی با Pull Requestها (PRs) در گیت‌هاب

در حین کار با گیت و گیت‌هاب، اصطلاح "پول ریکوئست" (Pull Request) که اغلب به اختصار "PR" نامیده می‌شود، مکرراً مطرح می‌شود. یک پول ریکوئست اساساً درخواستی است که شما برای ادغام تغییرات خود در یک شاخه دیگر – معمولاً شاخه اصلی (main) – ارائه می‌دهید. این به معنای این است که "من تغییراتی در شاخه خودم ایجاد کرده‌ام. لطفاً آن‌ها را بررسی کنید، و اگر همه چیز خوب به نظر می‌رسد، آن‌ها را در شاخه اصلی ادغام کنید." به عبارت دیگر، شما معمولاً تغییرات را مستقیماً در مخزن شخص دیگری ایجاد نمی‌کنید. وقتی کار خود را در شاخه خودتان به پایان می‌رسانید، یک پول ریکوئست ایجاد می‌کنید تا اجازه ادغام کد خود را در مخزن اصلی درخواست کنید.

روند ایجاد یک پول ریکوئست در گیت‌هاب به این صورت است که ابتدا شاخه فیچر (feature branch) خود را به گیت‌هاب "پوش" می‌کنید. سپس در صفحه گیت‌هاب مخزن خود، به بخش "Pull requests" می‌روید. با کلیک بر روی "New pull request"، شما انتخاب می‌کنید که کدام شاخه (مثلاً `development` یا `feature`) را به کدام شاخه پایه (معمولاً `main`) می‌خواهید ادغام کنید. گیت‌هاب به طور خودکار مقایسه‌ای دقیق از تغییرات انجام شده را نشان می‌دهد: کدام فایل‌ها تغییر کرده‌اند، کدام خطوط اضافه یا حذف شده‌اند. پس از بررسی و اطمینان از صحت تغییرات، یک عنوان و توضیحات مناسب برای PR خود می‌نویسید و آن را ارسال می‌کنید. پس از ارسال، هم‌تیمی‌های شما می‌توانند کد را بررسی کنند، در مورد تغییرات بحث و نظر دهند و در صورت تأیید، PR را ادغام کنند. این فرآیند تضمین می‌کند که شاخه اصلی همواره پایدار بماند و کل تیم بتواند با خیال راحت و کارآمد با یکدیگر همکاری کنند، زیرا هر تغییری قبل از ادغام در کد اصلی، بازبینی می‌شود. این سازوکار نقش مهمی در حفظ کیفیت کد و مدیریت پروژه‌های بزرگ ایفا می‌کند.

جمع‌بندی و توصیه‌های نهایی

در این راهنمای جامع، با مفاهیم اساسی و پیشرفته Git و GitHub آشنا شدید. گیت، ابزار کنترل نسخه قدرتمندی است که به شما امکان می‌دهد تمام تغییرات فایل‌هایتان را ردیابی کنید، نسخه‌های مختلف را نگهداری و در هر زمان به نسخه‌های قبلی بازگردید. گیت‌هاب نیز پلتفرمی ابری است که به‌عنوان یک "سرور کد" مرکزی عمل کرده و همکاری تیمی، پشتیبان‌گیری و اشتراک‌گذاری پروژه‌ها را به سادگی ممکن می‌سازد. از نصب گیت و راه‌اندازی مخازن محلی و ریموت گرفته تا درک کامل گردش کار گیت (working directory, staging area, local repository)، و همچنین مدیریت تغییرات با دستوراتی مانند `git add`, `git commit`, `git status`، همگی از پایه‌های کار با این ابزارهای حیاتی هستند. همچنین، کار با ریموت‌ها از طریق `git push`, `git fetch`, `git pull` و استفاده از `Pull Request`ها برای همکاری تیمی، از مهارت‌های کلیدی در توسعه نرم‌افزار مدرن محسوب می‌شوند.

توانایی استفاده از قابلیت‌های پیشرفته‌تر مانند شاخه‌بندی (branching)، ادغام (merging)، حل تعارضات، و دستورات بازیابی (مانند `git restore`, `git revert`, `git stash`) و سازماندهی تاریخچه با `git rebase`، شما را به یک توسعه‌دهنده کارآمدتر تبدیل می‌کند. در نهایت، با تسلط بر این ابزارها، نه تنها از از دست رفتن کارتان جلوگیری می‌کنید، بلکه می‌توانید به طور مؤثرتری در پروژه‌های تیمی مشارکت کرده و روند توسعه نرم‌افزار را بهبود بخشید. توصیه می‌شود که این دستورات و مفاهیم را به صورت عملی و مداوم تمرین کنید تا به بخشی جدایی‌ناپذیر از جریان کاری توسعه شما تبدیل شوند. یادگیری عمیق گیت و گیت‌هاب سرمایه‌گذاری بزرگی در مسیر شغلی هر برنامه‌نویسی است.