مقایسه گردش کار git: آنچه باید بدانید

GIT رایج ترین سیستم کنترل نسخه امروز است. گردش کار GIT یک دستور العمل یا توصیه برای نحوه استفاده از GIT برای انجام کار به صورت مداوم و تولیدی است. گردش کار GIT توسعه دهندگان و تیم های DevOps را تشویق می کند تا به طور مؤثر و مداوم از GIT استفاده کنند. GIT انعطاف پذیری زیادی را در نحوه مدیریت کاربران ارائه می دهد. با توجه به تمرکز GIT بر انعطاف پذیری ، هیچ فرآیند استانداردی در مورد نحوه تعامل با GIT وجود ندارد. هنگام کار با تیمی در یک پروژه با مدیریت GIT ، مهم است که اطمینان حاصل کنید که تیم در مورد چگونگی اعمال جریان تغییرات توافق دارد. برای اطمینان از اینکه تیم در همان صفحه قرار دارد ، باید یک گردش کار GIT توافق شده توسعه یا انتخاب شود. چندین گردش کار GIT وجود دارد که ممکن است مناسب تیم شما باشد. در اینجا ، ما در مورد برخی از این گزینه های گردش کار GIT بحث خواهیم کرد.

مجموعه گردش کار ممکن می تواند دانستن از کجا شروع به کار در محل کار کند. این صفحه با بررسی رایج ترین گردش کار GIT برای تیم های نرم افزاری ، نقطه شروع را ارائه می دهد.

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

گردش کار موفق GIT چیست؟

هنگام ارزیابی گردش کار برای تیم خود ، مهمترین چیز این است که فرهنگ تیم خود را در نظر بگیرید. شما می خواهید گردش کار برای افزایش اثربخشی تیم شما و سنگین بودن بهره وری نباشد. برخی از مواردی که باید هنگام ارزیابی گردش کار GIT در نظر بگیرید عبارتند از:

• آیا این مقیاس گردش کار با اندازه تیم است؟
• آیا با این گردش کار ، اشتباهات و خطاها را آسان می کنید؟
• آیا این گردش کار هیچ سربار شناختی غیر ضروری جدید را به تیم تحمیل می کند؟

گردش کار متمرکز

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

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

با این حال ، استفاده از GIT برای برقراری جریان کار توسعه شما چند مزیت نسبت به SVN ارائه می دهد. اول ، این کپی محلی خود را از کل پروژه به هر توسعه دهنده می دهد. این محیط جدا شده به هر توسعه دهنده اجازه می دهد تا مستقل از سایر تغییرات دیگر در یک پروژه کار کند - آنها می توانند تعهداتی را به مخزن محلی خود اضافه کنند و تحولات بالادست را تا زمانی که برای آنها مناسب باشد ، کاملاً فراموش کنند.

دوم ، این امکان را به شما می دهد تا به مدل انشعاب و ادغام قوی Git. بر خلاف SVN ، شاخه های GIT به گونه ای طراحی شده اند که مکانیسم امن برای ادغام کد و به اشتراک گذاری تغییرات بین مخازن باشد. گردش کار متمرکز مشابه سایر گردش کار در استفاده از یک مخزن میزبان از راه دور سرور است که توسعه دهندگان فرم را فشار داده و می کشند. در مقایسه با سایر گردش کار ، گردش کار متمرکز هیچ درخواست کشش مشخص یا الگوهای چنگال ندارد. یک گردش کار متمرکز به طور کلی برای تیم هایی که از SVN به GIT و تیم های کوچکتر مهاجرت می کنند مناسب تر است.

چگونه کار می کند

توسعه دهندگان با کلون کردن مخزن مرکزی شروع می کنند. آنها در نسخه های محلی خود از این پروژه ، پرونده ها را ویرایش می کنند و همانطور که با SVN انجام می دهند ، تغییراتی را انجام می دهند. با این حال ، این تعهدات جدید به صورت محلی ذخیره می شوند - آنها کاملاً از مخزن مرکزی جدا شده اند. این امر به توسعه دهندگان این امکان را می دهد تا تا زمانی که در یک نقطه استراحت راحت قرار بگیرند ، همگام سازی را در بالادست انجام دهند.

برای انتشار تغییرات در پروژه رسمی ، توسعه دهندگان شعبه اصلی محلی خود را به مخزن مرکزی "فشار می دهند". این معادل تعهد SVN است ، به جز این که تمام تعهدات محلی را که قبلاً در شاخه اصلی اصلی نیستند ، اضافه می کند.

مخزن مرکزی را آغاز کنید

اول ، شخصی باید مخزن مرکزی را روی سرور ایجاد کند. اگر این یک پروژه جدید است ، می توانید یک مخزن خالی را آغاز کنید. در غیر این صورت ، شما باید یک مخزن GIT یا SVN موجود را وارد کنید.

مخازن مرکزی همیشه باید مخازن برهنه باشند (آنها نباید یک فهرست کار داشته باشند) ، که می تواند به شرح زیر ایجاد شود:

حتما از یک نام کاربری معتبر SSH برای کاربر ، دامنه یا آدرس IP سرور خود برای میزبان و مکانی که می خواهید repo خود را برای /path/to/repo. git ذخیره کنید ، استفاده کنید. توجه داشته باشید که پسوند . git معمولاً به نام مخزن اضافه می شود تا نشان دهد که این یک مخزن لخت است.

میزبان مخازن مرکزی

مخازن مرکزی اغلب از طریق خدمات میزبانی شخص ثالث مانند Bitbucket Cloud یا Server Bitbucket ایجاد می شوند. روند اولیه سازی یک مخزن لخت که در بالا مورد بحث قرار گرفت ، توسط سرویس میزبانی برای شما انجام می شود. سپس سرویس میزبانی آدرس دسترسی به مخزن مرکزی را از مخزن محلی شما فراهم می کند.

کلون مخزن مرکزی

در مرحله بعد ، هر توسعه دهنده یک نسخه محلی از کل پروژه ایجاد می کند. این کار از طریق دستور git clone انجام می شود:

هنگامی که یک مخزن را کلون می کنید ، Git به طور خودکار میانبرهایی به نام Origin اضافه می کند که به مخزن "والدین" باز می گردد ، با این فرض که می خواهید با آن در پایین جاده ارتباط برقرار کنید.

تغییر ایجاد کنید و مرتکب شوید

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

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

تعهدات جدید را به مخزن مرکزی فشار دهید

هنگامی که مخزن محلی تغییرات جدیدی مرتکب شده است. این تغییر برای به اشتراک گذاشتن با سایر توسعه دهندگان در این پروژه باید تحت فشار قرار گیرد.

این دستور تغییرات جدید متعهد را به مخزن مرکزی سوق می دهد. هنگام فشار دادن تغییرات به مخزن مرکزی ، این امکان وجود دارد که به روزرسانی های دیگر از توسعه دهنده دیگر تحت فشار قرار گرفته است که حاوی کدی است که با به روزرسانی های فشار در نظر گرفته شده است. GIT پیامی را نشان می دهد که این درگیری را نشان می دهد. در این شرایط ، Git Pull ابتدا نیاز به اعدام خواهد داشت. این سناریوی درگیری در بخش زیر گسترش خواهد یافت.

مدیریت درگیری ها

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

قبل از اینکه توسعه دهنده بتواند ویژگی خود را منتشر کند، باید commit های مرکزی به روز شده را واکشی کند و تغییرات خود را در بالای آنها تغییر دهد. این مثل این است که بگوییم: «می‌خواهم تغییراتم را به کارهایی که دیگران قبلاً انجام داده‌اند اضافه کنم». نتیجه یک تاریخچه کاملاً خطی است، درست مانند گردش کار SVN سنتی.

اگر تغییرات محلی مستقیماً با commit های بالادست تضاد داشته باشد، Git فرآیند rebasing را متوقف می کند و به شما فرصتی می دهد تا تداخل ها را به صورت دستی حل کنید. نکته خوب در مورد Git این است که از همان وضعیت git و دستورات git add برای ایجاد commit و حل تضادهای ادغام استفاده می کند. این امر مدیریت ادغام های خود را برای توسعه دهندگان جدید آسان می کند. به‌علاوه، اگر خود را به دردسر بیاندازند، Git خیلی راحت می‌تواند کل rebase را لغو کند و دوباره امتحان کند (یا به دنبال کمک بروید).

مثال

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

جان روی ویژگی خود کار می کند

جان در مخزن محلی خود می‌تواند ویژگی‌هایی را با استفاده از فرآیند استاندارد Git commit توسعه دهد: ویرایش، مرحله، و commit.

به یاد داشته باشید که از آنجایی که این دستورات commit های محلی را ایجاد می کنند، جان می تواند این فرآیند را هر چند بار که بخواهد بدون نگرانی در مورد آنچه در مخزن مرکزی می گذرد تکرار کند.

مریم روی ویژگی خود کار می کند

در همین حال، مری در حال کار بر روی ویژگی خود در مخزن محلی خود با استفاده از همان فرآیند ویرایش/مرحله/تعهد است. او مانند جان، برایش مهم نیست که در مخزن مرکزی چه می‌گذرد، و واقعاً برایش مهم نیست که جان در مخزن محلی‌اش چه می‌کند، زیرا همه مخازن محلی خصوصی هستند.

جان ویژگی خود را منتشر می کند

هنگامی که جان ویژگی خود را تمام کرد، باید تعهدات محلی خود را در مخزن مرکزی منتشر کند تا سایر اعضای تیم بتوانند به آن دسترسی داشته باشند. او می تواند این کار را با دستور git push انجام دهد، مانند:

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

مری سعی می کند ویژگی خود را منتشر کند

بیایید ببینیم چه اتفاقی می افتد اگر مری سعی کند ویژگی خود را پس از اینکه جان با موفقیت تغییرات خود را در مخزن مرکزی منتشر کرد، اعمال کند. او می تواند دقیقاً از همان فرمان فشار استفاده کند:

اما ، از آنجا که تاریخ محلی وی از مخزن مرکزی فاصله گرفته است ، GIT با یک پیام خطای نسبتاً کلامی درخواست را امتناع می کند:

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

ماری Rebases در بالای تعهد (های) جان

مری می تواند از Git Pull برای ترکیب تغییرات بالادست در مخزن خود استفاده کند. این دستور مانند به روزرسانی SVN است - کل تاریخ ارتکاب بالادست را به مخزن محلی مریم می کشاند و سعی می کند آن را با تعهدات محلی خود ادغام کند:

گزین ه-Rebase به Git می گوید که تمام تعهدات مریم را پس از همگام سازی آن با تغییرات از مخزن مرکزی ، به نوک شاخه اصلی منتقل کند ، همانطور که در زیر آمده است:

اگر این گزینه را فراموش کرده باشید ، هنوز هم کار می کند ، اما هر بار که کسی نیاز به هماهنگی با مخزن مرکزی داشت ، با یک "تعهد ادغام" اضافی باد می کنید. برای این گردش کار ، همیشه بهتر است به جای ایجاد یک تعهد ادغام ، مجدداً مجدداً مجدداً مجدداً مجدداً مجدداً مجدداً مجدداً مجدداً مورد استفاده قرار گرفت.

مریم درگیری ادغام را برطرف می کند

Rebasing با انتقال هر تعهد محلی به شعبه اصلی به روز شده یک بار کار می کند. این بدان معنی است که شما به جای حل همه آنها در یک تعهد گسترده ادغام ، درگیری ها را بر اساس تعهد به دست می آورید. این امر تعهدات شما را تا حد امکان متمرکز نگه می دارد و باعث می شود تاریخچه پروژه تمیز باشد. به نوبه خود ، این امر می تواند تشخیص دهد که در کجا اشکالات معرفی شده اند و در صورت لزوم ، تغییرات را با حداقل تأثیر بر روی پروژه بازگردانند.

اگر مری و جان روی ویژگی های نامربوط کار می کنند ، بعید است که روند کار مجدد باعث ایجاد اختلافات شود. اما اگر این کار را انجام دهد ، GIT در تعهد فعلی مکث می کند و پیام زیر را به همراه برخی دستورالعمل های مربوطه ، مکث می کند:

نکته جالب در مورد GIT این است که هر کسی می تواند درگیری های ادغام خود را برطرف کند. در مثال ما ، مریم به سادگی وضعیت git را اجرا می کند تا ببیند مشکل کجاست. پرونده های متناقض در بخش مسیرهای Unberged ظاهر می شوند:

سپس ، او پرونده (های) را به دلخواه خود ویرایش می کند. هنگامی که او از نتیجه خوشحال شد ، می تواند پرونده (های) را به روش معمول صحنه بگذارد و اجازه دهد Git Rebase بقیه را انجام دهد:

و این همه چیز در آن است. GIT به سمت تعهد بعدی حرکت می کند و روند کار دیگری را که ایجاد درگیری ایجاد می کند ، تکرار می کند.

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

مری با موفقیت ویژگی خود را منتشر می کند

بعد از اینکه او همگام سازی با مخزن مرکزی انجام شد ، مری قادر خواهد بود تغییرات خود را با موفقیت منتشر کند:

از کجا برویم

همانطور که مشاهده می کنید ، می توان با استفاده از تعداد معدودی از دستورات GIT ، یک محیط توسعه براندازی سنتی را تکرار کرد. این برای انتقال تیم های SVN بسیار عالی است ، اما از ماهیت توزیع شده Git استفاده نمی کند.

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

سایر گردش کار مشترک

گردش کار متمرکز در واقع یک ساختمان ساختمانی برای سایر گردش کار GIT است. بیشتر گردش کار GIT به نوعی repo متمرکز وجود دارد که توسعه دهندگان انفرادی از آن فشار می آورند و از آن می کشند. در زیر ما به طور خلاصه در مورد برخی از گردش کار محبوب Git بحث خواهیم کرد. این گردش کار گسترده الگوهای تخصصی تری در رابطه با مدیریت شعب برای توسعه ویژگی ها ، رفع داغ و انتشار نهایی ارائه می دهد.

انشعاب ویژگی

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

گردش کار gitflow

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

گردش کار جعل

گردش کار Forking اساساً متفاوت از سایر گردش کار است که در این آموزش مورد بحث قرار گرفته است. به جای استفاده از یک مخزن سمت سرور واحد برای عمل به عنوان پایگاه "مرکزی" ، به هر توسعه دهنده یک مخزن سمت سرور می دهد. این بدان معناست که هر یک از مشارکت کنندگان یک مخزن GIT ندارند بلکه دو مخزن GIT دارند: یک محلی خصوصی و یک سرور عمومی.

دستورالعمل

هیچ اندازه ای متناسب با تمام گردش کار git نیست. همانطور که قبلاً گفته شد ، توسعه یک گردش کار GIT که یک افزایش بهره وری برای تیم شما است ، مهم است. علاوه بر فرهنگ تیمی ، یک گردش کار نیز باید فرهنگ تجارت را تکمیل کند. ویژگی های GIT مانند شعب و برچسب ها باید برنامه انتشار کسب و کار شما را تکمیل کنند. اگر تیم شما از نرم افزار مدیریت پروژه ردیابی کار استفاده می کند ، ممکن است بخواهید از شاخه هایی استفاده کنید که با وظایف در حال انجام مطابقت داشته باشد. علاوه بر این ، برخی از دستورالعمل ها که باید هنگام تصمیم گیری در مورد گردش کار در نظر بگیرند عبارتند از:

شاخه های کوتاه مدت

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

بازگشت ها را به حداقل برسانید و ساده کنید

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

با یک برنامه انتشار مطابقت داشته باشید

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

خلاصه

در این سند ما در مورد گردش کار GIT بحث کردیم. ما نگاهی عمیق به یک گردش کار متمرکز با نمونه های عملی انداختیم. با گسترش در گردش کار متمرکز ، ما در مورد گردش کار تخصصی اضافی بحث کردیم. برخی از غذاهای مهم از این سند عبارتند از:

• هیچ گردش کار یک اندازه ای وجود ندارد
• یک گردش کار باید ساده باشد و بهره وری تیم شما را تقویت کند
• نیازهای تجاری شما باید به شکل گیری گردش کار GIT کمک کند

برای مطالعه در مورد گردش کار بعدی GIT ، تجزیه جامع ما از گردش کار شعبه ویژگی را بررسی کنید.