آموزش کار با گیت هاب

Repository چیست ؟

آشنایی با اصطلاح  Repo

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

کاربرد repository

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

گیت (Git) چیست؟

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

گیت‌هاب چیست؟

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

کاری که گیت‌هاب می‌کند

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

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

همان‌طور که احتمالا حدس زده اید، این کد باید ارتقا یابد.

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

1. گیت‌هاب به هر فرد این امکان را می‌دهد که فضایی برای مدیریت کد ‌ها و پروژه‌های خود ایجاد کند بخش (Version Control)
2. و در عین حال این امکان را نیز فراهم می‌کند که سایر افراد هم بتوانند این کدها را به منظور بهبود، رفع خطا و … ، ویرایش نمایند. به این ترتیب پروژه ها با هم‌فکری و هم‌کاری افراد مختلف و با سرعت بیشتری توسعه می‌یابند بخش (Source Code Management).

مثلا به عنوان مثال پروژه لایبری GSM برای آردوینو را در گیت هاب ببنید و بعد ادامه نوشته را بخوانید.

نحوه استفاده از  گیت‌هاب

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

• روش دانلود فایل‌ها از گیت‌هاب (Download ZIP)
• روش ایجاد و مدیریت پروژه در گیت‌هاب (Managing Repos)
• روش ویرایش و ارتقا کد ها و پروژه‌ها (Pull Requests)
• آشنایی و روش کار با بخشی دیگری از قابلیت‌های وسیع گیت هاب؛ تحت عنوان Wiki and Issues

روش دانلود فایل‌ها از گیت‌هاب

اگر نیاز داشتید یکی از کدهایی که در صفحات عمومی گیت‌هاب قرار دارد را دانلود و استفاده کنید، کافی‌ست به شیوه‌ زیر عمل کنید:

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

توجه کنید که اگر در حال پرسه زدن در کد های پروژه بزرگی هستید و تصادفا کد مورد نیاز خودتان را آن‌جا می‌یابید، نخواهید توانست با راست کلیک و انتخاب save as آن فایل را به صورت کد ذخیره کنید. بلکه تنها یک نسخه روی سایت از آن را دریافت می‌کنید. برای دریافت کد،  باید از مسیر Download ZIP که توضیح داده شد بروید.

روش ایجاد و مدیریت پروژه در گیت‌هاب

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

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

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

در طول نصب، در یکی از مراحل ممکن است از شما بخواهد که کامپیوتر خود را به منظور پیدا کردن Repo های قبلی جستجو کنید. پیشنهاد ما این است که این کار را نکنید. این کار زمان زیادی می‌برد و احتمالا شما از قبل repo ی ذخیره‌ شده ای ندارید و اِلا در حال خواندن این آموزش نبودید!

خب ، اما زمانی که این نرم افزار نصب شد، برای ادامه آموزش به یک repo نیاز داریم. از آن‌جا که احتمالا از قبل repo  ای ندارید، می‌توانید یکی را از پروژه های sparkfun را دانلود کنید.

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

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

“chipaddict/Github_Tutorial”

و کلماتی که در زیر این عبارت آمده اند: “forked from sparkfun/Github_Tutorial” . این‌ها نشان‌ می‌دهند که این پروژه در اکانت شما کپی شده است.

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

حال که یک کپی آنلاین از پروژه خود دارید، بر روی گزینه ‘Clone or Download’ کلیک کنید  و سپس ‘Open in Desktop’ را بزنید. این کار شما را به صفحه‌ی ویندوز گیت‌هاب می‌برد.

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

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

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

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

قابلیت‌های دیگری برای ردیابی یک کد

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

در اینجا می‌توانید مسیری که مخازن ذخیره سازی شما در آن وجود دارند را ببینید (آدرس Clone path). همان‌طور که در تصویر می‌بینید، ما در اینجا آدرس یک در اپ‌باکس را برای این مسیر تعیین کرده‌ایم. شما میتوانید هر پوشه ای را در روی سیستم خودتان انتخاب کنید.

اکنون شما می‌دانید که repoهای‌تان در کجا ذخیره می‌شوند. به آن آدرس بروید و رپو ای که دانلود کردیم را باز کنید :

فایل :  Github_Tutorial.ino

در  Windows Notepad یا IDE آردوینو ، تعریف متغیر را از byte به int تغییر دهید. این تغییر را ذخیره کنید و به GitHub GUI بازگردید.

می‌بینید که گیت‌هاب متوجه این تغییر شده است! یک نقطه نیز بر روی گزینه‌ی changes در بالای صفحه ظاهر شده است.

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

کوچک‌ترین تغییری با هایلایت شدن مشخص شده است.

اما جالب است بدانیم repo ها چگونه این کارهای هیجان‌انگیر را انجام می‌دهند!

• شما یک نسخه‌ی کپی از repoی شخصی(محلی) تان دارید که بر روی آن کار می‌کنید(Local working copy)،
• یک نسخه از خود local repo
• و یک نسخه ی عمومی از (repo ( global repo

Local working copy چیست؟ تمام کد‌هایی که شما در طول سروکله زدن با پروژه‌تان به طور شخصی می‌نویسید، تمام pcb هایی که طراحی می‌کنید و … همه و همه در این نسخه در کامپیوتر شما ذخیره می‌شوند. تا زمانی که شما پنجره گیت‌هاب را باز نکنید و این تغییرات را بر روی local repo   اعمال نکنید،  این تغییرات برای سایر افرادی که پروژه شما را در گیت‌هاب می‌بینند، قابل رویت نخواهد بود و تنها خودتان آن‌ها را می‌بینید. در واقع Local working copy مشابه یک دفتر باطله شخصی است.

local repo چیست؟ اگر بخواهیم تغییراتی که لازم است را به پروژه اعمال کنیم، پیش از این کار، باید راجع به این تغییرات توضیحاتی بدهیم. به طور کامل توضیح می‌دهیم که این تغییرات چه هستند و چرا اعمال شده اند. سپس گزینه ‘Commit to master’ را انتخاب می‌کنیم.

به عنوان یک قانون کلی همواره به خاطر داشته باشید که بهتر است تغییرات را مرتبا و قبل از آن‌که روی هم تلنبار شوند، در local repo اعمال کنید. در غیر این صورت اگر بین هر بار اعمال تغییرات به طور مثال 4، 5 ماهی فاصله بیندازید، خواهید دید که بعضا فراموش کرده‌اید که این یا آن بخش کد یا طراحی را به چه علت می‌خواستید تغییر دهید!

خب، پس از آن‌که بر روی commit کلیک کردید، دکمه sync نمایان می‌شود.

می‌بینید که هیچ تغییر اعمال شده‌ای از قبل نداریم، اما تغییراتی داریم که هنوز sync نشده‌اند (unsynced commits)

معنای این وضعیت این است که ما در نسخه‌ی محلی یا local تغییراتی ایجاد کرده‌ایم که هنوز به نسخه‌ی عمومی یا global منتقل نشده‌اند.

Global repo چیست؟ 

اگر ‘Sync’ را بزنیم، این تغییرات به نسخه‌ی عمومی صادر شده ، در اکانت گیت‌هاب ما ثبت شده و برای سایرین نیز قابل مشاهده خواهند بود.

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

می‌بینیم که توضیحاتی که در رابطه‌ با این تغییرات کامنت کردیم نیز این‌جا ثبت شده‌اند. هم‌‌چنین نسخه‌ی قبلی ( که در این‌جا همان نسخه‌ی اولیه بدون تغییر است) نیز وجود دارد.

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

مرزهای استفاده رایگان از گیت هاب

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

آن‌چه تا این لحظه آموختیم

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

روش ویرایش و ارتقا کد ها و پروژه‌ها

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

اما قدرت واقعی آن‌ها زمانی مشخص می‌شود که شما یک پروژه را با همکاری چند نفر و به صورت گروهی ویرایش کنید.

در این حالت که افراد مختلف تغییرات مختلف ایجاد می‌کنند، چگونه باید این تغییرات با یکدیگر ترکیب شوند؟

Pull Requests پروسه‌ای ست که به هر یک از این افراد مشارکت‌کننده، امکان ارجاع به کد اصلی را می‌دهد.

فرض کنید ما در پروژه‌ای به نام Github_Tutorial تغییراتی ایجاد کرده‌ایم. حال می‌خواهیم صاحب اصلی پروژه را از این تغییرات باخبر کنیم. به این منظور روی دکمه‌ی new pull request   کلیک می‌کنیم.

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

پس از نوشتن توضیحات، create pull request را می‌زنیم.

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

تصویر فوق، نمایی از صفحه‌ی pull request از منظر دریافت کننده request هاست. او می‌تواند هر درخواستی را پذیرفته و با کد اصلیmerge کند و یا آن‌که اگر بحثی در مورد آن دارد، با فرستنده مطرح کند.

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

قابلیت‌های گیت هاب Wiki and Issues

آشنایی و روش کار با بخشی دیگری از قابلیت‌های وسیع گیت هاب؛ تحت عنوان Wiki and Issues

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

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

همچنین هر repo ، یک wiki  هم دارد که فایلی سودمند به منظور ذخیره سازی سوالات و توضیحات متداول در مورد آن پروژه است.

یک مثال خوب برای استفاده از wiki  در یک پروژه را در تصویر زیر می‌بینید:

خب ، تمام شد! امیدواریم که در پروژه بعدی‌تان از git و github استفاده کنید و تجربه‌ی لذت بخش کدزنی و یادگیری دست‌جمعی را از دست ندهید!

منبع : melec.ir