درخواست pull یکی از قابلیت هایی است که مشارکت را برای توسعه دهنده ها آسان تر کرده است. سایت هایی مانند Github راه کار مناسب و کاربر پسندی برای بحث درمورد تغییرات پیشنهادی قبل از ثبت در پروژه اصلی ایجاد می کنند.
در ساده ترین شکل، درخواست pull مکانیسمی برای توسعه دهنده است که سایر اعضای تیم را از پیاده سازی یک قابلیت آگاه کند. پس از اینکه شاخه feature آماده شد توسعه دهنده یک درخواست pull ثبت می کند. این کار باعث می شود تمام افرادی که درگیر پروژه هستند متوجه شوند که باید کد های جدید را بررسی کنند و آن را در شاخه main ادغام کنند.
البته درخواست pull چیزی بیشتر از یک اعلان است. می توان آن را یک تالار گفت و گوی اختصاصی برای بحث درمورد تغییرات پیشنهاد شده دانست. اگر تغییرات پیشنهادی مشکلی دارند، هم تیمی ها می توانند بازخوردشان را در آن جا ارسال کنند. همچنین آن ها می توانند تغییرات خودشان را به تغییرات پیشنهادی اضافه کنند. تمام این فعالیت ها درون درخواست pull ثبت می شود.
در مقایسه با سایر شیوه های مشارکت، این شکل از به اشتراک گذاری commit ها روند کاری ساده تری دارد. Git می تواند با استفاده از یک اسکریپت ساده اعلان ها را ایمیل کند اما هنگامی که توسعه دهنده ها درمورد تغییرات بحث می کنند استفاده از ایمیل دشوار است. درخواست های pull، مشکلات این چنینی را با یک صفحه وب برطرف می کنند.
ساختار یک درخواست pull
وقتی که یک درخواست pull ثبت می کنید در اصل از توسعه دهنده دیگری (مانند مدیر یا نگهدارنده پروژه) می خواهید که شاخه ای را از مخزن شما در مخزن خودشان دریافت کنند. این بدان معنا است که شما برای ایجاد درخواست Pull باید 4 داده را فراهم کنید. مخزن مرجع، شاخه مرجع، مخزن مقصد و شاخه مقصد.
برخی از این داده ها در Github مقدار پیش فرض مناسبی دارند. البته بر اساس روند مشارکت، تیم شما ممکن است مقدار های خودش را تعیین کند. تصویر بالا یک درخواست pull را نشان می دهد که می خواهد شاخه feature را در شاخه main رسمی ادغام کند. راه های زیاد دیگری هم برای استفاده از درخواست pull وجود دارد.
چگونه کار می کند
درخواست های pull می توانند با گردش کار feature branch، گردش کار Gitflow یا گردش کار forking استفاده شود. اما به دلیل این که یک درخواست Pull دو شاخه متفاوت یا دو مخزن متفاوت نیاز دارد، نمی تواند با گردش کار متمرکز استفاده شود. استفاده از درخواست pull در هرکدام از این گردش کارها کمی متفاوت است اما فرآیند کلی شامل موارد زیر می شود:
- یک توسعه دهنده قابلیتی را در شاخه ای جداگانه در مخزن خود ایجاد می کند.
- توسعه دهنده آن شاخه را در مخزن عمومی بارگذاری (push) می کند.
- توسعه دهنده یک درخواست pull ایجاد می کند.
- سایر اعضای تیم آن را بررسی می کنند، درمورد آن صحبت کرده و تغییرش می دهند.
- نگهدارنده پروژه قابلیت جدید را در مخزن رسمی ادغام می کند و درخواست pull را می بندد.
در ادامه این بخش به ترکیب درخواست pull با گردش کار های مختلف می پردازیم.
گردش کار feature branch و درخواست های pull
گردش کار feature branch از یک مخزن مشترک برای مدیریت همکاری استفاده می کند و توسعه دهنده ها شاخه های مستقل برای هر قابلیت ایجاد می کنند. اما به جای ادغام سریع این شاخه ها در main، توسعه دهنده ها یک درخواست pull ایجاد می کنند تا قبل از ادغام قابلیت درمورد آن بحث و بررسی انجام شود.
در گردش کار feature branch تنها یک مخزن وجود دارد. بنابراین مخزن مقصد در درخواست pull با مخزن مرجع همیشه یکی است. به طور معمول توسعه دهنده شاخه خود را به عنوان شاخه مرجع و شاخه main را به عنوان شاخه مقصد انتخاب می کند.
نگهدارنده پروژه پس از دریافت درخواست pull باید تصمیم بگیرد که چه کاری می خواهد انجام بدهد. اگر قابلیت آماده شده است می توان به راحتی آن را با main ادغام کرد و درخواست pull را بست. اما اگر مشکلی با تغییرات پیشنهاد شده وجود دارد، نگهدارنده پروژه می تواند بازخورد خود را ثبت کند.
همچنین این امکان وجود دارد تا یک درخواست pull برای قابلیتی که هنوز تمام نشده است ثبت کنیم. به عنوان نمونه اگر توسعه دهنده در پیاده سازی یک نیازمندی خاص مشکل دارد می تواند درخواست pull خود را که حاوی کار در حال انجام است ثبت کند. توسعه دهنده های دیگر می توانند پیشنهاد هایی داخل آن درخواست pull مطرح کنند یا حتی با اضافه کردن چند commit، آن مشکل را برطرف کنند.
گردش کار Gitflow و درخواست های pull
گردش کار Gitflow مانند feature branch است اما یک شیوه خاص برای ایجاد شاخه در پروژه را تعریف می کند. اضافه کردن درخواست های pull به گردش کار Gitflow به توسعه دهنده ها این امکان را می دهد که درمورد شاخه release یا شاخه bugfix هنگام کار روی آن صحبت کنند.
فرآیند درخواست های pull در گردش کار Gitflow دقیقا مانند بخش قبلی است. یک توسعه دهنده زمانی که یک feature، hotfix یا release، نیاز به بررسی دارد درخواست pull ثبت می کند و سایر اعضای تیم توسط Github مطلع می شوند.
قابلیت ها به طور معمول در شاخه develop ادغام می شوند در حالی که شاخه های release و hotfix هم در develop و هم در main ادغام می شوند. از درخواست های pull می توان استفاده کرد تا همه ادغام ها را مدیریت کرد.
گردش کار Forking و درخواست های pull
در گردش کار Forking، یک توسعه دهنده قابلیتی که پیاده سازی کرده است را به جای یک مخزن مشترک در یک مخزن عمومی بارگذاری می کند. پس از آن، یک درخواست pull ایجاد می کند تا نگهدارنده پروژه را از آماده شدن قابلیت برای بررسی مطلع کند.
بخش اطلاع رسانی درخواست های pull در این گردش کار بیشتر به کار می آید زیرا نگهدارنده پروژه هیچ راهی ندارد تا از بارگذاری commit ها توسط توسعه دهنده دیگر مطلع شود.
از آن جایی که هر توسعه دهنده مخزن عمومی خودش را دارد، در درخواست های pull مخزن مرجع با مخزن مقصد فرق می کند. مخزن مرجع همان مخزن عمومی توسعه دهنده است و شامل تغییرات پیشنهادی می شود. اگر توسعه دهنده قصد داشته باشد تغییرات را در مخزن رسمی ادغام کند مخزن مقصد همان مخزن رسمی می شود و شاخه مقصد شاخه main خواهد بود.
درخواست های pull می توانند برای مشارکت توسعه دهنده ها خارج از پروژه رسمی هم استفاده شوند. برای نمونه اگر توسعه دهنده ای با یکی از اعضای تیم روی یک قابلیت کار میکند، آن ها می توانند یک درخواست pull ایجاد کنند که مخزن مقصد آن مخزن هم تیمی شان است و نه مخزن رسمی. در این صورت آن ها از یک شاخه به عنوان شاخه مرجع و مقصد استفاده می کنند.
دو توسعه دهنده می توانند درون درخواست pull بحث کنند و توسعه قابلیت را آن جا ادامه دهند. زمانی که کارشان تمام می شود یکی از آن ها درخواست pull ای ایجاد می کند که قابلیت در مخزن رسمی ادغام شود. این گونه از انعطاف پذیری، درخواست های pull را به ابزار بسیار قدرتمندی برای مشارکت در گردش کار Forking تبدیل می کند.
اکنون شما تمام اطلاعاتی که برای استفاده از درخواست های pull در گردش کاری فعلیتان نیاز دارید را کسب کرده اید. به خاطر داشته باشید که درخواست های pull جایگزین هیچ یک از روش های انجام مشارکت در Git نیست. بلکه یک قابلیت دیگر است که مشارکت را برای اعضای تیم آسان تر می کند.
منبع:
https://www.atlassian.com/git/tutorials/making-a-pull-request
