گیت هاب چیست؛ آموزش ساخت اکانت و کار با Github

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

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

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

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

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

هاب سیستم کنترل نسخه‌ای است که توسط اکثر توسعه‌دهندگان ترجیح داده می‌شود؛ زیرا نسبت به سایر سیستم‌ها برتری‌هایی دارد. مثلا در ذخیره‌ی تغییرات فایل‌ها بهتر عمل می‌کند. در بخش‌های بعدی این مقاله به نحوه‌ی کار با گیت خواهیم پرداخت.

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

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

اولین قدم این است که با تایپ "github.com" در نوار آدرس مرورگر خود، به وب‌سایت GitHub بروید. پس از ورود به وب‌سایت، دکمه ثبت نام (Sign up) را در گوشه سمت راست بالای صفحه مشاهده خواهید کرد.

پس از کلیک روی دکمه Sign up و به صفحه‌ای هدایت می‌شوید که باید مشخصات خود را وارد کنید و از شما خواسته می‌شود نام کاربری، آدرس ایمیل و رمز عبور خود را ارائه دهید. اطمینان حاصل کنید که یک نام کاربری منحصر‌به‌فرد انتخاب کرده تا آن را به راحتی به خاطر بسپارید. آدرس ایمیل شما باید آدرسی معتبر باشد زیرا گیت‌هاب برای فعال کردن حساب شما یک ایمیل تأیید برای شما ارسال خواهد کرد.

پس از وارد کردن مشخصات خود، گیت‌هاب برای تأیید حساب، ایمیلی برای شما ارسال می‌کند. صندوق ورودی (Inbox) خود را بررسی و روی لینک تأیید ارائه شده در ایمیل کلیک کنید. اگر ایمیل را دریافت نکردید، پوشه اسپم (Spam) خود را نیز بررسی کنید.

هنگامی که آدرس ایمیل خود را تأیید کردید، از شما خواسته می‌شود یک طرح را انتخاب کنید. گیت‌هاب سه طرح را ارائه می‌دهد که شامل گزینه‌های رایگان، تیمی و سازمانی است. طرح رایگان برای توسعه‌دهندگانی مناسب است که می‌خواهند از گیت‌هاب برای پروژه‌های شخصی خود استفاده کنند. طرح تیمی نیز برای تیم‌هایی است که می‌خواهند در پروژه‌ها همکاری کنند، در حالی که طرح سازمانی برای سازمان‌های بزرگ با الزامات پیچیده است.

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

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

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

در مرحله‌ی بعد، از آن‌جایی که در روند آموزش، یک مخزن شامل یک کد و یک README خواهیم ساخت، یک دایرکتوری برای آن در نظر بگیرید.

پس از آن، به عملیات معمولی نظیر init، کلون، کامیت و diff می‌پردازیم. البته، عملیات پیشرفته‌تری نیز وجود دارد که در مراحل اولیه نیازی به آن‌ها نخواهید داشت.

قبل از شروع کار با گیت، باید یک مخزن پروژه راه‌اندازی کنید تا به کمک گیت آن را مدیریت کنید. ترمینال را باز کنید و در دایرکتوری پروژه‌ی خود دستور . git init را وارد کنید.

با این کار یک دایرکتوری مخفی با نام git. در دایرکتوری پروژه‌ی شما ساخته خواهد شد. این دایرکتوری همان مسیری است که گیت دیتابیس و تنظیمات خود را در آن ذخیره می‌کند تا تغییرات پروژه‌ی شما را دنبال کند.

راه دیگری برای دسترسی به مخزن وجود دارد که به کلونینگ مشهور است. درست مثل بررسی مخزن در سایر سیستم‌ها، اجرای کد git clone یک کپی کامل از مخزن مورد نظر به سیستم شما منتقل خواهد کرد. سپس، می‌توانید تغییرات دلخواه را در آن اعمال کنید. روند اعمال تغییرات ساخت تغییرات، اعمال موقت آن‌ها بدون وارد کردن در مخزن اصلی(staging)، اعمال تغییر در مخزن یا کامیت (commit) را شامل می‌شود.

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

;?php print "Hello World";

بعد از ذخیره‌ی فایل، دستور 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 عوض کنید. برای این‌کار دستور زیر را از ترمینال اجرا کنید:

git config --global core.editor

در قسمت آخر کد به جای 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

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

اگر مبتدی هستید، یکی از گیج‌کننده‌ترین قسمت‌ها برای شما محیط استیجینگ و رابطه‌ی آن با کامیت خواهد بود.

کامیت در واقع ثبت سوابق تغییرات فایل‌ها نسبت به آخرین تغییر اعمال‌شده است. یعنی شما تغییری در مخزن خود اعمال می‌کنید و به کیت می‌گویید آن فایل‌ها را در یک کامیت ثبت سابقه کند.

کامیت‌ها ماهیت پروژه‌ی شما را در مراحل مختلف حفظ می‌کنند تا هر زمان که نیاز شد بتوانید به مرحله‌ی قبل برگردید.

اما چطور به گیت می‌گویید کدام فایل‌ها را در کامیت قرار دهد؟ اینجا است که استیجینگ یا ایندکس ایفای نقش می‌کند. برای اضافه کردن یک فایل در کامیت، ابتدا باید آن را به محیط استیجینگ اضافه کنید. برای انجام این کار می‌توانید از دستور

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

تا این‌ بخش از آموزش در حال کار روی شاخه‌ی اصلی یا مستر برنچ بوده‌ایم. شاخه‌ی اصلی در واقع همان شاخه‌ای است که به‌صورت پیش‌فرض راه‌اندازی گیت با آن آغاز می‌شود. اکنون قصد داریم یک شاخه به نام development (به معنی توسعه) راه‌اندازی کنیم. از ترمینال دستور git checkout -b develop را اجرا کنید تا شاخه‌ای به نام develop ساخته شود. اجرای این دستور علاوه بر ساخت شاخه‌ی مذکور بررسی آن را نیز اعمال می‌کند. این شاخه در ابتدا یک کپی از شاخه‌ی اصلی است. یعنی اگر دستور git status را اجرا کنید همان دو تغییر اعمال‌شده در README.md را مشاهده خواهید کرد. حالا فرض کنید می‌خواهیم همین دو کامیت را در شاخه‌ی اصلی تلفیق کنیم.

برای انجام این‌کار ابتدا باید مشخص کنید که قصد تلفیق تغییرات موجود در کدام شاخه را دارید.

پس، دستور git checkout master را اجرا کنید. حالا باید تغییرات را از شاخه‌ای که در حال کار روی آن بوده‌اید در این شاخه تلفیق کنید. برای این‌کار دستور git merge develop را اجرا کنید.

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

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

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

مخزن یا repository که به اختصار به آن repo نیز گفته می‌شود می‌تواند شامل فولدر، فایل، تصویر، ویدیو و هر آنچه پروژه‌ی شما به آن نیاز دارد باشد. گیت‌هاب در ابتدای ساخت پروژه امکان افزودن README و سایر موارد مانند لایسنس را در اختیار می‌گذارد.

مخزن اول شما با نام hello-world می‌تواند مکانی برای ذخیره کردن ایده‌ها، منابع یا حتی اشتراک‌گذاری و بحث در مورد چیزهای مختلف باشد.

• برای ساخت یک مخزن جدید در گوشه‌ی بالا سمت راست و نزدیک به آواتار یا نماد کاربری شما، روی + و سپس New repository کلیک کنید.
• توضیح کوتاهی بنویسید.
• در صورت تمایل به اضافه کردن README گزینه‌ی Initialize this repository with a README را انتخاب کنید.
• روی Creat repository کلیک کنید.

برنچینگ روشی برای کار همزمان روی نسخه‌های مختلف یک مخزن است.

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

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

نمودار زیر روندی را که یک شاخه‌ی جانبی با نام feature باید طی کند تا با شاخه‌ی اصلی تلفیق شود نمایش می‌دهد.

• برای ساخت یک شاخه‌ی جدید به مخزن جدیدی که با نام hello-world ساخته‌اید بروید.
• روی فهرست بازشونده‌ی موجود در بالای فهرست فایل‌ها که روی آن نام شاخه نوشته شده است کلیک کنید. در تکست‌باکس بازشده نام شاخه‌ی جدید، مثلا readme-edits را وارد کنید.
• روی دکمه‌ی Create branch کلیک کنید یا دکمه‌ی Enter را در کیبورد خود بزنید.

حالا دو شاخه دارید؛ یکی master و دیگری readme-edits که کاملا شبیه به هم هستند؛ البته تا زمانی که تغییری در هیچ‌یک اعمال نکرده‌ایم.

حالا که شاخه‌ی جدیدی با محتویات یکسان با شاخه‌ی اصلی داریم، بدون ترس از خرابکاری ویرایش‌های خود را آغاز می‌کنیم.

در گیت‌هاب به تغییرات اعمال‌شده کامیت (commit) می‌گویند. هر کامیت یک پیام کامیت نیز به همراه دارد که توضیح کوتاهی در رابطه با دلیل اعمال آن تغییر است. پیام‌های کامیت به سایر مشارکت‌کنندگان در پروژه این امکان را می‌دهد که متوجه شوند شما چه تغییری را به چه دلیل اعمال کرده‌اید.

• برای اعمال یک تغییر روی فایل README.md کلیک کنید.
• روی آیکون مداد در گوشه‌ی بالا سمت راست کلیک کنید تا بتوانید آن را ویرایش کنید.
• در ویرایشگر، کمی درباره‌ی خود بنویسید.
• یک پیام کامیت برای توصیف تغییرات خود بنویسید.
• روی دکمه‌ی Commit changes کلیک کنید.

تغییرات ایجادشده در فایل README تنها در شاخه‌ی readme-edits اعمال‌ شده‌اند. حالا این شاخه دارای تغییراتی نسبت به شاخه‌ی master است.

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

با استفاده از سیستم منشن در گیت‌هاب می‌توانید در سیستم پیام‌ pull request خود از سایر افراد یا تیم‌ها درخواست کنید که درباره‌ی ویرایش‌های شما نظر بدهند.

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

در این گام پایانی، نحوه‌ی تلفیق تغییرات شاخه‌ی فرعی در شاخه‌ی master را بررسی می‌کنیم.

• روی دکمه‌ی سبزرنگ 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 کلیک کنید.

در این مرحله به صفحه‌ی راه‌انداری سریع هدایت خواهید شد. این صفحه امکان بارگذاری پروژه‌ی گیت را به ما خواهد داد. برای انجام این‌کار اولین سطر زیر or push an existing repository from the command line... را کپی کنید و آن را در ترمینال یعنی همان‌جایی که تا کنون روی آن کار می‌کردیم پیست کنید.

این‌کار به ما خروجی نخواهد داد. حالا همین کار را برای سطر دوم انجام دهید. در این مرحله تغییرات ما به گیت‌هاب منتقل می‌شود و خروجی مشابه آن‌چه در تصویر زیر می‌بینید خواهد بود. حالا در مرورگر خود صفحه‌ی گیت‌هاب را ریفرش کنید. فایل‌های README.md و index.php به‌عنوان اولین فایل‌های پروژه نمایش داده می‌شوند و محتویات README.md در پایین صفحه نمایان می‌شود.

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