گیت و گیت‌هاب سیستم‌های کنترل نسخه‌ی رایج بین توسعه‌دهندگان هستند که برای کار با آن‌ها باید ابتدا با مفاهیم بنیادی این سیستم‌ها آشنا شوید.
اگر به‌عنوان کاربر اندروید حداقل یک بار سراغ رام کاستوم رفته باشید، محال است نام گیت‌هاب (Github) را ندیده باشید. تقریبا تمام توسعه‌دهندگان اندروید از این سرویس برای انتشار منابع پروژه‌های خود استفاده می‌کنند؛ اما بسیاری از کاربران در مواجهه با گیت‌هاب، بخش‌ها و اصطلاحات آن سردرگم می‌شوند. در این مقاله به چیستی گیت، گیت‌هاب و نحوه‌ی کار با آن‌ها می‌پردازیم.
اسم گیت‌هاب از دو بخش گیت و هاب تشکیل شده است. در زیر هرکدام را به‌صورت جداگانه بررسی می‌کنیم.
گیت در گیت‌هاب
برای فهم گیت‌هاب، ابتدا باید با گیت آشنا شویم. گیت یک سیستم کنترل نسخه‌ی متن باز است که توسط خالق لینوکس، لینوس تروالدز، ساخته شد. گیت مانند سایر سیستم‌های کنترل نسخه از قبیل ساب‌ورژن، CVS و مرکوریال است؛ اما اساسا سیستم کنترل نسخه چیست؟ وقتی توسعه‌دهندگان چیز جدیدی مانند یک اپلیکیشن خلق می‌کنند، مدام تغییراتی در کدهای آن می‌دهند تا اولین نسخه‌ی رسمی و غیر بتا آماده‌ی انتشار شود. این روند در به‌روزرسانی برای نسخه‌های بعدی نیز ادامه دارد.
سیستم‌های کنترل نسخه تغییرات و بازنگری‌های توسعه‌دهندگان را در یک مخزن مرکزی ذخیره می‌کنند. با این کار همکاری بین توسعه‌دهندگان آسان می‌شود؛ به این شکل که هر توسعه‌دهنده می‌تواند نسخه‌ی جدید را دانلود کند، تغییرات را در آن اعمال و سپس آپلود کند. کلیه‌ی توسعه‌دهندگان قادر به مشاهده‌ی تغییرات جدید، دانلود آن‌ها و مشارکت در پروژه خواهند بود.
همچنین، کسانی که نقشی در پروژه ندارند، می‌توانند فایل‌های آن را دانلود و استفاده کنند. کاربران حرفه‌ای لینوکس احتمالا با این روند آشنایی کامل دارند؛ چرا که استفاده از گیت، ساب‌ورژن و سرویس‌های مشابه از ملزومات کامپایل کردن یک برنامه از سورس‌کد آن است.
هاب در گیت‌هاب، سیستم کنترل نسخه‌ای است که توسط اکثر توسعه‌دهندگان ترجیح داده می‌شود؛ زیرا نسبت به سایر سیستم‌ها برتری‌هایی دارد. مثلا در ذخیره‌ی تغییرات فایل‌ها بهتر عمل می‌کند. در بخش‌های بعدی این مقاله به نحوه‌ی کار با گیت خواهیم پرداخت.
در دنیای رایانه، هاب به تجهیزات سخت‌افزاری گفته می‌شود که از آن اشتراک‌گذاری شبکه با گجت‌های مختلف استفاده می‌شود و در نتیجه هاب به نوعی شبکه را گسترش می‌دهد. هاب در گیت‌هاب نیز چنین مفهومی دارد. توسعه‌دهندگان پروژه‌های خود را در گیت‌هاب ذخیره می‌کنند و از این طریق به شبکه‌ی عظیم توسعه‌دهندگان دنیا وصل می‌شوند. در گیت‌هاب این امکان وجود دارد که پروژه‌ای را از مخزن توسعه‌دهنده به مخزن خود کپی و در آن تغییرات اعمال کنید و سپس درخواست اعمال تغییرات را به صاحب پروژه بفرستید تا در پروژه‌ی اصلی اعمال کند. امکان پرسش و پاسخ نیز در این شبکه‌ی گیت فراهم است.
حالا که با مفاهیم گیت و گیت‌هاب آشنا شدیم به نحوه‌ی کار با این سرویس‌ها می‌پردازیم.
آموزش کار با گیت
نیازهای بنیادی
قبل از هرچیز لازم است مواردی را نصب کنید. برای این‌کار نسخه‌ی متناسب با سیستم‌عامل خود را از اینجا دانلود و نصب کنید. اگر از لینوکس استفاده می‌کنید، از طریق پکیج منیجر نیز می‌توانید اقدام کنید.
در مرحله‌ی بعد، از آن‌جایی که در روند آموزش، یک مخزن شامل یک کد و یک README خواهیم ساخت، یک دایرکتوری برای آن در نظر بگیرید.
پس از آن، به عملیات معمولی نظیر init، کلون، کامیت و diff می‌پردازیم. البته، عملیات پیشرفته‌تری نیز وجود دارد که در مراحل اولیه نیازی به آن‌ها نخواهید داشت.
راه‌اندازی یک مخزن (Repository)
قبل از شروع کار با گیت، باید یک مخزن پروژه راه‌اندازی کنید تا به کمک گیت آن را مدیریت کنید. ترمینال را باز کنید و در دایرکتوری پروژه‌ی خود دستور . git init را وارد کنید.
با این کار یک دایرکتوری مخفی با نام git. در دایرکتوری پروژه‌ی شما ساخته خواهد شد. این دایرکتوری همان مسیری است که گیت دیتابیس و تنظیمات خود را در آن ذخیره می‌کند تا تغییرات پروژه‌ی شما را دنبال کند.
کلون یا کپی کردن یک مخزن
راه دیگری برای دسترسی به مخزن وجود دارد که به کلونینگ مشهور است. درست مثل بررسی مخزن در سایر سیستم‌ها، اجرای کد git clone <repository URL> یک کپی کامل از مخزن مورد نظر به سیستم شما منتقل خواهد کرد. سپس، می‌توانید تغییرات دلخواه را در آن اعمال کنید. روند اعمال تغییرات ساخت تغییرات، اعمال موقت آن‌ها بدون وارد کردن در مخزن اصلی (staging)، اعمال تغییر در مخزن یا کامیت (commit) را شامل می‌شود.
افزودن فایل جدید
در این مرحله می‌توان از زبان‌های برنامه‌نویسی مختلف مانند پایتون، روبی، Go یا هر زبان دیگری استفاده کرد. ما در این آموزش از زبان php که معمول‌تر است استفاده می‌کنیم. فایلی به نام index.php را در دایرکتوری خود ایجاد و کد زیر را در آن وارد کنید.
بعد از ذخیره‌ی فایل، دستور git status را از ترمینال اجرا کنید. این دستور وضعیت حاضر مخزن کار شما را نشان می‌دهد. نتیجه‌ی به نمایش درآمده باید مشابه تصویر زیر باشد که در آن index.php به‌عنوان یک فایل untracked یا بررسی‌نشده فهرست شده است.
بعد از ذخیره‌ی فایل، دستور git status را از ترمینال اجرا کنید. این دستور وضعیت حاضر مخزن کار شما را نشان می‌دهد. نتیجه‌ی به نمایش درآمده باید مشابه تصویر زیر باشد که در آن index.php به‌عنوان یک فایل untracked یا بررسی‌نشده فهرست شده است.
حالا طرز کار با چند فایل بدون اعمال تغییرات در مخزن را بررسی می‌کنیم. برای این‌کار یک فایل دوم به نام README.md بسازید. در این فایل جزئیاتی مثل نام پروژه، نام و نشانی ایمیل خود را وارد کنید. دستور git status را مجددا اجرا کنید. خواهید دید که این‌بار دو فایل به‌عنوان بررسی‌نشده فهرست شده‌اند.
حالا می‌خواهیم index.php را به‌اصطلاح استیج (stage) کنیم. فایلی که استیج می‌شود؛ یعنی تغییرات آن انجام گرفته اما هنوز در مخزن اصلی اعمال نشده است. برای این‌کار دستور git add index.php را وارد کنید. حالا، دستور وضعیت گیت (git status) را مجددا اجرا کنید. خواهید دید که index.php به‌عنوان فایلی جدید در بخش تغییرات در انتظار اعمال (changes to be commited) فهرست شده است و README.md در همان بخش Untracked files قرار دارد.
تنظیمات
در این مرحله همه‌چیز آماده‌ی اعمال تغییرات یا commit است؛ اما قبل از این‌کار باید با تنظیمات ویرایشگر که گیت هنگام نوشتن پیام‌های کامیت مورد استفاده قرار می‌دهد آشنا شوید.
اگر از لینوکس استفاده می‌کنید گیت به‌طور پیش‌فرض، از برنامه‌‌هایی مانند pico، vi، vim یا emacs استفاده خواهد کرد. اگر با این برنامه‌ها آشنایی ندارید، ممکن است بخواهید آن‌ها را با نرم‌افزاری مثل Notepad، TextEdit یا Gedit عوض کنید. برای این‌کار دستور زیر را از ترمینال اجرا کنید:
در قسمت آخر کد به جای your app's name نام نرم‌افزار مورد نظر خود را وارد کنید.
تنظیمات دیگری مانند تغییر نام و ایمیل و چگونگی نمایش پیام کامیت نیز قابل انجام است. ما در این آموزش از vim به‌عنوان ادیتور استفاده می‌کنیم؛ اما شما می‌توانید انتخاب متفاوت خود را داشته باشید.
اعمال اولین تغییر
کامیت در گیت شباهت بسیار زیادی با کامیت در سایر سیستم‌های کنترل نسخه مانند ساب‌ورژن دارد. روند کار به این شکل است که کار را آغاز می‌کنید و پیامی جهت توضیح اینکه دلیل تغییر انجام گرفته چیست وارد می‌کنید و فایل تغییر می‌یابد. پس دستور git commit را اجرا کنید. با این کار ویرایشگر به‌صورت خودکار باز می‌شود و الگوی زیر را نمایش می‌دهد.
با بررسی مداوم وضعیت تغییرات اعمال‌شده توسط دستور git status از شرایط مخزن خود آگاهی پیدا خواهید کرد. با این‌کار همواره خواهید دانست چه تغییری را اعمال کرده و چه تغییری را هنوز اعمال نکرده‌اید. یک پیام کامیت خوب باید شامل دو بخش باشد؛ اول اینکه کوتاه و در حد ۷۲ کاراکتر باشد و به‌طور خلاصه تغییر اعمال‌شده را اعلام کند. دیگر اینکه دارای توضیحی بلندتر باشد که به‌طور مجزا در سطری دیگر جزئیات تغییر اعمال‌شده را توضیح دهد. البته مورد دوم اختیاری است و الزامی برای نوشتن آن وجود ندارد.
ما در این مرحله نیاز به نوشتن توضیح پیچیده‌ای نداریم؛ چرا که تنها یک فایل را به مخزن اضافه کرده‌ایم؛ اما چنان‌چه تغییری که اعمال می‌کنید دارای الگوریتم‌های پیچیده‌ای باشد، لازم است توضیحاتی در این بخش برای مطالعه‌ی سایر توسعه‌دهندگان بنویسید و آن‌ها را از چرایی اعمال این تغییر آگاه سازید. بنابراین، پیام ساده‌ی زیر را در ویرایشگر وارد و ذخیره کنید و خارج شوید.
حالا که تغییرات اعمال شدند. وضعیت گیت را مجددا بررسی کنید. خواهید دید که REDME.md همچنان در قسمت untracked قرار دارد.
مشاهده‌ی تغییرات
در این مرحله از آن‌جایی که چند فایل در قسمت کنترل نسخه داریم و با دستورهای پایه آشنا شده‌ایم، به بررسی تغییرات می‌پردازیم. برای بررسی تغییرات اعمال‌شده در یک فایل از دستور git diff استفاده می‌کنیم. این دستور مشابه دستور Linux diff دو فایل را با هم مقایسه می‌کند و تغییرات فایل جدیدتر را نمایش می‌دهد.
در اینجا برای مشاهده‌ی تغییرات فایل README.md دستور git diff README.md را اجرا می‌کنیم. با این‌کار تغییرات جدیدترین نسخه نسبت به اولین نسخه به نمایش درمی‌آید.
به خاطر داشته باشید که به‌طور پیش‌فرض، دستور git diff تغییرات را نسبت به فایل اولیه نشان می‌دهد، نه فایل استیج‌شده. اگر می‌خواهید تغییرات استیج‌شده را مشاهده کنید، دستور git diff --cached README.md را اجرا کنید. این دستور چیزی شبیه کد زیر را به نمایش درخواهد آورد.
در کد نمایش داده‌شده به پنج خط آخر دقت کنید. قبل از هر سطر یک علامت + وجود دارد. این علامت نشانگر افزودن چیزی به فایل است. در اینجا ما فقط اضافه کرده‌ایم؛ اما اگر چیزی حذف کرده بودیم علامت منفی (-) نمایش داده می‌شد.
نکات مهم درباره‌ی استیجینگ یا ایندکس
اگر مبتدی هستید، یکی از گیج‌کننده‌ترین قسمت‌ها برای شما محیط استیجینگ و رابطه‌ی آن با کامیت خواهد بود.
کامیت در واقع ثبت سوابق تغییرات فایل‌ها نسبت به آخرین تغییر اعمال‌شده است. یعنی شما تغییری در مخزن خود اعمال می‌کنید و به کیت می‌گویید آن فایل‌ها را در یک کامیت ثبت سابقه کند.
کامیت‌ها ماهیت پروژه‌ی شما را در مراحل مختلف حفظ می‌کنند تا هر زمان که نیاز شد بتوانید به مرحله‌ی قبل برگردید.
اما چطور به گیت می‌گویید کدام فایل‌ها را در کامیت قرار دهد؟ اینجا است که استیجینگ یا ایندکس ایفای نقش می‌کند. برای اضافه کردن یک فایل در کامیت، ابتدا باید آن را به محیط استیجینگ اضافه کنید. برای انجام این کار می‌توانید از دستور <git add <filename استفاده کنید. پس از اینکه که فایل‌های مورد نظر خود را با این دستور به محیط استیجینگ اضافه کردید، می‌توانید با دستور git commit آن‌ها را به‌عنوان کامیت در مخزن اعمال کنید.
برنچینگ یا شاخه‌بندی
تا اینجا با نحوه‌ی شروع کار و اعمال تغییرات و بررسی آن‌ها آشنا شدیم. حالا با مفهوم پیشرفته‌تری به نام شاخه‌بندی آشنا می‌شویم. وقتی به‌طور تیمی روی یک نرم‌افزار کار می‌کنیم. آزمون و خطاهای هر برنامه‌نویس روی شاخه‌ی اصلی کدهای یک برنامه ممکن است دردسرساز شود. گیت این اجازه را به شما می‌دهد که شاخه‌ی اختصاصی خود را داشته باشید. در این حالت، وقتی روی ساخت یک ویژگی کار می‌کنید، آزمایش‌های شما صدمه‌ای به شاخه‌ی اصلی نمی‌زند و می‌توانید وقتی به نتیجه رسیدید، مجموعه‌ی تغییرات اعمال‌شده را با شاخه‌ی اصلی تلفیق یا merge کنید.
تا این بخش از آموزش در حال کار روی شاخه‌ی اصلی یا مستر برنچ بوده‌ایم. شاخه‌ی اصلی در واقع همان شاخه‌ای است که به‌صورت پیش‌فرض راه‌اندازی گیت با آن آغاز می‌شود. اکنون قصد داریم یک شاخه به نام development (به معنی توسعه) راه‌اندازی کنیم. از ترمینال دستور git checkout -b develop را اجرا کنید تا شاخه‌ای به نام develop ساخته شود. اجرای این دستور علاوه بر ساخت شاخه‌ی مذکور بررسی آن را نیز اعمال می‌کند. این شاخه در ابتدا یک کپی از شاخه‌ی اصلی است. یعنی اگر دستور git status را اجرا کنید همان دو تغییر اعمال‌شده در README.md را مشاهده خواهید کرد. حالا فرض کنید می‌خواهیم همین دو کامیت را در شاخه‌ی اصلی تلفیق کنیم.
برای انجام این‌کار ابتدا باید مشخص کنید که قصد تلفیق تغییرات موجود در کدام شاخه را دارید.
پس، دستور git checkout master را اجرا کنید. حالا باید تغییرات را از شاخه‌ای که در حال کار روی آن بوده‌اید در این شاخه تلفیق کنید. برای این‌کار دستور git merge develop را اجرا کنید.
وقتی کار تمام شد، پیامی مبنی بر تغییر فایل‌ها و خلاصه گزارشی از آن تغییرات نشان داده خواهد شد.
به همین سادگی می‌توانید شاخه اضافه کنید و تغییرات آن را در شاخه‌ی اصلی اعمال کنید. البته برای این کار روش‌های دیگری نیز وجود دارد که با توجه به مقدماتی بودن آموزش به همین مقدار بسنده می‌کنیم.
آموزش کار با گیت‌هاب
پس از آشنایی مقدماتی با گیت وقت آن رسیده است که به گیت‌هاب بپردازیم. همان‌طور که گفته شد، گیت‌هاب چیزی فراتر از یک مخزن پروژه است. این سرویس یکی از نسخه‌های گرافیکی گیت به شمار می‌رود. در واقع، اگر کار با گیت را بلد باشید به‌ندرت در کار با گیت‌هاب به مشکل برخواهید خورد. مسئله‌ی دیگر این است که ممکن است نخواهید پروژه‌ی خود را با دیگران به اشتراک بگذارید. در این حالت استفاده از گیت و ذخیره‌ی تغییرات به‌صورت لوکال بهترین گزینه است؛ همچنین در استفاده از گیت‌هاب شما ملزم به داشتن اتصال اینترنت هستید؛ ولی در کار با گیت چنین الزامی وجود ندارد. با تمام این اوصاف، ممکن است بخواهید صفر تا صد پروژه‌ی خود را در گیت‌هاب انجام دهید؛ چرا که کار با گیت مرارت‌های خاص خود را دارد. برای مثال باید کل منبع را دانلود کنید، سپس وایرایش‌های خود را در قالب یک پچ تهیه کنید و به طریقی مثل ایمیل به سازنده‌ی اصلی بدهید و او این پچ را که از سازنده‌ی آن اطلاع دقیقی ندارد بررسی و در صورت امکان استفاده کند. خواهید دید که در گیت‌هاب به‌عنوان یک شبکه‌ی برخط و متن باز هیچ‌یک از این مرارت‌ها وجود نخواهد داشت؛ اما قبل از شروع کار با گیت‌هاب نیاز به آشنایی با مفاهیم خاصی است که در زیر به آن‌ها می‌پردازیم.
گام اول: ساخت مخزن یا Repository
مخزن یا repository که به اختصار به آن repo نیز گفته می‌شود می‌تواند شامل فولدر، فایل، تصویر، ویدیو و هر آنچه پروژه‌ی شما به آن نیاز دارد باشد. گیت‌هاب در ابتدای ساخت پروژه امکان افزودن README و سایر موارد مانند لایسنس را در اختیار می‌گذارد.
مخزن اول شما با نام hello-world می‌تواند مکانی برای ذخیره کردن ایده‌ها، منابع یا حتی اشتراک‌گذاری و بحث در مورد چیزهای مختلف باشد.
برنچینگ روشی برای کار همزمان روی نسخه‌های مختلف یک مخزن است.
به‌طور پیش‌فرض مخزن شما یک شاخه به نام master دارد که شاخه‌ی اصلی به‌حساب می‌آید. از شاخه‌ها برای آزمون و خطا و ویرایش کدها قبل از اعمال تغییرات در شاخه‌ی اصلی استفاده می‌شود.
وقتی یک شاخه بر پایه‌ی شاخه‌ی اصلی می‌سازید، یک کپی از آن با آخرین تغییراتی که تا آن لحظه اعمال‌شده در شاخه‌ی جدید ایجاد می‌شود. اگر زمانی که شما روی شاخه‌ی خود کار می‌کنید کسی کامیتی به شاخه‌ی اصلی اضافه کند می‌توانید آن را در شاخه‌ی خود اعمال کنید.
نمودار زیر روندی را که یک شاخه‌ی جانبی با نام feature باید طی کند تا با شاخه‌ی اصلی تلفیق شود نمایش می‌دهد.
روی دکمه‌ی Create branch کلیک کنید یا دکمه‌ی Enter را در کیبورد خود بزنید.
حالا دو شاخه دارید؛ یکی master و دیگری readme-edits که کاملا شبیه به هم هستند؛ البته تا زمانی که تغییری در هیچ‌یک اعمال نکرده‌ایم.
گام سوم: ایجاد تغییرات و اعمال آن‌ها
حالا که شاخه‌ی جدیدی با محتویات یکسان با شاخه‌ی اصلی داریم، بدون ترس از خرابکاری ویرایش‌های خود را آغاز می‌کنیم.
در گیت‌هاب به تغییرات اعمال‌شده کامیت (commit) می‌گویند. هر کامیت یک پیام کامیت نیز به همراه دارد که توضیح کوتاهی در رابطه با دلیل اعمال آن تغییر است. پیام‌های کامیت به سایر مشارکت‌کنندگان در پروژه این امکان را می‌دهد که متوجه شوند شما چه تغییری را به چه دلیل اعمال کرده‌اید.
تغییرات ایجادشده در فایل README تنها در شاخه‌ی readme-edits اعمال شده‌اند. حالا این شاخه دارای تغییراتی نسبت به شاخه‌ی master است.
گام چهارم: ایجاد درخواست اعمال تغییرات یا pull request
حالا برای اعمال این تغییرات در شاخه‌ی اصلی باید درخواست آن را ایجاد کنید. pull request هسته‌ی تمام همکاری‌ها در گیت‌هاب را تشکیل می‌دهد. با ارسال چنین درخواستی، شما از صاحب شاخه می‌خواهید که تغییرات انجام‌شده توسط شما را بررسی و در صورت صلاحدید به شاخه‌ی اصلی اضافه کند. درخواست‌های اعمال تغییرات تغییرات بین دو شاخه را نمایش می‌دهند. تغییرات، حذف و اضافه‌ها در رنگ‌های سبز و قرمز نشان داده می‌شوند.
با استفاده از سیستم منشن در گیت‌هاب می‌توانید در سیستم پیام pull request خود از سایر افراد یا تیم‌ها درخواست کنید که درباره‌ی ویرایش‌های شما نظر بدهند.
شما می‌توانید درخواست اعمال تغییرات را برای خود نیز ارسال کنید. یعنی وقتی تغییری را به‌طور کامل در شاخه‌ی فرعی انجام دادید، می‌توانید برای تلفیق آن در شاخه‌ی اصلی از pull request استفاده کنید.
گام پنجم: پذیرش درخواست تلفیق تغییرات اعمال‌شده
در این گام پایانی، نحوه‌ی تلفیق تغییرات شاخه‌ی فرعی در شاخه‌ی master را بررسی می‌کنیم.
در تصویر فوق صفحه‌ی اصلی مربوط به یک پروژه را می‌بینید. در مستطیل شماره‌ی یک نام پروژه، تعداد افرادی که در حال تماشای آن هستند، تعداد افرادی که با ستاره دادن آن را ارزیابی کرده‌اند، تعداد دفعاتی که این پروژه توسط توسعه‌دهندگان دیگر برای مشارکت در پروژه آن را کپی‌برداری شده است. در مستطیل شماره‌ی ۲ تعداد کامیت‌های اعمال‌شده در شاخه‌ی فعلی، تعداد شاخه‌های موجود، تعداد نسخه‌های منتشرشده و تعداد مشارکت‌کنندگان در پروژه نشان داده شده است. در مستطیل شماره‌ی ۳ نوار انتخاب شاخه را می‌بینید که در زیر آن فایل‌های مهم پروژه به همراه زمان آخرین باری که تغییری در آن‌ها اعمال‌شده است قرار دارد.
در قسمت راست تصویر و در مستطیل شماره‌ی ۴ مفاهیمی کلیدی را مشاهده می‌کنید که در زیر به توضیح آن‌ها می‌پردازیم.
حالا با کلیک روی قسمت commits نگاهی به سوابق کامیت‌ها می‌اندازیم. در این قسمت کامیت‌ها را به ترتیب جدیدترین به قدیمی‌ترین مشاهده می‌کنید. در سمت چپ توضیح مختصری در خصوص کامیت، نام سازنده‌ی آن و تاریخی که ساخته شده است می‌بینید. در سمت راست، نسخه‌ی کوتاه هش مربوط به کامیت و لینک ورود به این کامیت قرار دارد.
روی هش کامیت کلیک کنید تا تغییراتی که به واسطه‌ی آن اعمال می‌شود ببینید. در مثال ما تغییرات نظیر به نظیر فایل README و فایل Version.php یک پروژه بررسی شده است. در سمت چپ مواردی که در مقایسه با نسخه‌ی قبل حذف شده‌اند می‌بینید و در سمت راست آنچه در این نسخه اضافه شده است شاهد هستید. در بالای هر کامیت سمت چپ خلاصه‌ای کوتاه از تغییرات نمایش داده می‌شود.
اما قسمت جالب ماجرا اینجا است؛ نشانگر موس را روی هر یک از قسمت‌های چپ یا راست که قرار دهید آیکونی آبی‌رنگ با علامت مثبت نمایان می‌شود. با کلیک روی آن می‌توانید نظر خود را در خصوص قسمت خاصی از تغییر اعمال‌شده بنویسید. این ویژگی گیت‌هاب از قابلیت‌های فوق‌العاده‌‌ای است که تجربه‌ی کار گروهی را ارتقاء می‌دهد. اگر می‌خواهید راحب کل کامیت نظر بدهید، در پایین آن قسمتی برای ای‌کار در نظر گرفته شده است.
آموزش انتقال پروژه از گیت به گیت‌هاب
حالا قصد داریم پروژه‌ی کوچکی را که در گیت روی آن کار کرده بودیم در گیت‌هاب بارگذاری کنیم. برای این‌کار ابتدا نیاز به ساخت یک حساب کاربری در گیت‌هاب دارید. توجه داشته باشید در روند ساخت حساب کاربری در گیت‌هاب پس از وارد کردن نام کاربری، ایمیل و پسورد، دو تعرفه پیش روی شما قرار می‌گیرد. در گزینه‌ی اول استفاده از گیت‌هاب رایگان خواهد بود اما نمی‌توانید پروژه‌ی محرمانه بسازید. طبعا گزینه‌ی دوم پولی و با امکان ساخت پروژه‌ی محرمانه یا خصوصی است.
پس از ورود به حساب کاربری خود برای بارگذاری پروژه روی علامت مثبت موجود در بالا گوشه‌ی راست کلیک کنید و در فهرست بازشده New repository را برای راه‌اندازی مخزن جدید انتخاب کنید. در این مرحله فرم مربوط به ساخت پروژه‌ی جدید ظاهر خواهد شد.
در قسمت Repository name یک نام برای مخزن خود وارد کنید. این نام می‌تواند first-project به معنی اولین پروژه باشد. می‌توانید توضیحی نیز در خصوص آن ذکر کنید. مثلا my first Github project به معنی اولین پروژه‌ی من در گیت‌هاب. حالت پروژه با توجه به نوع کاربری شما، public خواهد بود. نهایتا تیک inilialize this repository with a README را بزنید و دو قسمت دیگر را به همان شکل روی None رها کنید. حالا روی Create repository کلیک کنید.
در این مرحله به صفحه‌ی راه‌انداری سریع هدایت خواهید شد. این صفحه امکان بارگذاری پروژه‌ی گیت را به ما خواهد داد. برای انجام این‌کار اولین سطر زیر or push an existing repository from the command line... را کپی کنید و آن را در ترمینال یعنی همان‌جایی که تا کنون روی آن کار می‌کردیم پیست کنید.
این‌کار به ما خروجی نخواهد داد. حالا همین کار را برای سطر دوم انجام دهید. در این مرحله تغییرات ما به گیت‌هاب منتقل می‌شود و خروجی مشابه آنچه در تصویر زیر می‌بینید خواهد بود. حالا در مرورگر خود صفحه‌ی گیت‌هاب را ریفرش کنید. فایل‌های README.md و index.php به‌عنوان اولین فایل‌های پروژه نمایش داده می‌شوند و محتویات README.md در پایین صفحه نمایان می‌شود.
اگر به‌عنوان کاربر اندروید حداقل یک بار سراغ رام کاستوم رفته باشید، محال است نام گیت‌هاب (Github) را ندیده باشید. تقریبا تمام توسعه‌دهندگان اندروید از این سرویس برای انتشار منابع پروژه‌های خود استفاده می‌کنند؛ اما بسیاری از کاربران در مواجهه با گیت‌هاب، بخش‌ها و اصطلاحات آن سردرگم می‌شوند. در این مقاله به چیستی گیت، گیت‌هاب و نحوه‌ی کار با آن‌ها می‌پردازیم.
اسم گیت‌هاب از دو بخش گیت و هاب تشکیل شده است. در زیر هرکدام را به‌صورت جداگانه بررسی می‌کنیم.
گیت در گیت‌هاب
برای فهم گیت‌هاب، ابتدا باید با گیت آشنا شویم. گیت یک سیستم کنترل نسخه‌ی متن باز است که توسط خالق لینوکس، لینوس تروالدز، ساخته شد. گیت مانند سایر سیستم‌های کنترل نسخه از قبیل ساب‌ورژن، CVS و مرکوریال است؛ اما اساسا سیستم کنترل نسخه چیست؟ وقتی توسعه‌دهندگان چیز جدیدی مانند یک اپلیکیشن خلق می‌کنند، مدام تغییراتی در کدهای آن می‌دهند تا اولین نسخه‌ی رسمی و غیر بتا آماده‌ی انتشار شود. این روند در به‌روزرسانی برای نسخه‌های بعدی نیز ادامه دارد.
سیستم‌های کنترل نسخه تغییرات و بازنگری‌های توسعه‌دهندگان را در یک مخزن مرکزی ذخیره می‌کنند. با این کار همکاری بین توسعه‌دهندگان آسان می‌شود؛ به این شکل که هر توسعه‌دهنده می‌تواند نسخه‌ی جدید را دانلود کند، تغییرات را در آن اعمال و سپس آپلود کند. کلیه‌ی توسعه‌دهندگان قادر به مشاهده‌ی تغییرات جدید، دانلود آن‌ها و مشارکت در پروژه خواهند بود.
همچنین، کسانی که نقشی در پروژه ندارند، می‌توانند فایل‌های آن را دانلود و استفاده کنند. کاربران حرفه‌ای لینوکس احتمالا با این روند آشنایی کامل دارند؛ چرا که استفاده از گیت، ساب‌ورژن و سرویس‌های مشابه از ملزومات کامپایل کردن یک برنامه از سورس‌کد آن است.
هاب در گیت‌هاب، سیستم کنترل نسخه‌ای است که توسط اکثر توسعه‌دهندگان ترجیح داده می‌شود؛ زیرا نسبت به سایر سیستم‌ها برتری‌هایی دارد. مثلا در ذخیره‌ی تغییرات فایل‌ها بهتر عمل می‌کند. در بخش‌های بعدی این مقاله به نحوه‌ی کار با گیت خواهیم پرداخت.
در دنیای رایانه، هاب به تجهیزات سخت‌افزاری گفته می‌شود که از آن اشتراک‌گذاری شبکه با گجت‌های مختلف استفاده می‌شود و در نتیجه هاب به نوعی شبکه را گسترش می‌دهد. هاب در گیت‌هاب نیز چنین مفهومی دارد. توسعه‌دهندگان پروژه‌های خود را در گیت‌هاب ذخیره می‌کنند و از این طریق به شبکه‌ی عظیم توسعه‌دهندگان دنیا وصل می‌شوند. در گیت‌هاب این امکان وجود دارد که پروژه‌ای را از مخزن توسعه‌دهنده به مخزن خود کپی و در آن تغییرات اعمال کنید و سپس درخواست اعمال تغییرات را به صاحب پروژه بفرستید تا در پروژه‌ی اصلی اعمال کند. امکان پرسش و پاسخ نیز در این شبکه‌ی گیت فراهم است.
حالا که با مفاهیم گیت و گیت‌هاب آشنا شدیم به نحوه‌ی کار با این سرویس‌ها می‌پردازیم.
آموزش کار با گیت
نیازهای بنیادی
قبل از هرچیز لازم است مواردی را نصب کنید. برای این‌کار نسخه‌ی متناسب با سیستم‌عامل خود را از اینجا دانلود و نصب کنید. اگر از لینوکس استفاده می‌کنید، از طریق پکیج منیجر نیز می‌توانید اقدام کنید.
در مرحله‌ی بعد، از آن‌جایی که در روند آموزش، یک مخزن شامل یک کد و یک README خواهیم ساخت، یک دایرکتوری برای آن در نظر بگیرید.
پس از آن، به عملیات معمولی نظیر init، کلون، کامیت و diff می‌پردازیم. البته، عملیات پیشرفته‌تری نیز وجود دارد که در مراحل اولیه نیازی به آن‌ها نخواهید داشت.
راه‌اندازی یک مخزن (Repository)
قبل از شروع کار با گیت، باید یک مخزن پروژه راه‌اندازی کنید تا به کمک گیت آن را مدیریت کنید. ترمینال را باز کنید و در دایرکتوری پروژه‌ی خود دستور . git init را وارد کنید.
کلون یا کپی کردن یک مخزن
راه دیگری برای دسترسی به مخزن وجود دارد که به کلونینگ مشهور است. درست مثل بررسی مخزن در سایر سیستم‌ها، اجرای کد git clone <repository URL> یک کپی کامل از مخزن مورد نظر به سیستم شما منتقل خواهد کرد. سپس، می‌توانید تغییرات دلخواه را در آن اعمال کنید. روند اعمال تغییرات ساخت تغییرات، اعمال موقت آن‌ها بدون وارد کردن در مخزن اصلی (staging)، اعمال تغییر در مخزن یا کامیت (commit) را شامل می‌شود.
افزودن فایل جدید
در این مرحله می‌توان از زبان‌های برنامه‌نویسی مختلف مانند پایتون، روبی، Go یا هر زبان دیگری استفاده کرد. ما در این آموزش از زبان php که معمول‌تر است استفاده می‌کنیم. فایلی به نام index.php را در دایرکتوری خود ایجاد و کد زیر را در آن وارد کنید.
?php print "Hello World";
بعد از ذخیره‌ی فایل، دستور git status را از ترمینال اجرا کنید. این دستور وضعیت حاضر مخزن کار شما را نشان می‌دهد. نتیجه‌ی به نمایش درآمده باید مشابه تصویر زیر باشد که در آن index.php به‌عنوان یک فایل untracked یا بررسی‌نشده فهرست شده است.
بعد از ذخیره‌ی فایل، دستور git status را از ترمینال اجرا کنید. این دستور وضعیت حاضر مخزن کار شما را نشان می‌دهد. نتیجه‌ی به نمایش درآمده باید مشابه تصویر زیر باشد که در آن index.php به‌عنوان یک فایل untracked یا بررسی‌نشده فهرست شده است.
در این مرحله همه‌چیز آماده‌ی اعمال تغییرات یا commit است؛ اما قبل از این‌کار باید با تنظیمات ویرایشگر که گیت هنگام نوشتن پیام‌های کامیت مورد استفاده قرار می‌دهد آشنا شوید.
اگر از لینوکس استفاده می‌کنید گیت به‌طور پیش‌فرض، از برنامه‌‌هایی مانند pico، vi، vim یا emacs استفاده خواهد کرد. اگر با این برنامه‌ها آشنایی ندارید، ممکن است بخواهید آن‌ها را با نرم‌افزاری مثل Notepad، TextEdit یا Gedit عوض کنید. برای این‌کار دستور زیر را از ترمینال اجرا کنید:
git config --global core.editor <your app's name
در قسمت آخر کد به جای your app's name نام نرم‌افزار مورد نظر خود را وارد کنید.
تنظیمات دیگری مانند تغییر نام و ایمیل و چگونگی نمایش پیام کامیت نیز قابل انجام است. ما در این آموزش از vim به‌عنوان ادیتور استفاده می‌کنیم؛ اما شما می‌توانید انتخاب متفاوت خود را داشته باشید.
اعمال اولین تغییر
کامیت در گیت شباهت بسیار زیادی با کامیت در سایر سیستم‌های کنترل نسخه مانند ساب‌ورژن دارد. روند کار به این شکل است که کار را آغاز می‌کنید و پیامی جهت توضیح اینکه دلیل تغییر انجام گرفته چیست وارد می‌کنید و فایل تغییر می‌یابد. پس دستور git commit را اجرا کنید. با این کار ویرایشگر به‌صورت خودکار باز می‌شود و الگوی زیر را نمایش می‌دهد.
# Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # # Initial commit # # Changes to be committed: # new file: index.php # # Untracked files: # README.md #
با بررسی مداوم وضعیت تغییرات اعمال‌شده توسط دستور git status از شرایط مخزن خود آگاهی پیدا خواهید کرد. با این‌کار همواره خواهید دانست چه تغییری را اعمال کرده و چه تغییری را هنوز اعمال نکرده‌اید. یک پیام کامیت خوب باید شامل دو بخش باشد؛ اول اینکه کوتاه و در حد ۷۲ کاراکتر باشد و به‌طور خلاصه تغییر اعمال‌شده را اعلام کند. دیگر اینکه دارای توضیحی بلندتر باشد که به‌طور مجزا در سطری دیگر جزئیات تغییر اعمال‌شده را توضیح دهد. البته مورد دوم اختیاری است و الزامی برای نوشتن آن وجود ندارد.
ما در این مرحله نیاز به نوشتن توضیح پیچیده‌ای نداریم؛ چرا که تنها یک فایل را به مخزن اضافه کرده‌ایم؛ اما چنان‌چه تغییری که اعمال می‌کنید دارای الگوریتم‌های پیچیده‌ای باشد، لازم است توضیحاتی در این بخش برای مطالعه‌ی سایر توسعه‌دهندگان بنویسید و آن‌ها را از چرایی اعمال این تغییر آگاه سازید. بنابراین، پیام ساده‌ی زیر را در ویرایشگر وارد و ذخیره کنید و خارج شوید.
“Adding the core script file to the repository”
حالا که تغییرات اعمال شدند. وضعیت گیت را مجددا بررسی کنید. خواهید دید که REDME.md همچنان در قسمت untracked قرار دارد.
در این مرحله از آن‌جایی که چند فایل در قسمت کنترل نسخه داریم و با دستورهای پایه آشنا شده‌ایم، به بررسی تغییرات می‌پردازیم. برای بررسی تغییرات اعمال‌شده در یک فایل از دستور git diff استفاده می‌کنیم. این دستور مشابه دستور Linux diff دو فایل را با هم مقایسه می‌کند و تغییرات فایل جدیدتر را نمایش می‌دهد.
در اینجا برای مشاهده‌ی تغییرات فایل README.md دستور git diff README.md را اجرا می‌کنیم. با این‌کار تغییرات جدیدترین نسخه نسبت به اولین نسخه به نمایش درمی‌آید.
به خاطر داشته باشید که به‌طور پیش‌فرض، دستور git diff تغییرات را نسبت به فایل اولیه نشان می‌دهد، نه فایل استیج‌شده. اگر می‌خواهید تغییرات استیج‌شده را مشاهده کنید، دستور git diff --cached README.md را اجرا کنید. این دستور چیزی شبیه کد زیر را به نمایش درخواهد آورد.
diff --git a/README.md b/README.md new file mode 100644 index 0000000..27c0a86 --- /dev/null +++ b/README.md @@ -0,0 +1,5 @@ +# Simple Git Project + +## Authors + +Matthew Setter <[email protected]>
در کد نمایش داده‌شده به پنج خط آخر دقت کنید. قبل از هر سطر یک علامت + وجود دارد. این علامت نشانگر افزودن چیزی به فایل است. در اینجا ما فقط اضافه کرده‌ایم؛ اما اگر چیزی حذف کرده بودیم علامت منفی (-) نمایش داده می‌شد.
نکات مهم درباره‌ی استیجینگ یا ایندکس
اگر مبتدی هستید، یکی از گیج‌کننده‌ترین قسمت‌ها برای شما محیط استیجینگ و رابطه‌ی آن با کامیت خواهد بود.
کامیت در واقع ثبت سوابق تغییرات فایل‌ها نسبت به آخرین تغییر اعمال‌شده است. یعنی شما تغییری در مخزن خود اعمال می‌کنید و به کیت می‌گویید آن فایل‌ها را در یک کامیت ثبت سابقه کند.
کامیت‌ها ماهیت پروژه‌ی شما را در مراحل مختلف حفظ می‌کنند تا هر زمان که نیاز شد بتوانید به مرحله‌ی قبل برگردید.
اما چطور به گیت می‌گویید کدام فایل‌ها را در کامیت قرار دهد؟ اینجا است که استیجینگ یا ایندکس ایفای نقش می‌کند. برای اضافه کردن یک فایل در کامیت، ابتدا باید آن را به محیط استیجینگ اضافه کنید. برای انجام این کار می‌توانید از دستور <git add <filename استفاده کنید. پس از اینکه که فایل‌های مورد نظر خود را با این دستور به محیط استیجینگ اضافه کردید، می‌توانید با دستور git commit آن‌ها را به‌عنوان کامیت در مخزن اعمال کنید.
برنچینگ یا شاخه‌بندی
تا اینجا با نحوه‌ی شروع کار و اعمال تغییرات و بررسی آن‌ها آشنا شدیم. حالا با مفهوم پیشرفته‌تری به نام شاخه‌بندی آشنا می‌شویم. وقتی به‌طور تیمی روی یک نرم‌افزار کار می‌کنیم. آزمون و خطاهای هر برنامه‌نویس روی شاخه‌ی اصلی کدهای یک برنامه ممکن است دردسرساز شود. گیت این اجازه را به شما می‌دهد که شاخه‌ی اختصاصی خود را داشته باشید. در این حالت، وقتی روی ساخت یک ویژگی کار می‌کنید، آزمایش‌های شما صدمه‌ای به شاخه‌ی اصلی نمی‌زند و می‌توانید وقتی به نتیجه رسیدید، مجموعه‌ی تغییرات اعمال‌شده را با شاخه‌ی اصلی تلفیق یا merge کنید.
تا این بخش از آموزش در حال کار روی شاخه‌ی اصلی یا مستر برنچ بوده‌ایم. شاخه‌ی اصلی در واقع همان شاخه‌ای است که به‌صورت پیش‌فرض راه‌اندازی گیت با آن آغاز می‌شود. اکنون قصد داریم یک شاخه به نام development (به معنی توسعه) راه‌اندازی کنیم. از ترمینال دستور git checkout -b develop را اجرا کنید تا شاخه‌ای به نام develop ساخته شود. اجرای این دستور علاوه بر ساخت شاخه‌ی مذکور بررسی آن را نیز اعمال می‌کند. این شاخه در ابتدا یک کپی از شاخه‌ی اصلی است. یعنی اگر دستور git status را اجرا کنید همان دو تغییر اعمال‌شده در README.md را مشاهده خواهید کرد. حالا فرض کنید می‌خواهیم همین دو کامیت را در شاخه‌ی اصلی تلفیق کنیم.
برای انجام این‌کار ابتدا باید مشخص کنید که قصد تلفیق تغییرات موجود در کدام شاخه را دارید.
پس، دستور git checkout master را اجرا کنید. حالا باید تغییرات را از شاخه‌ای که در حال کار روی آن بوده‌اید در این شاخه تلفیق کنید. برای این‌کار دستور git merge develop را اجرا کنید.
وقتی کار تمام شد، پیامی مبنی بر تغییر فایل‌ها و خلاصه گزارشی از آن تغییرات نشان داده خواهد شد.
آموزش کار با گیت‌هاب
پس از آشنایی مقدماتی با گیت وقت آن رسیده است که به گیت‌هاب بپردازیم. همان‌طور که گفته شد، گیت‌هاب چیزی فراتر از یک مخزن پروژه است. این سرویس یکی از نسخه‌های گرافیکی گیت به شمار می‌رود. در واقع، اگر کار با گیت را بلد باشید به‌ندرت در کار با گیت‌هاب به مشکل برخواهید خورد. مسئله‌ی دیگر این است که ممکن است نخواهید پروژه‌ی خود را با دیگران به اشتراک بگذارید. در این حالت استفاده از گیت و ذخیره‌ی تغییرات به‌صورت لوکال بهترین گزینه است؛ همچنین در استفاده از گیت‌هاب شما ملزم به داشتن اتصال اینترنت هستید؛ ولی در کار با گیت چنین الزامی وجود ندارد. با تمام این اوصاف، ممکن است بخواهید صفر تا صد پروژه‌ی خود را در گیت‌هاب انجام دهید؛ چرا که کار با گیت مرارت‌های خاص خود را دارد. برای مثال باید کل منبع را دانلود کنید، سپس وایرایش‌های خود را در قالب یک پچ تهیه کنید و به طریقی مثل ایمیل به سازنده‌ی اصلی بدهید و او این پچ را که از سازنده‌ی آن اطلاع دقیقی ندارد بررسی و در صورت امکان استفاده کند. خواهید دید که در گیت‌هاب به‌عنوان یک شبکه‌ی برخط و متن باز هیچ‌یک از این مرارت‌ها وجود نخواهد داشت؛ اما قبل از شروع کار با گیت‌هاب نیاز به آشنایی با مفاهیم خاصی است که در زیر به آن‌ها می‌پردازیم.
گام اول: ساخت مخزن یا Repository
مخزن یا repository که به اختصار به آن repo نیز گفته می‌شود می‌تواند شامل فولدر، فایل، تصویر، ویدیو و هر آنچه پروژه‌ی شما به آن نیاز دارد باشد. گیت‌هاب در ابتدای ساخت پروژه امکان افزودن README و سایر موارد مانند لایسنس را در اختیار می‌گذارد.
مخزن اول شما با نام hello-world می‌تواند مکانی برای ذخیره کردن ایده‌ها، منابع یا حتی اشتراک‌گذاری و بحث در مورد چیزهای مختلف باشد.
- برای ساخت یک مخزن جدید در گوشه‌ی بالا سمت راست و نزدیک به آواتار یا نماد کاربری شما، روی + و سپس New repository کلیک کنید.
- توضیح کوتاهی بنویسید.
- در صورت تمایل به اضافه کردن README گزینه‌ی Initialize this repository with a README را انتخاب کنید.
- روی Creat repository کلیک کنید.
برنچینگ روشی برای کار همزمان روی نسخه‌های مختلف یک مخزن است.
به‌طور پیش‌فرض مخزن شما یک شاخه به نام master دارد که شاخه‌ی اصلی به‌حساب می‌آید. از شاخه‌ها برای آزمون و خطا و ویرایش کدها قبل از اعمال تغییرات در شاخه‌ی اصلی استفاده می‌شود.
وقتی یک شاخه بر پایه‌ی شاخه‌ی اصلی می‌سازید، یک کپی از آن با آخرین تغییراتی که تا آن لحظه اعمال‌شده در شاخه‌ی جدید ایجاد می‌شود. اگر زمانی که شما روی شاخه‌ی خود کار می‌کنید کسی کامیتی به شاخه‌ی اصلی اضافه کند می‌توانید آن را در شاخه‌ی خود اعمال کنید.
نمودار زیر روندی را که یک شاخه‌ی جانبی با نام feature باید طی کند تا با شاخه‌ی اصلی تلفیق شود نمایش می‌دهد.
- برای ساخت یک شاخه‌ی جدید به مخزن جدیدی که با نام hello-world ساخته‌اید بروید.
- روی فهرست بازشونده‌ی موجود در بالای فهرست فایل‌ها که روی آن نام شاخه نوشته شده است کلیک کنید. در تکست‌باکس بازشده نام شاخه‌ی جدید، مثلا readme-edits را وارد کنید.
حالا دو شاخه دارید؛ یکی master و دیگری readme-edits که کاملا شبیه به هم هستند؛ البته تا زمانی که تغییری در هیچ‌یک اعمال نکرده‌ایم.
گام سوم: ایجاد تغییرات و اعمال آن‌ها
حالا که شاخه‌ی جدیدی با محتویات یکسان با شاخه‌ی اصلی داریم، بدون ترس از خرابکاری ویرایش‌های خود را آغاز می‌کنیم.
در گیت‌هاب به تغییرات اعمال‌شده کامیت (commit) می‌گویند. هر کامیت یک پیام کامیت نیز به همراه دارد که توضیح کوتاهی در رابطه با دلیل اعمال آن تغییر است. پیام‌های کامیت به سایر مشارکت‌کنندگان در پروژه این امکان را می‌دهد که متوجه شوند شما چه تغییری را به چه دلیل اعمال کرده‌اید.
- برای اعمال یک تغییر روی فایل README.md کلیک کنید.
- روی آیکون مداد در گوشه‌ی بالا سمت راست کلیک کنید تا بتوانید آن را ویرایش کنید.
- در ویرایشگر، کمی درباره‌ی خود بنویسید.
- یک پیام کامیت برای توصیف تغییرات خود بنویسید.
- روی دکمه‌ی Commit changes کلیک کنید.
گام چهارم: ایجاد درخواست اعمال تغییرات یا pull request
حالا برای اعمال این تغییرات در شاخه‌ی اصلی باید درخواست آن را ایجاد کنید. pull request هسته‌ی تمام همکاری‌ها در گیت‌هاب را تشکیل می‌دهد. با ارسال چنین درخواستی، شما از صاحب شاخه می‌خواهید که تغییرات انجام‌شده توسط شما را بررسی و در صورت صلاحدید به شاخه‌ی اصلی اضافه کند. درخواست‌های اعمال تغییرات تغییرات بین دو شاخه را نمایش می‌دهند. تغییرات، حذف و اضافه‌ها در رنگ‌های سبز و قرمز نشان داده می‌شوند.
با استفاده از سیستم منشن در گیت‌هاب می‌توانید در سیستم پیام pull request خود از سایر افراد یا تیم‌ها درخواست کنید که درباره‌ی ویرایش‌های شما نظر بدهند.
شما می‌توانید درخواست اعمال تغییرات را برای خود نیز ارسال کنید. یعنی وقتی تغییری را به‌طور کامل در شاخه‌ی فرعی انجام دادید، می‌توانید برای تلفیق آن در شاخه‌ی اصلی از pull request استفاده کنید.
گام پنجم: پذیرش درخواست تلفیق تغییرات اعمال‌شده
در این گام پایانی، نحوه‌ی تلفیق تغییرات شاخه‌ی فرعی در شاخه‌ی master را بررسی می‌کنیم.
[*=center]روی دکمه‌ی سبزرنگ Merge pull request کلیک کنید تا تغییرات شما در شاخه‌ی اصلی اعمال شوند.
- روی Confirm merge کلیک کنید.
- حالا که تغییرات را اعمال کرده‌اید، می‌توانید با استفاده از دکمه‌ی Delete branch شاخه‌ی فرعی را حذف کنید.
در قسمت راست تصویر و در مستطیل شماره‌ی ۴ مفاهیمی کلیدی را مشاهده می‌کنید که در زیر به توضیح آن‌ها می‌پردازیم.
- کد (Code): حالت نمایشی که به‌صورت پیش‌فرض در آن قرار دارید و فایل‌های پروژه به شما نمایش داده می‌شوند.
- مسائل (Issues): چنان‌چه شما یا هم‌تیمی‌های شما بخواهند مشکلی را در نرم‌افزار گزارش کنند، یا درخواست افزودن قابلیت یا مسائلی این‌چنینی را مطرح کنند، از این گزینه استفاده می‌کنند.
- ویکی (Wiki): امکانی است برای ثبت جزئی‌تر پروژه نسبت به آنچه در README.md می‌آید.
- ضربان (Pulse): خلاصه‌ای از آمار پروژه شامل مسائل مطرح‌شده، حل‌شده و حل‌نشده که نشانگر میزان فعال بودن پروژه است.
- نمودارها (Graphs): پیشرفت پروژه در طول زمان شامل روزهای پرکار و زمان‌هایی که پروژه رها شده و بی‌تغییر مانده است نشان می‌دهد.
حالا با کلیک روی قسمت commits نگاهی به سوابق کامیت‌ها می‌اندازیم. در این قسمت کامیت‌ها را به ترتیب جدیدترین به قدیمی‌ترین مشاهده می‌کنید. در سمت چپ توضیح مختصری در خصوص کامیت، نام سازنده‌ی آن و تاریخی که ساخته شده است می‌بینید. در سمت راست، نسخه‌ی کوتاه هش مربوط به کامیت و لینک ورود به این کامیت قرار دارد.
روی هش کامیت کلیک کنید تا تغییراتی که به واسطه‌ی آن اعمال می‌شود ببینید. در مثال ما تغییرات نظیر به نظیر فایل README و فایل Version.php یک پروژه بررسی شده است. در سمت چپ مواردی که در مقایسه با نسخه‌ی قبل حذف شده‌اند می‌بینید و در سمت راست آنچه در این نسخه اضافه شده است شاهد هستید. در بالای هر کامیت سمت چپ خلاصه‌ای کوتاه از تغییرات نمایش داده می‌شود.
آموزش انتقال پروژه از گیت به گیت‌هاب
حالا قصد داریم پروژه‌ی کوچکی را که در گیت روی آن کار کرده بودیم در گیت‌هاب بارگذاری کنیم. برای این‌کار ابتدا نیاز به ساخت یک حساب کاربری در گیت‌هاب دارید. توجه داشته باشید در روند ساخت حساب کاربری در گیت‌هاب پس از وارد کردن نام کاربری، ایمیل و پسورد، دو تعرفه پیش روی شما قرار می‌گیرد. در گزینه‌ی اول استفاده از گیت‌هاب رایگان خواهد بود اما نمی‌توانید پروژه‌ی محرمانه بسازید. طبعا گزینه‌ی دوم پولی و با امکان ساخت پروژه‌ی محرمانه یا خصوصی است.
پس از ورود به حساب کاربری خود برای بارگذاری پروژه روی علامت مثبت موجود در بالا گوشه‌ی راست کلیک کنید و در فهرست بازشده New repository را برای راه‌اندازی مخزن جدید انتخاب کنید. در این مرحله فرم مربوط به ساخت پروژه‌ی جدید ظاهر خواهد شد.
در قسمت Repository name یک نام برای مخزن خود وارد کنید. این نام می‌تواند first-project به معنی اولین پروژه باشد. می‌توانید توضیحی نیز در خصوص آن ذکر کنید. مثلا my first Github project به معنی اولین پروژه‌ی من در گیت‌هاب. حالت پروژه با توجه به نوع کاربری شما، public خواهد بود. نهایتا تیک inilialize this repository with a README را بزنید و دو قسمت دیگر را به همان شکل روی None رها کنید. حالا روی Create repository کلیک کنید.