حالا که در مشارکت در یک پروژه راحت شدهایم، بیایید به سمت دیگر قضیه نگاه کنیم: ایجاد، نگهداری و مدیریت پروژهی خودتان.
بیایید یک مخزن جدید بسازیم تا کد پروژهمان را به اشتراک بگذاریم. با کلیک روی دکمهی «New repository» در سمت راست داشبورد شروع کنید، یا از دکمهی «+» در نوار ابزار بالای صفحه کنار نام کاربریتان استفاده کنید، همانطور که در The “New repository” dropdown دیده میشود.
این شما را به فرم “new repository” هدایت میکند:
تنها کاری که واقعاً باید انجام دهید این است که نام پروژه را وارد کنید؛ بقیه فیلدها کاملاً اختیاری هستند.
فعلاً فقط روی دکمهی «Create Repository» کلیک کنید، و همینطور — یک مخزن جدید روی گیتهاب با نام <user>/<project_name> دارید.
از آنجا که هنوز هیچ کدی در این مخزن نیست، گیتهاب به شما دستورالعملهایی برای ساخت یک مخزن گیت کاملاً جدید یا اتصال یک پروژهی گیت موجود نشان میدهد. ما اینجا وارد جزئیات نمیشویم؛ اگر نیاز به بازخوانی دارید، بخش ch02-git-basics-chapter.asc را مطالعه کنید.
حالا که پروژهی شما روی گیتهاب میزبانی شده است، میتوانید آدرس URL آن را به هر کسی که میخواهید پروژه را با او به اشتراک بگذارید، بدهید.
هر پروژهای روی گیتهاب از طریق HTTPS به صورت https://github.com/<user>/<project_name>; و از طریق SSH به صورت git@github.com:<user>/<project_name> قابل دسترسی است.
گیت میتواند از هر دو URL دریافت و ارسال کند، اما دسترسی به آنها بر اساس اعتبارنامههای کاربری که به آنها متصل میشوند کنترل میشود.
|
Note
|
اغلب ترجیح داده میشود که URL مبتنی بر HTTPS را برای پروژههای عمومی به اشتراک بگذارید، چرا که کاربر برای کلون کردن نیازی به حساب کاربری گیتهاب ندارد. اگر URL SSH را بدهید، کاربران باید حساب کاربری و کلید SSH آپلود شده داشته باشند تا بتوانند به پروژه دسترسی پیدا کنند. همچنین، URL HTTPS همان آدرسی است که آنها میتوانند در مرورگر خود برای مشاهده پروژه وارد کنند. |
اگر با افرادی کار میکنید که میخواهید دسترسی تعهد (commit) به آنها بدهید، باید آنها را به عنوان «collaborators» اضافه کنید. اگر بن، جف و لوئیس همه در گیتهاب حساب کاربری بسازند و شما بخواهید دسترسی push به مخزن خود بدهید، میتوانید آنها را به پروژه اضافه کنید. این کار به آنها دسترسی «push» میدهد، بدین معنا که هم به پروژه و مخزن گیت خواندن و نوشتن دارند.
روی لینک “Setting” در پایین نوار کناری سمت راست کلیک کنید.
سپس از منوی سمت چپ «Collaborators» را انتخاب کنید. بعد، فقط نام کاربری را در کادر تایپ کنید و روی «Add collaborator» کلیک کنید. میتوانید این کار را به هر تعداد که دوست دارید تکرار کنید تا به همهی افراد دلخواه دسترسی بدهید. اگر نیاز به لغو دسترسی داشتید، فقط روی «X» در سمت راست ردیف آنها کلیک کنید.
حالا که یک پروژه با مقداری کد دارید و شاید چند همکار که دسترسی push دارند، بیایید ببینیم وقتی خودتان یک Pull Request دریافت میکنید، چه کار باید بکنید.
درخواستهای Pull میتوانند یا از یک شاخه در یک فورک مخزن شما بیایند یا از شاخهای دیگر در همان مخزن. تنها تفاوت این است که درخواستهای Pull در فورکها اغلب از افرادی هستند که شما نمیتوانید به شاخه آنها push کنید و آنها هم نمیتوانند به شاخه شما push کنند، در حالی که در درخواستهای Pull داخلی معمولاً هر دو طرف به شاخه دسترسی دارند.
برای این مثالها فرض کنیم شما “tonychacon” هستید و یک پروژه کد آردوینو به نام «fade» ساختهاید.
کسی میآید و تغییری در کد شما ایجاد میکند و یک Pull Request برای شما ارسال میکند. شما باید ایمیلی دریافت کنید که در مورد Pull Request جدید اطلاع دهد و این ایمیل باید چیزی شبیه به Email notification of a new Pull Request باشد.
چند نکته درباره این ایمیل وجود دارد که باید بدانید. این ایمیل یک خلاصه کوچک از تغییرات (diffstat) به شما میدهد — فهرستی از فایلهایی که در درخواست Pull تغییر کردهاند و میزان تغییرات آنها. همچنین یک لینک به درخواست Pull در گیتهاب به شما ارائه میکند. چند URL نیز دارد که میتوانید از طریق خط فرمان از آنها استفاده کنید.
اگر به خطی که نوشته git pull <url> patch-1 دقت کنید، این یک روش ساده برای ادغام یک شاخه از راه دور بدون نیاز به اضافه کردن remote است.
ما این موضوع را سریعاً در ch05-distributed-git.asc مرور کردیم.
اگر بخواهید، میتوانید یک شاخه موضوعی (topic branch) ایجاد و به آن سوئیچ کنید و سپس این دستور را اجرا کنید تا تغییرات درخواست Pull را ادغام کنید.
URLهای جالب دیگر، URLهای .diff و .patch هستند که همانطور که حدس میزنید، نسخههای unified diff و patch از درخواست Pull را ارائه میدهند.
از نظر فنی، میتوانید کار درخواست Pull را با چیزی شبیه به این ادغام کنید:
$ curl https://github.com/tonychacon/fade/pull/1.patch | git amهمانطور که در ch06-github.asc توضیح دادیم، اکنون میتوانید با شخصی که درخواست Pull را باز کرده است گفتگو کنید. میتوانید روی خطوط خاصی از کد نظر بگذارید، روی کامیتهای کامل یا کل درخواست Pull نظر بدهید و در همه جا از Markdown با سبک GitHub استفاده کنید.
هر بار که شخص دیگری روی درخواست Pull نظر میدهد، شما ایمیل اطلاعرسانی دریافت میکنید تا بدانید فعالیتی در حال انجام است. هر ایمیل شامل لینکی به درخواست Pull است که فعالیت در آنجا اتفاق میافتد و همچنین میتوانید مستقیماً به ایمیل پاسخ دهید و در همان رشته (thread) درخواست Pull نظر بگذارید.
وقتی کد به جایی رسید که راضی بودید و میخواهید آن را ادغام کنید، میتوانید کد را دانلود کرده و محلی ادغام کنید، یا با دستور git pull <url> <branch> که قبلاً دیدیم، یا با افزودن فورک به عنوان remote و گرفتن و ادغام آن.
اگر ادغام ساده باشد، میتوانید به سادگی روی دکمه «Merge» در سایت گیتهاب کلیک کنید. این کار یک ادغام «non-fast-forward» انجام میدهد، یعنی یک کامیت ادغام ایجاد میکند حتی اگر ادغام fast-forward ممکن باشد. این یعنی هر بار که دکمه merge را میزنید، یک کامیت ادغام ساخته میشود. همانطور که در Merge button and instructions for merging a Pull Request manually میبینید، گیتهاب همه این اطلاعات را اگر روی لینک راهنما کلیک کنید، به شما نشان میدهد.
اگر تصمیم گرفتید که نمیخواهید ادغام کنید، میتوانید فقط درخواست Pull را ببندید و شخصی که آن را باز کرده است، مطلع خواهد شد.
گیتهاب در واقع شاخههای درخواست Pull را به عنوان شاخههای شبه (pseudo-branches) روی سرور تبلیغ میکند. به طور پیشفرض وقتی کلون میکنید آنها را دریافت نمیکنید، اما به شکلی پنهان وجود دارند و میتوانید به راحتی به آنها دسترسی پیدا کنید.
برای نشان دادن این موضوع، از یک دستور سطح پایین (که اغلب به آن دستور «لولهکشی» یا plumbing گفته میشود و در ch10-git-internals.asc بیشتر درباره آن میخوانیم) به نام 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 را به شاخهی اصلی یا master ارسال کنید، بلکه در واقع میتوانید درخواست Pull را به هر شاخهای در شبکه هدف قرار دهید.
در واقع، حتی میتوانید یک درخواست Pull را هدف بگیرید.
اگر درخواست Pull ای را دیدید که در مسیر درستی حرکت میکند و ایدهای برای تغییر دارید که به آن وابسته است، یا مطمئن نیستید که ایدهی خوبی باشد، یا دسترسی برای ارسال مستقیم به شاخه هدف را ندارید، میتوانید مستقیماً درخواست Pull را به آن ارسال کنید.
وقتی میخواهید درخواست Pull باز کنید، در بالای صفحه جعبهای وجود دارد که مشخص میکند شما درخواست ادغام از کدام شاخه به کدام شاخه را دارید. اگر روی دکمهی “Edit” در سمت راست آن جعبه کلیک کنید، میتوانید نه تنها شاخهها بلکه فورک مورد نظر را نیز تغییر دهید.
در اینجا میتوانید بهراحتی مشخص کنید که شاخه جدیدتان را به یک درخواست Pull دیگر یا فورک دیگری از پروژه ادغام کنید.
گیتهاب همچنین سیستم اعلانهای بسیار خوبی دارد که وقتی سوالی دارید یا به بازخورد از افراد یا تیمهای خاص نیاز دارید، بسیار مفید است.
در هر کامنت میتوانید کاراکتر @ را تایپ کنید و گیتهاب شروع به تکمیل خودکار نامها و نامکاربری افرادی میکند که همکار یا مشارکتکننده در پروژه هستند.
همچنین میتوانید کاربری را که در آن لیست نیست، به صورت دستی ذکر کنید، اما اغلب تکمیل خودکار کار را سریعتر میکند.
پس از ارسال کامنت با ذکر کاربر، آن کاربر مطلع خواهد شد. این یعنی این روش میتواند بسیار مؤثر باشد برای جلب توجه افراد به مکالمات، به جای اینکه آنها را مجبور به رصد کردن کنید. اغلب در درخواستهای Pull در گیتهاب، افراد دیگر اعضای تیم یا شرکت خود را برای بررسی یک Issue یا Pull Request وارد گفتگو میکنند.
اگر کسی در یک درخواست Pull یا Issue ذکر شود، به آن مورد “subscribed” میشود و هر بار که فعالیتی روی آن انجام شود، اعلان دریافت خواهد کرد. شما هم به مواردی که باز کردهاید، یا مخزن را دنبال میکنید، یا در آن نظر دادهاید، بهطور خودکار عضو میشوید. اگر دیگر نمیخواهید اعلان دریافت کنید، دکمهی “Unsubscribe” در صفحه وجود دارد که میتوانید با کلیک روی آن، دریافت بهروزرسانیها را متوقف کنید.
وقتی دربارهی “اعلانها” در گیتهاب صحبت میکنیم، منظورمان روشی خاص است که گیتهاب برای اطلاعرسانی به شما هنگام رخ دادن رویدادها دارد و شما میتوانید آنها را به چند روش مختلف تنظیم کنید. اگر به تب “Notification center” در صفحه تنظیمات بروید، میتوانید برخی از گزینههای موجود را ببینید.
دو گزینه اصلی دریافت اعلانها از طریق “ایمیل” و “وب” هستند و میتوانید برای زمانی که در فعالیتها شرکت میکنید و فعالیت روی مخازنی که دنبال میکنید، هر دو، هیچکدام یا یکیشان را انتخاب کنید.
اعلانهای وب فقط در گیتهاب وجود دارند و فقط میتوانید آنها را در گیتهاب مشاهده کنید. اگر این گزینه را در تنظیمات خود فعال کرده باشید و اعلان جدیدی برای شما ایجاد شود، یک نقطهی کوچک آبی روی آیکون اعلانها در بالای صفحه ظاهر میشود، همانطور که در Notification center دیده میشود.
با کلیک روی آن، فهرستی از تمام مواردی که اعلان دریافت کردهاید، به تفکیک پروژه نمایش داده میشود. میتوانید با کلیک روی نام پروژه در نوار کناری سمت چپ، اعلانهای یک پروژه خاص را فیلتر کنید. همچنین میتوانید با کلیک روی آیکون تیک کنار هر اعلان، آن را تأیید کنید، یا تمام اعلانهای یک پروژه را با کلیک روی تیک بالای گروه تأیید نمایید. دکمهی سایلنت (بیصدا) نیز کنار هر تیک وجود دارد که اگر کلیک کنید، دیگر اعلانهای آن مورد خاص را دریافت نخواهید کرد.
تمام این ابزارها برای مدیریت تعداد زیادی اعلان بسیار کاربردی هستند. بسیاری از کاربران حرفهای گیتهاب، اعلانهای ایمیل را کاملاً غیرفعال میکنند و تمام اعلانهای خود را از طریق این صفحه مدیریت میکنند.
اعلانهای ایمیل روش دیگری برای دریافت اعلانها از طریق گیتهاب هستند. اگر این گزینه را فعال کنید، برای هر اعلان یک ایمیل دریافت خواهید کرد. ما نمونههایی از این اعلانها را در [_email_notification] و 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 است.
همچنین شایان ذکر است که اگر اعلانهای ایمیل و وب هر دو فعال باشند و شما نسخه ایمیلی اعلان را بخوانید، نسخه وب نیز به عنوان خوانده شده علامتگذاری میشود، البته به شرطی که در کلاینت ایمیل خود اجازه نمایش تصاویر را داده باشید.
چند فایل ویژه وجود دارند که اگر در مخزن شما باشند، گیتهاب آنها را تشخیص میدهد.
اولین فایل README است که میتواند تقریباً هر فرمتی داشته باشد که گیتهاب به عنوان متن قابل خواندن بشناسد.
مثلاً میتواند README، README.md، README.asciidoc و غیره باشد.
اگر گیتهاب فایل README را در سورس شما ببیند، آن را در صفحه اصلی پروژه نمایش میدهد.
بسیاری از تیمها از این فایل استفاده میکنند تا تمام اطلاعات مرتبط با پروژه را برای کسی که تازه با مخزن یا پروژه آشنا شده، ارائه دهند. معمولاً این اطلاعات شامل موارد زیر است:
-
هدف پروژه چیست
-
چگونه آن را پیکربندی و نصب کنیم
-
نمونهای از نحوه استفاده یا اجرای آن
-
مجوزی که پروژه تحت آن عرضه شده است
-
نحوه مشارکت در پروژه
از آنجا که گیتهاب این فایل را نمایش میدهد، میتوانید تصاویر یا لینکهایی در آن بگنجانید تا فهم آن آسانتر شود.
فایل ویژه دیگری که گیتهاب آن را تشخیص میدهد، فایل CONTRIBUTING است.
اگر فایل CONTRIBUTING با هر پسوندی داشته باشید، گیتهاب زمانی که کسی درخواست پول جدیدی باز میکند، Opening a Pull Request when a CONTRIBUTING file exists را نمایش میدهد.
ایده این است که شما میتوانید قواعد خاصی که میخواهید یا نمیخواهید در یک Pull Request به پروژه شما ارسال شود را مشخص کنید. به این ترتیب، افراد احتمالاً قبل از باز کردن درخواست پول، دستورالعملها را مطالعه خواهند کرد.
به طور کلی امکانات مدیریتی زیادی برای یک پروژه واحد وجود ندارد، اما چند مورد ممکن است برای شما جالب باشد.
اگر شاخهای غیر از “master” را به عنوان شاخه پیشفرض که میخواهید افراد روی آن درخواست پول باز کنند یا به صورت پیشفرض ببینند، استفاده میکنید، میتوانید این تنظیم را در صفحه تنظیمات مخزن خود زیر تب “Options” تغییر دهید.
به سادگی شاخه پیشفرض را در منوی کشویی تغییر دهید و از آن پس تمام عملیات اصلی با آن شاخه به عنوان پیشفرض انجام خواهد شد، از جمله شاخهای که هنگام کلون کردن مخزن به صورت پیشفرض بررسی میشود.
اگر بخواهید پروژهای را به کاربر یا سازمان دیگری در گیتهاب منتقل کنید، گزینهای با عنوان “Transfer ownership” در پایین همان تب “Options” در صفحه تنظیمات مخزن شما وجود دارد که این امکان را فراهم میکند.
این قابلیت زمانی مفید است که شما پروژه را رها میکنید و کسی میخواهد آن را به عهده بگیرد، یا پروژه شما بزرگتر شده و میخواهید آن را به یک سازمان منتقل کنید.
این کار نه تنها مخزن را همراه با تمام دنبالکنندگان و ستارههای آن به مکان جدید منتقل میکند، بلکه یک ریدایرکت از URL قبلی شما به مکان جدید نیز ایجاد میکند. همچنین این ریدایرکت شامل کلونها و دریافتها از طریق گیت میشود، نه فقط درخواستهای وب.