2nd Edition

6.3 GitHub (گیت هاب) - نگهداری یک پروژه (Maintaining a Project)

نگهداری یک پروژه (Maintaining a Project)

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

ایجاد یک مخزن جدید (Creating a New Repository)

بیایید یک مخزن جدید بسازیم تا کد پروژه‌مان را به اشتراک بگذاریم. با کلیک روی دکمه‌ی «New repository» در سمت راست داشبورد شروع کنید، یا از دکمه‌ی «+» در نوار ابزار بالای صفحه کنار نام کاربری‌تان استفاده کنید، همانطور که در The “New repository” dropdown دیده می‌شود.

نمودار 109. The “Your repositories” area

نمودار 110. The “New repository” dropdown

این شما را به فرم “new repository” هدایت می‌کند:

نمودار 111. The “new repository” form

تنها کاری که واقعاً باید انجام دهید این است که نام پروژه را وارد کنید؛ بقیه فیلدها کاملاً اختیاری هستند. فعلاً فقط روی دکمه‌ی «Create Repository» کلیک کنید، و همین‌طور — یک مخزن جدید روی گیت‌هاب با نام <user>/<project_name> دارید.

از آنجا که هنوز هیچ کدی در این مخزن نیست، گیت‌هاب به شما دستورالعمل‌هایی برای ساخت یک مخزن گیت کاملاً جدید یا اتصال یک پروژه‌ی گیت موجود نشان می‌دهد. ما اینجا وارد جزئیات نمی‌شویم؛ اگر نیاز به بازخوانی دارید، بخش مقدمات گیت (git basics chapter) را مطالعه کنید.

حالا که پروژه‌ی شما روی گیت‌هاب میزبانی شده است، می‌توانید آدرس URL آن را به هر کسی که می‌خواهید پروژه را با او به اشتراک بگذارید، بدهید. هر پروژه‌ای روی گیت‌هاب از طریق HTTPS به صورت https://github.com/<user>/<project_name> و از طریق SSH به صورت git@github.com:<user>/<project_name> قابل دسترسی است. گیت می‌تواند از هر دو URL دریافت و ارسال کند، اما دسترسی به آن‌ها بر اساس اعتبارنامه‌های کاربری که به آن‌ها متصل می‌شوند کنترل می‌شود.

یادداشت

اغلب ترجیح داده می‌شود که URL مبتنی بر HTTPS را برای پروژه‌های عمومی به اشتراک بگذارید، چرا که کاربر برای کلون کردن نیازی به حساب کاربری گیت‌هاب ندارد. اگر URL SSH را بدهید، کاربران باید حساب کاربری و کلید SSH آپلود شده داشته باشند تا بتوانند به پروژه دسترسی پیدا کنند. همچنین، URL HTTPS همان آدرسی است که آن‌ها می‌توانند در مرورگر خود برای مشاهده پروژه وارد کنند.

اضافه کردن همکاران (Adding Collaborators)

اگر با افرادی کار می‌کنید که می‌خواهید دسترسی تعهد (commit) به آن‌ها بدهید، باید آن‌ها را به عنوان «collaborators» اضافه کنید. اگر بن، جف و لوئیس همه در گیت‌هاب حساب کاربری بسازند و شما بخواهید دسترسی push به مخزن خود بدهید، می‌توانید آن‌ها را به پروژه اضافه کنید. این کار به آن‌ها دسترسی «push» می‌دهد، بدین معنا که هم به پروژه و مخزن گیت خواندن و نوشتن دارند.

روی لینک “Setting” در پایین نوار کناری سمت راست کلیک کنید.

نمودار 112. The repository settings link

سپس از منوی سمت چپ «Collaborators» را انتخاب کنید. بعد، فقط نام کاربری را در کادر تایپ کنید و روی «Add collaborator» کلیک کنید. می‌توانید این کار را به هر تعداد که دوست دارید تکرار کنید تا به همه‌ی افراد دلخواه دسترسی بدهید. اگر نیاز به لغو دسترسی داشتید، فقط روی «X» در سمت راست ردیف آن‌ها کلیک کنید.

نمودار 113. The repository collaborators box

مدیریت درخواست‌های کشش (Managing Pull Requests)

حالا که یک پروژه با مقداری کد دارید و شاید چند همکار که دسترسی push دارند، بیایید ببینیم وقتی خودتان یک Pull Request دریافت می‌کنید، چه کار باید بکنید.

درخواست‌های Pull می‌توانند یا از یک شاخه در یک فورک مخزن شما بیایند یا از شاخه‌ای دیگر در همان مخزن. تنها تفاوت این است که درخواست‌های Pull در فورک‌ها اغلب از افرادی هستند که شما نمی‌توانید به شاخه آن‌ها push کنید و آن‌ها هم نمی‌توانند به شاخه شما push کنند، در حالی که در درخواست‌های Pull داخلی معمولاً هر دو طرف به شاخه دسترسی دارند.

برای این مثال‌ها فرض کنیم شما “tonychacon” هستید و یک پروژه کد آردوینو به نام «fade» ساخته‌اید.

اعلان‌های ایمیلی (Email Notifications)

کسی می‌آید و تغییری در کد شما ایجاد می‌کند و یک Pull Request برای شما ارسال می‌کند. شما باید ایمیلی دریافت کنید که در مورد Pull Request جدید اطلاع دهد و این ایمیل باید چیزی شبیه به Email notification of a new Pull Request باشد.

نمودار 114. Email notification of a new Pull Request

 چند نکته درباره این ایمیل وجود دارد که باید بدانید.
این ایمیل یک خلاصه کوچک از تغییرات (diffstat) به شما می‌دهد — فهرستی از فایل‌هایی که در درخواست Pull تغییر کرده‌اند و میزان تغییرات آن‌ها.
همچنین یک لینک به درخواست Pull در گیت‌هاب به شما ارائه می‌کند.
چند URL نیز دارد که می‌توانید از طریق خط فرمان از آن‌ها استفاده کنید.

اگر به خطی که نوشته git pull <url> patch-1 دقت کنید، این یک روش ساده برای ادغام یک شاخه از راه دور بدون نیاز به اضافه کردن remote است. ما این موضوع را سریعاً در بررسی شاخه‌های ریموت (Checking Out Remote Branches) مرور کردیم. اگر بخواهید، می‌توانید یک شاخه موضوعی (topic branch) ایجاد و به آن سوئیچ کنید و سپس این دستور را اجرا کنید تا تغییرات درخواست Pull را ادغام کنید.

URLهای جالب دیگر، URLهای .diff و .patch هستند که همان‌طور که حدس می‌زنید، نسخه‌های unified diff و patch از درخواست Pull را ارائه می‌دهند. از نظر فنی، می‌توانید کار درخواست Pull را با چیزی شبیه به این ادغام کنید:

$ curl https://github.com/tonychacon/fade/pull/1.patch | git am

همکاری روی درخواست کشش (Collaborating on the Pull Request)

همان‌طور که در روند کاری گیت‌هاب (The GitHub Flow) توضیح دادیم، اکنون می‌توانید با شخصی که درخواست Pull را باز کرده است گفتگو کنید. می‌توانید روی خطوط خاصی از کد نظر بگذارید، روی کامیت‌های کامل یا کل درخواست Pull نظر بدهید و در همه جا از Markdown با سبک GitHub استفاده کنید.

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

نمودار 115. Responses to emails are included in the thread

وقتی کد به جایی رسید که راضی بودید و می‌خواهید آن را ادغام کنید، می‌توانید کد را دانلود کرده و محلی ادغام کنید، یا با دستور git pull <url> <branch> که قبلاً دیدیم، یا با افزودن فورک به عنوان remote و گرفتن و ادغام آن.

اگر ادغام ساده باشد، می‌توانید به سادگی روی دکمه «Merge» در سایت گیت‌هاب کلیک کنید. این کار یک ادغام «non-fast-forward» انجام می‌دهد، یعنی یک کامیت ادغام ایجاد می‌کند حتی اگر ادغام fast-forward ممکن باشد. این یعنی هر بار که دکمه merge را می‌زنید، یک کامیت ادغام ساخته می‌شود. همان‌طور که در Merge button and instructions for merging a Pull Request manually می‌بینید، گیت‌هاب همه این اطلاعات را اگر روی لینک راهنما کلیک کنید، به شما نشان می‌دهد.

نمودار 116. Merge button and instructions for merging a Pull Request manually

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

رفرنس‌های درخواست کشش (Pull Request Refs)

گیت‌هاب در واقع شاخه‌های درخواست Pull را به عنوان شاخه‌های شبه (pseudo-branches) روی سرور تبلیغ می‌کند. به طور پیش‌فرض وقتی کلون می‌کنید آن‌ها را دریافت نمی‌کنید، اما به شکلی پنهان وجود دارند و می‌توانید به راحتی به آن‌ها دسترسی پیدا کنید.

برای نشان دادن این موضوع، از یک دستور سطح پایین (که اغلب به آن دستور «لوله‌کشی» یا plumbing گفته می‌شود و در ابزارها و دستورات سطح پایین (Plumbing and Porcelain) بیشتر درباره آن می‌خوانیم) به نام ls-remote استفاده می‌کنیم. این دستور معمولاً در عملیات روزمره گیت استفاده نمی‌شود اما مفید است برای اینکه به ما نشان دهد چه ارجاعاتی روی سرور وجود دارد.

اگر این دستور را روی مخزن “blink” که قبلاً استفاده می‌کردیم اجرا کنیم، فهرستی از همه شاخه‌ها، تگ‌ها و ارجاعات دیگر در مخزن به ما می‌دهد.

$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d	HEAD
10d539600d86723087810ec636870a504f4fee4d	refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e	refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3	refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1	refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d	refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a	refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c	refs/pull/4/merge

البته، اگر در مخزن خود باشید و دستور git ls-remote origin یا هر ریموت دیگری که می‌خواهید بررسی کنید را اجرا کنید، چیزی مشابه این مشاهده خواهید کرد.

اگر مخزن روی GitHub باشد و هر درخواست Pull (Pull Request) باز شده‌ای داشته باشید، این ارجاعات را خواهید دید که با refs/pull/ شروع می‌شوند. این‌ها اساساً شاخه هستند، اما چون زیر refs/heads/ نیستند، معمولاً هنگام کلون کردن یا fetch گرفتن از سرور به شما نمایش داده نمی‌شوند — فرایند fetch معمولاً آن‌ها را نادیده می‌گیرد.

برای هر درخواست Pull دو ارجاع وجود دارد — ارجاعی که به /head ختم می‌شود دقیقاً به همان کامیتی اشاره می‌کند که آخرین کامیت در شاخه درخواست Pull است. پس اگر کسی در مخزن ما یک درخواست Pull باز کند و شاخه‌اش به نام bug-fix باشد و به کامیت a5a775 اشاره کند، در مخزن خودمان شاخه‌ای به نام bug-fix نخواهیم داشت (چون آن در فورک آن‌ها است)، اما داشتن ارجاع pull/<pr#>/head که به a5a775 اشاره می‌کند، خواهیم داشت. این یعنی می‌توانیم به آسانی همه شاخه‌های درخواست Pull را یکجا دریافت کنیم بدون اینکه مجبور باشیم تعداد زیادی ریموت اضافه کنیم.

حالا، می‌توانید کاری مانند دریافت مستقیم ارجاع را انجام دهید.

$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
 * branch            refs/pull/958/head -> FETCH_HEAD

این به Git می‌گوید: «به ریموت `origin وصل شو، و ارجاع به نام refs/pull/958/head را دانلود کن.» Git با کمال میل این کار را انجام می‌دهد و همه چیز لازم برای ساختن آن ارجاع را دانلود می‌کند و اشاره‌گری به کامیتی که می‌خواهید را زیر `.git/FETCH_HEAD قرار می‌دهد. شما می‌توانید بعد از آن با دستور git merge FETCH_HEAD این را در شاخه‌ای که می‌خواهید تست کنید ادغام کنید، اما پیام کامیت ادغام کمی عجیب به نظر می‌رسد. همچنین، اگر تعداد زیادی درخواست Pull را بررسی می‌کنید، این کار خسته‌کننده می‌شود.

یک روش هم برای دریافت تمام درخواست‌های Pull و به‌روزرسانی آن‌ها هر بار که به ریموت وصل می‌شوید وجود دارد. فایل .git/config را در ویرایشگر مورد علاقه‌تان باز کنید و دنبال ریموت origin بگردید. باید چیزی شبیه به این باشد:

[remote "origin"]
    url = https://github.com/libgit2/libgit2
    fetch = +refs/heads/*:refs/remotes/origin/*

خطی که با fetch = شروع می‌شود، یک “refspec” است. روشی برای نگاشت نام‌ها در ریموت با نام‌ها در دایرکتوری محلی .git شماست. این refspec خاص به Git می‌گوید: «مواردی که در ریموت زیر refs/heads هستند باید در مخزن محلی من زیر refs/remotes/origin ذخیره شوند.» می‌توانید این بخش را اصلاح کنید و یک refspec دیگر اضافه کنید:

[remote "origin"]
    url = https://github.com/libgit2/libgit2.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

خط آخر به Git می‌گوید: «تمام ارجاع‌هایی که شبیه refs/pull/123/head هستند باید به صورت محلی مانند refs/remotes/origin/pr/123 ذخیره شوند.» حالا اگر آن فایل را ذخیره کنید و دستور git fetch را اجرا کنید:

$ git fetch
# …
 * [new ref]         refs/pull/1/head -> origin/pr/1
 * [new ref]         refs/pull/2/head -> origin/pr/2
 * [new ref]         refs/pull/4/head -> origin/pr/4
# …

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

$ git checkout pr/2
Checking out files: 100% (3769/3769), done.
Branch pr/2 set up to track remote branch pr/2 from origin.
Switched to a new branch 'pr/2'

کسانی که با دقت نگاه می‌کنند متوجه head در انتهای بخش ریموت refspec خواهند شد. همچنین یک ارجاع refs/pull/#/merge در سمت GitHub وجود دارد که نشان‌دهنده کامیتی است که در صورت زدن دکمه “merge” در سایت حاصل می‌شود. این امکان را فراهم می‌کند که قبل از زدن دکمه، ادغام را تست کنید.

درخواست‌های کشش روی درخواست‌های کشش (Pull Requests on Pull Requests)

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

اگر درخواست Pull ای را دیدید که در مسیر درستی حرکت می‌کند و ایده‌ای برای تغییر دارید که به آن وابسته است، یا مطمئن نیستید که ایده‌ی خوبی باشد، یا دسترسی برای ارسال مستقیم به شاخه هدف را ندارید، می‌توانید مستقیماً درخواست Pull را به آن ارسال کنید.

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

نمودار 117. Manually change the Pull Request target fork and branch

در اینجا می‌توانید به‌راحتی مشخص کنید که شاخه جدیدتان را به یک درخواست Pull دیگر یا فورک دیگری از پروژه ادغام کنید.

ذکرها و اعلان‌ها (Mentions and Notifications)

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

در هر کامنت می‌توانید کاراکتر @ را تایپ کنید و گیت‌هاب شروع به تکمیل خودکار نام‌ها و نام‌کاربری افرادی می‌کند که همکار یا مشارکت‌کننده در پروژه هستند.

نمودار 118. Start typing @ to mention someone

همچنین می‌توانید کاربری را که در آن لیست نیست، به صورت دستی ذکر کنید، اما اغلب تکمیل خودکار کار را سریع‌تر می‌کند.

پس از ارسال کامنت با ذکر کاربر، آن کاربر مطلع خواهد شد. این یعنی این روش می‌تواند بسیار مؤثر باشد برای جلب توجه افراد به مکالمات، به جای اینکه آن‌ها را مجبور به رصد کردن کنید. اغلب در درخواست‌های Pull در گیت‌هاب، افراد دیگر اعضای تیم یا شرکت خود را برای بررسی یک Issue یا Pull Request وارد گفتگو می‌کنند.

اگر کسی در یک درخواست Pull یا Issue ذکر شود، به آن مورد “subscribed” می‌شود و هر بار که فعالیتی روی آن انجام شود، اعلان دریافت خواهد کرد. شما هم به مواردی که باز کرده‌اید، یا مخزن را دنبال می‌کنید، یا در آن نظر داده‌اید، به‌طور خودکار عضو می‌شوید. اگر دیگر نمی‌خواهید اعلان دریافت کنید، دکمه‌ی “Unsubscribe” در صفحه وجود دارد که می‌توانید با کلیک روی آن، دریافت به‌روزرسانی‌ها را متوقف کنید.

نمودار 119. Unsubscribe from an Issue or Pull Request

صفحه اعلان‌ها (The Notifications Page)

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

نمودار 120. Notification center options

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

اعلان‌های وب (Web Notifications)

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

نمودار 121. Notification center

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

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

اعلان‌های ایمیل (Email Notifications)

اعلان‌های ایمیل روش دیگری برای دریافت اعلان‌ها از طریق گیت‌هاب هستند. اگر این گزینه را فعال کنید، برای هر اعلان یک ایمیل دریافت خواهید کرد. ما نمونه‌هایی از این اعلان‌ها را در Comments sent as email notifications و Email notification of a new Pull Request دیدیم. ایمیل‌ها همچنین به‌صورت موضوع‌بندی شده (Threaded) ارسال می‌شوند، که اگر از کلاینت ایمیل با پشتیبانی از این قابلیت استفاده کنید، بسیار مناسب است.

علاوه بر این، مقدار قابل توجهی از فراداده (metadata) در هدرهای ایمیل‌هایی که گیت‌هاب ارسال می‌کند وجود دارد، که برای تنظیم فیلترها و قوانین سفارشی بسیار مفید است.

برای مثال، اگر به هدرهای ایمیل واقعی که به تونی در ایمیل نشان داده‌شده در Email notification of a new Pull Request ارسال شده نگاه کنیم، اطلاعات زیر در میان داده‌های ارسالی دیده می‌شود:

To: tonychacon/fade <fade@noreply.github.com>
Message-ID: <tonychacon/fade/pull/1@github.com>
Subject: [fade] Wait longer to see the dimming effect better (#1)
X-GitHub-Recipient: tonychacon
List-ID: tonychacon/fade <fade.tonychacon.github.com>
List-Archive: https://github.com/tonychacon/fade
List-Post: <mailto:reply+i-4XXX@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Recipient-Address: tchacon@example.com

 چند نکته جالب در اینجا وجود دارد.
اگر بخواهید ایمیل‌ها را به این پروژه خاص یا حتی درخواست پول (Pull Request) مشخصی هدایت یا برجسته کنید، اطلاعات موجود در `Message-ID` تمام داده‌ها را به فرمت `<user>/<project>/<type>/<id>` در اختیار شما قرار می‌دهد.
برای مثال، اگر این یک مسئله (Issue) بود، فیلد `<type>` به جای "`pull`" مقدار "`issues`" را داشت.

فیلدهای List-Post و List-Unsubscribe به این معنا هستند که اگر کلاینت ایمیل شما این قابلیت‌ها را پشتیبانی کند، به راحتی می‌توانید به لیست ایمیل ارسال کنید یا از دریافت این موضوع خاص لغو اشتراک کنید. این عملکرد عملاً معادل کلیک روی دکمه “mute” در نسخه وب اعلان یا گزینه “Unsubscribe” در صفحه Issue یا Pull Request است.

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

فایل‌های ویژه (Special Files)

چند فایل ویژه وجود دارند که اگر در مخزن شما باشند، گیت‌هاب آن‌ها را تشخیص می‌دهد.

فایل معرفی (README)

اولین فایل README است که می‌تواند تقریباً هر فرمتی داشته باشد که گیت‌هاب به عنوان متن قابل خواندن بشناسد. مثلاً می‌تواند README، README.md، README.asciidoc و غیره باشد. اگر گیت‌هاب فایل README را در سورس شما ببیند، آن را در صفحه اصلی پروژه نمایش می‌دهد.

بسیاری از تیم‌ها از این فایل استفاده می‌کنند تا تمام اطلاعات مرتبط با پروژه را برای کسی که تازه با مخزن یا پروژه آشنا شده، ارائه دهند. معمولاً این اطلاعات شامل موارد زیر است:

هدف پروژه چیست
چگونه آن را پیکربندی و نصب کنیم
نمونه‌ای از نحوه استفاده یا اجرای آن
مجوزی که پروژه تحت آن عرضه شده است
نحوه مشارکت در پروژه

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

مشارکت (CONTRIBUTING)

فایل ویژه دیگری که گیت‌هاب آن را تشخیص می‌دهد، فایل CONTRIBUTING است. اگر فایل CONTRIBUTING با هر پسوندی داشته باشید، گیت‌هاب زمانی که کسی درخواست پول جدیدی باز می‌کند، Opening a Pull Request when a CONTRIBUTING file exists را نمایش می‌دهد.

نمودار 122. Opening a Pull Request when a CONTRIBUTING file exists

ایده این است که شما می‌توانید قواعد خاصی که می‌خواهید یا نمی‌خواهید در یک Pull Request به پروژه شما ارسال شود را مشخص کنید. به این ترتیب، افراد احتمالاً قبل از باز کردن درخواست پول، دستورالعمل‌ها را مطالعه خواهند کرد.

مدیریت پروژه (Project Administration)

به طور کلی امکانات مدیریتی زیادی برای یک پروژه واحد وجود ندارد، اما چند مورد ممکن است برای شما جالب باشد.

تغییر شاخه پیش‌فرض (Changing the Default Branch)

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

نمودار 123. Change the default branch for a project

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

انتقال یک پروژه (Transferring a Project)

اگر بخواهید پروژه‌ای را به کاربر یا سازمان دیگری در گیت‌هاب منتقل کنید، گزینه‌ای با عنوان “Transfer ownership” در پایین همان تب “Options” در صفحه تنظیمات مخزن شما وجود دارد که این امکان را فراهم می‌کند.

نمودار 124. Transfer a project to another GitHub user or Organization

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

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

prev | next

1. شروع به کار (getting started)

2. مقدمات گیت (git basics chapter)

3. انشعاب‌گیری در گیت (Git Branching)

4. گیت روی سرور (Git on the server)

5. گیت توزیع‌شده (Distributed git)

6. GitHub (گیت هاب)

7. ابزارهای گیت (Git Tools)

8. سفارشی‌سازی Git (Customizing Git)

9. گیت و سیستم‌های دیگر (Git and Other Systems)

10. (Git Internals)

A1. پیوست A: گیت در محیط‌های دیگر (Git in Other Environments)

A2. پیوست B: گنجاندن گیت در برنامه‌های شما (Embedding Git in your Applications)

A3. پیوست C: دستورات گیت (Git Commands)