آشنایی با گیت هاب (بخش دوم)
فهرست مطالب
آخرین به روزرسانی در 29/07/2022
ما در بخش اول آشنایی و آموزش گیت هاب به معرفی گیت هاب و یک سری از عملگرهای مهم آن پرداختیم حال در این مقاله قصد داریم به بخش دوم آموزش پرداخته و سایر اصطلاحات ، نکات و عملگرهای دیگر گیت هاب را نیز آموزش دهیم .
(توجه تمامی نکات ، توضیحات و آموزش های زیر از منبع رسمی و داکیومنت خود گیت هاب تهیه و ترجمه شده است که به سه منبع زیر تقسیم می شود :
پیشنیاز این مقاله بخش اول آشنایی با گیت هاب می باشد.
سیستم کنترل نسخه توزیع شده چیست؟
Git نمونه ای از سیستم کنترل نسخه توزیع شده ((DVCS است که معمولاً برای توسعه نرم افزارهای منبع باز و تجاری استفاده می شود. DVCS اجازه دسترسی کامل به هر فایل ، شاخه و تکرار یک پروژه را می دهد و به هر کاربر اجازه می دهد به یک تاریخچه کامل و مستقل از همه تغییرات دسترسی پیدا کند.
برخلاف سیستم های کنترل نسخه متمرکز قدیمی ، DVCS مانند Git نیازی به اتصال ثابت به مخزن مرکزی ندارند. توسعه دهندگان می توانند در هر مکانی کار کنند و در هر منطقه زمانی به صورت نامتقارن همکاری کنند.
بدون کنترل نسخه ، اعضای تیم مشمول کارهای اضافی ، زمان بندی کندتر و چندین نسخه از یک پروژه واحد هستند. برای از بین بردن کارهای غیر ضروری ، Git و سایر VCS ها به هر یک از مشارکت کنندگان یک دید واحد و سازگار از یک پروژه می دهند و کارهایی را که در حال انجام است ، نشان می دهد.
مشاهده یک تاریخ شفاف از تغییرات ، اینکه چه کسی آنها را ایجاد کرده است و چگونه آنها در توسعه یک پروژه کمک می کنند به اعضای تیم کمک می کند تا در حین کار مستقل در یک راستا بمانند.
چرا گیت ؟
طبق آخرین نظرسنجی توسعه دهندگان Stack Overflow ، بیش از 70 درصد توسعه دهندگان از Git استفاده می کنند و این پرفروش ترین VCS در جهان است.
معمولاً برای توسعه نرم افزارهای منبع باز و تجاری استفاده می شود و مزایای قابل توجهی برای افراد ، تیم ها و مشاغل دارد.
Git به توسعه دهندگان اجازه می دهد تا کل زمان بندی تغییرات ، تصمیمات و پیشرفت هر پروژه خود را در یک مکان مشاهده کنند. از زمانی که آنها به تاریخچه پروژه دسترسی پیدا می کنند ، توسعه دهنده تمام زمینه های مورد نیاز برای درک آن و شروع به مشارکت را دارد.
توسعه دهندگان در هر منطقه زمانی کار می کنند. با DVCS مانند Git ، همکاری می تواند در هر زمان با حفظ یکپارچگی کد منبع اتفاق بیفتد ؛ با استفاده از شعب ، توسعه دهندگان می توانند با خیال راحت تغییراتی در کد تولید ارائه دهند.
مشاغلی که از Git استفاده می کنند می توانند موانع ارتباطی بین تیم ها را از بین ببرند و آنها را بر انجام بهترین کار متمرکز کنند. به علاوه ، Git این امکان را فراهم می آورد تا متخصصان را در یک تجارت برای همکاری در پروژه های بزرگ تراز کند.
دستورات اولیه گیت
برای استفاده از Git ، توسعه دهندگان از دستورات خاصی برای کپی ، ایجاد ، تغییر و ترکیب کد استفاده می کنند. این دستورات را می توان مستقیماً از خط فرمان یا با استفاده از برنامه ای مانند GitHub Desktop یا Git Kraken اجرا کرد. در اینجا چند دستور رایج برای استفاده از Git آورده شده است که به شرح زیر می باشد :
git init : یک مخزن جدید Git را راه اندازی می کند و ردیابی یک فهرست موجود را آغاز می کند. این یک زیر پوشه مخفی در فهرست موجود اضافه می کند که ساختار داده های داخلی مورد نیاز برای کنترل نسخه را در خود جای داده است.
git clone : یک نسخه محلی از پروژه ای را ایجاد می کند که قبلاً از راه دور وجود داشته است. کلون شامل تمام پرونده ها ، سابقه و شاخه های پروژه است.
Git add : مراحل تغییر Git را در پایگاه کد توسعه دهندگان دنبال می کند ، اما لازم است مراحل را انجام داده و از تغییرات آن برای ثبت آنها در تاریخ پروژه استفاده کنید.
این دستور مرحله بندی را انجام می دهد ، اولین قسمت از این فرآیند دو مرحله ای ؛ هرگونه تغییری که انجام می شود بخشی از تصویر بعدی و بخشی از تاریخ پروژه خواهد شد. مرحله بندی و انجام جداگانه به توسعه دهندگان امکان کنترل کامل بر تاریخ پروژه خود را بدون تغییر نحوه کدگذاری و کار می دهد.
git commit : مراحل فوری را در تاریخ پروژه ذخیره می کند و روند ردیابی تغییرات را تکمیل می کند. به طور خلاصه ، یک تابع مانند عکس گرفتن عمل می کند ؛ هر چیزی که با git add مرحله بندی شده باشد بخشی از تصویر فوری با git commit می شود.
git status : تغییرات را بدون ردیابی ، اصلاح شده یا مرحله ای نشان می دهد.
git branch : شاخه هایی را که به صورت محلی روی آنها کار می شود نشان می دهد.
git merge : خطوط توسعه را با هم ادغام می کند. این دستور معمولاً برای ترکیب تغییرات ایجاد شده در دو شاخه مجزا استفاده می شود. به عنوان مثال ، زمانی که یک توسعه دهنده می خواهد تغییرات را از یک شاخه ویژگی به شاخه اصلی ترکیب کند ، ادغام می شود.
git pull : خط توسعه commit را با به روزرسانی های همتای راه دور خود به روز می کند. توسعه دهندگان از این دستور در صورتی استفاده می کنند که هم تیمی خود به شعبه ای از راه دور وارد شده باشد و آنها می خواهند این تغییرات را در محیط محلی خود منعکس کنند.
git push : مخزن راه دور را با هر گونه commit که به صورت محلی در یک شعبه انجام می شود به روز می کند.
آَشنایی با fork
پس از مدتی استفاده از GitHub توسط خودتان ، ممکن است متوجه شوید که مایل به مشارکت در پروژه شخص دیگری هستید ؛ یا شاید دوست دارید از پروژه کسی به عنوان نقطه شروع پروژه خود استفاده کنید. این فرایند به عنوان چنگ زدن یا همان فورک شناخته می شود.
ایجاد “fork” تولید یک نسخه شخصی از پروژه شخص دیگری است. فورک ها نوعی پل ارتباطی بین مخزن اصلی و نسخه شخصی شما عمل می کنند.
با ارائه تغییرات خود در پروژه اصلی ، می توانید درخواست های Pull را برای کمک به بهبود پروژه های دیگران ارسال کنید. فورکینگ هسته اصلی برنامه نویسی اجتماعی در GitHub است.
نحوه ی استفاده :
- روی دکمه Fork در سربرگ مخزن کلیک کنید.
- پس از اتمام کار ، به کپی مخزن Spoon-Knife منتقل می شوید.
کلون کردن فورک
شما با موفقیت مخزن Spoon-Knife را فورک کرده اید ، اما این مخزن، فقط در GitHub وجود دارد. برای اینکه بتوانید روی پروژه کار کنید ، باید آن را در رایانه خود کلون کنید.
اگر از GitHub Desktop استفاده می کنید ، این فرایند بسیار ساده است. در چنگال Spoon-Knife ، به نوار سمت راست بروید و روی Clone یا Download کلیک کنید ؛ نحوه کلون سازی به خود شما بستگی دارد ؛ برخی از گزینه ها با خط فرمان یا با استفاده از GitHub Desktop شبیه سازی می شوند.
ایجاد و پیش بردن تغییرات
- با استفاده از ویرایشگر متن مورد علاقه خود ، چند تغییر در پروژه ایجاد کنید. برای مثال ، می توانید متن را در index.html تغییر دهید تا نام کاربری GitHub خود را اضافه کنید.
- وقتی آماده ارائه تغییرات خود هستید ، تغییرات خود را مرحله بندی کرده و متعهد شوید.
- می توانید تغییرات بیشتری انجام دهید و عکس های فوری مربوط به commit بیشتری بگیرید. هنگامی که آماده انتقال تغییرات خود به GitHub.com هستید ، تغییرات خود را به ریموت فشار دهید.
درخواست pull
در نهایت ، شما آماده پیشنهاد تغییرات در پروژه اصلی هستید ، این آخرین مرحله در تولید فورک پروژه شخص دیگری است و مسلماً مهمترین آن است. اگر تغییری را ایجاد کرده اید که احساس می کنید به نفع کل جامعه ی گیت هاب است ، قطعاً باید مشارکت مجدد را در نظر بگیرید.
برای انجام این کار ، به مخزن GitHub.com که محل پروژه شما است بروید ؛ بنری را مشاهده خواهید کرد که نشان می دهد اخیراً شعبه جدیدی را ایجاد کرده اید و می توانید این شعبه را “بالادست” به مخزن اصلی ارسال کنید مانند تصویر :
با کلیک بر روی مقایسه و کشیدن درخواست شما را به یک صفحه بحث می فرستد ، جایی که می توانید عنوان و توضیحات اختیاری را وارد کنید. ارائه اطلاعات مفید و منطقی برای اینکه چرا در ابتدا این درخواست Pull را انجام می دهید ، بسیار مهم است.
صاحب پروژه باید بتواند تعیین کند که آیا تغییر شما به اندازه ای که فکر می کنید برای همه مفید است یا خیر، سپس روی Send request request کلیک کنید.
مشکلات پروژه و راه های کمک گیری
مشکلات راهی عالی برای پیگیری وظایف ، پیشرفت ها و اشکالات پروژه های شما هستند. آنها شبیه ایمیل هستند ، با این تفاوت که می توان آنها را با بقیه اعضای تیم به اشتراک گذاشت و در مورد آنها صحبت کرد ؛ اکثر پروژه های نرم افزاری دارای نوعی ردیاب اشکال هستند ، این ردیاب GitHub Issues نامیده می شود و بخش مخصوص خود را در هر مخزن دارد.
در قسمت مشکلات هر کدام از اصطلاحات و نمادک ها به مفاهیم زیر است :
- عنوان و توضیحات توضیح می دهد که موضوع چیست.
- برچسب های دارای کد رنگی به شما کمک می کند مسائل خود را دسته بندی و فیلتر کنید (درست مانند برچسب های موجود در ایمیل).
- یک milestone مانند یک ظرف برای مسائل عمل می کند. این برای ارتباط مسائل با ویژگی های خاص یا مراحل پروژه مفید است.
- یک assignee وظیفه دارد در هر زمان روی موضوع کار کند.
- نظرات به هر کسی که به مخزن دسترسی دارد اجازه می دهد تا بازخورد خود را ارائه دهد.
Milestones, Labels and Assignees
هنگامی که تعداد زیادی از مسائل را جمع آوری کردید ، ممکن است پیدا کردن مواردی که به آنها اهمیت می دهید ، برای شما سخت باشد. Milestones ، Labels و Assignees ویژگی های بسیار خوبی برای فیلتر و دسته بندی مسائل هستند.
با کلیک روی چرخ دنده های مربوطه در نوار کناری در سمت راست ، می توانید یک Milestones ، Assignees و Labels ها را تغییر دهید یا اضافه کنید.
Milestones
Milestones گروهی از مسائل هستند که مربوط به یک پروژه ، ویژگی یا دوره زمانی است. مردم از آنها به طرق مختلف در توسعه نرم افزار استفاده می کنند. برخی از نمونه های مهم در GitHub عبارتند از:
- راه اندازی بتا : اشکالات فایل که باید قبل از راه اندازی بتا پروژه خود برطرف کنید ، این یک راه عالی برای اطمینان از این است که چیزی را از دست ندهید.
- اکتبر اسپرینت : پرونده هایی را که می خواهید در ماه اکتبر روی آنها کار کنید ، فایل کنید ، یک راه عالی برای تمرکز تلاش های خود در مواقعی که کارهای زیادی وجود دارد.
- طراحی مجدد : مشکلات مربوط به طراحی مجدد پروژه شما یک راه عالی برای جمع آوری ایده در مورد آنچه باید کار کنید.
Labels
برچسب ها راهی عالی برای سازماندهی انواع مختلف مسائل هستند. مشکلات می توانند به تعداد دلخواه برچسب داشته باشند و شما می توانید یک یا چند برچسب را به طور همزمان فیلتر کنید.
Assignees
هر شماره می تواند دارای یک Assignees باشد ، یک نفر مسئول پیشبرد موضوع است. گزینش کنندگان به همان ترتیب نقاط عطف انتخاب می شوند ، از طریق نوار خاکستری در بالای شماره.