چگونه از git بصورت موثر در مدیریت پروژه استفاده کنیم

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

• کدها دیروز مشکلی نداشتن ولی امروز مشکل دارن!
• بعضی از کدها پاک شدن!
• یک bug عجیب بصورت ناگهانی به وجود اومده و هیچکس در مورد اون چیزی نمیدونه!

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

در کنار دستوراتی مانند git add و git commit و git push که دستورات پایه هستند و دانستن اونا برای هر کسی لازمه، تکنیکهای دیگه‌ای هم وجود داره که باید در مورد اون اطلاعاتی داشته باشید تا بتونین بهتر پروژه‌هاتون رو مخصوصا بصورت گروهی مدیریت کنید.

گردش کار یا git workflow

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

بررسی سناریو

فرض کنید که شما سرپرست یک تیم میشید و قصد دارید یک پروژه بزرگ مانند Facebook رو به وجود بیارید. تیم شما 3 توسعه‌دهنده با مشخصات زیر داره:

• Alice : یک سال سابقه کار داره و برنامه نویسی بلده
• Bob : یک سال سابقه کار داره و برنامه نویسی بلده
• John : سه سال سابقه کار داره و برنامه نویسی رو خیلی خوب بلده
• خود شما : شما هم سرپرست نرم‌افزاری این پروژه هستید

فرآیند توسعه در git

branch یا شاخه master

1. شاخه master همیشه باید یک نسخه کپی از کدهای موجود در production باشه.
2. هیچکس - حتی شما که سرپرست هستید - نباید بصورت مستقیم در این شاخه تغییری به وجود بیاره بخاطر اینکه این کدها یک نسخه از production هستند و نبایند تغییر کنند.
3. کدهای جدید و تغییرات مورد نظر باید در شاخه‌های دیگه نوشته بشن

شاخه Release

1. زمانی که یک پروژه شروع میشه اولین کاری که باید انجام بدین اینه که یک شاخه بنام Release به وجود بیارید. شاخه Release از روی شاخه master ساخته میشه.
2. همه کدهای مربوط به این پروژه در شاخه release قرار میگیره. شاخه release یک شاخه نرمال هست که با پیشوند release/ مشخص میشه.
3. چون هدف این پروژه ساختن چیزی شبیه به facebook هست، اسم این شاخه رو release/fb قرار میدیم.
4. امکان داره که چندین پروژه بصورت همزمان بر روی یک پایه کد در حال انجام باشه. پس برای هر پروژه باید یک شاخه release جداگانه ساخته بشه. فرض کنید که همزمان در حال ساخت یک پیام‌رسان هم باشیم. پس میتونیم برای این پروژه هم شاخه release/messenger رو به وجود بیاریم.
5. به این دلیل برای هر کدام یک شاخه به وجود میاریم تا conflict در پروژه‌ها به وجود نیاد.

شاخه feature یا ویژگی

1. برای هر ویژگی جدیدی که قصد دارید به پروژه اضافه کنید، باید یک شاخه feature جداگانه برای اون بسازید. اینکار باعث میشه که این ویژگی جدید از ویژگی‌های در حال توسعه دیگه جدا و مستقل باشه.
2. شاخه‌های feature هم نرمال هستند ولی پیشوند feature/ رو دارند.
3. حالا شما به عنوان سرپرست تیم از Alice میخواید که یک صفحه login برای Facebook به وجود بیاره. پس Alice یک شاخه جدید از نوع feature به وجود میاره و اسم اون رو feature/login قرار میده. Alice همه کدهای مربوط به صفحه login رو در این شاخه قرار میده.
4. شاخه‌های feature در بیشتر موارد از روی شاخه release ساخته میشن.
5. در همین لحظه Bob هم وظیفه داره که صفحه درخواست دوستی رو به وجود بیاره. پس Bob هم باید یک شاخه جدید بنام feature/friendrequest رو به وجود بیاره و کدهای خودش رو در اونجا قرار بده.
6. وظیفه ساختن صفحه خبر هم به John میرسه، پس اونم یک شاخه بنام feature/newsfeed رو به وجود میاره.
7. همه کدهای توسعه‌دهنده‌های تیم در شاخه‌های جدا و مخصوص به خودشون هست و هیچ ربطی به هم ندارند.
8. حالا فرض کنید که Alice صفحه مربوط به login رو به پایان میرسونه و صفحه login آماده است. الان باید تغییراتی که در شاخه feature/login به وجود آورده رو به شاخه release/fb ارسال کنه. این کار با استفاده از Pull request انجام میشه.

Pull request

با شنیدن Pull request نباید این مورد رو با git pull اشتباه بگیرید و نزارید که گیجتون کنه. یک توسعه‌دهنده نمیتونه بصورت مستقیم به شاخه release کدهایی که نوشته رو push کنه. سرپرست پروژه که شما باشید باید در ابتدا کدهایی که در شاخه feature نوشته شده رو قبل از ادغام شدن با شاخه release، بررسی کنید. این کار با استفاده از Pull request انجام میشه.

Alice میتونه به راحتی یک pull request رو در github انجام بده. برای اینکار بصورت زیر عمل میکنه:

همونطور که میبینید در کنار نام شاخه feature/login یک دکمه به نام New pull request قرار داره که با کلیک کردن بر روی اون یک صفحه دیگه بصورت زیر باز میشه:

در تصویر بالا دو Dropdown قرار داره که بصورت زیر هستند:

• base : اون شاخه اصلی و مبدا که میخواید ببینید چه چیزهایی نسبت به اون تغییر کرده است. که در اینجا Alice اون رو release/fb قرار میده.
• compare : اون شاخه جدید که قصد داریم تغییرات اون رو مشاهده کنیم. در اینجا Alice شاخه feature/login مربوط به خودش رو انتخاب میکنه.

وقتی که کارهای بالا انجام شد، Alice باید یک عنوان و توضیحات رو برای این Pull request قرار بده و در نهایت بر روی دکمه Create pull request کلیک کنه. Alice همچنین باید reviewer یا بررسی کننده رو نیز در اینجا مشخص کنه. او نام شما رو از اونجا که سرپرست پروژه هستید، انتخاب میکنه.

شما هم متوجه Pull request میشید و تغییرات مورد نظر رو بررسی میکنید و در صورت تایید این تغییرات با شاخه release ادغام خواهند شد.

Code conflict

1. Bob هم کار خودش رو به پایان رسونده و اونم یک Pull request رو از سمت feature/friendrequest برای release/fb ارسال کرده است.
2. از اونجایی که هم اکنون کدهای مربوط به صفحه login در شاخه release/fb قرار داره، پس merge conflict پیش میاد. بررسی کردن conflict‌ها و برطرف کردن اونا بر عهده شما هست که سرپرست پروژه هستید. در نهایت کدهای Bob هم با شاخه release ادغام میشه.
3. در همین لحظه John هم کار خودش رو به پایان میرسونه و میخواد که کدهاشو با release ادغام کنه. اما John در برطرف کردن Conflict‌ها خیلی خوب و وارد هست. john قبل از اینکه درخواست pull request بده، آخرین تغییرات رو از شاخه release/fb میگیره و با شاخه خودش که feature/newsfeed هست، ادغام میکنه (این کار رو میتونه با استفاده از git pull یا git merge انجام بده). john همه conflict‌ها رو برطرف میکنه. حالا شاخه feature/branch همه کدهای مربوط به شاخه release/fb رو در خودش بدون conflict داره.
4. در نهایت John درخواست Pull request رو ارسال میکنه. این بار دیگه هیچ Code conflict ای پیش نماید چون که John همه اونا رو برطرف کرده است.

پس همونطور که دیدید 2 راه برای برطرف کردن Code conflict‌ها وجود داره:

• روش اول : بررسی کننده کدها که معمولا سرپرست پروژه هست، conflict‌ها رو برطرف کنه.
• روش دوم : توسعه‌دهنده قبل از Pull request، آخرین تغییرات رو بگیره و conflict‌ها رو برطرف کنه و بعد درخواست Pull request رو ارسال کنه.

در این مطلب همه چیز در مورد برطرف کردن Merge conflict در Git آموزش داده شده است.

در نهایت باز هم شاخه Master

زمانی که پروژه کامل شد و همه کارهای خودشون رو کردن و با شاخه release ادغام کردن، حالا باید خود شاخه release رو با شاخه master ادغام کنیم. بعد از این کدها بر روی محیط Production قرار میگیرن.

به همین راحتی میتونیم پروژه‌هامون رو با استفاده از git مدیریت کنیم.

Workflow‌های زیاد دیگه‌ای هم وجود دارند که خودتون میتونین جستجو کنید.

چه امتیازی به این مقاله می دید؟

1 2 3 4 5