مدیریت یک پروژه واقعی در شرکت، فراتر از دانستن دستورات جداگانه گیت است و به مهارت ترکیب هوشمندانه این ابزارها در شرایط حساس نیاز دارد. در این مرحله نهایی، شما از نقش یک یادگیرنده خارج شده و به عنوان یک عضو موثر در تیم، وظیفه اجرای صفر تا صد یک تسک فنی را بر عهده میگیرید.
تمام آموختههای قبلی شما، از ساخت شاخه تا حل تعارضات کدی، در این سناریوی عملی به کار گرفته میشوند تا یک خروجی استاندارد و حرفهای تولید کنید. این پروژه پایانی به شما اعتمادبهنفس لازم برای حضور در تیمهای نرمافزاری و پروژههای جدی را میدهد.
یاد میگیرید که چگونه یک تسک را دریافت کنید، تغییرات را با دقت ثبت نمایید و در نهایت با باز کردن یک PR اصولی، کدهای خود را برای بررسی همتیمیها ارسال کنید. تسلط بر این چرخه کامل، مرز میان یک کارآموز و یک برنامهنویس آمادهبهکار در بازار حرفهای است.
دریافت تسک و تحلیل نیازمندیها
در شرکتهای نرمافزاری، فرآیند توسعه با دریافت یک وظیفه مشخص (Task) آغاز میشو. شما نباید بلافاصله شروع به کدنویسی کنید؛ بلکه ابتدا باید ابعاد مختلف خواسته شده را بررسی کرده و مطمئن شوید که تمام جزئیات فنی را درک کردهاید]. این مرحله به شما کمک میکند تا نقشه راه دقیقی برای تغییرات خود داشته باشید و از دوبارهکاری بپرهیزید.
برای این پروژه، فرض کنید مدیر تیم از شما خواسته است تا یک فایل جدید به نام contact.txt ایجاد کرده و اطلاعات تماس شرکت را در آن ثبت کنید.
در مرحله دریافت تسک، چطور باید نیازمندیها را تحلیل کنیم؟
در مرحله تحلیل نیازمندیها، همانطور که در ابتدا گفته شد، نباید بلافاصله کدنویسی را شروع کنید. ابتدا باید ابعاد مختلف وظیفه محول شده را بررسی کنید تا مطمئن شوید تمام جزئیات فنی را بهخوبی درک کردهاید. این کار به شما کمک میکند تا یک نقشه راه دقیق برای تغییرات خود داشته باشید و از دوبارهکاری در میانه پروژه جلوگیری کنید.
به عنوان مثال، در تسک فعلی ما، باید به این سوالات پاسخ دهید:
- نام دقیق فایل چیست؟ (در این سناریو: contact.txt).
- چه محتوایی باید در آن قرار بگیرد؟ (در این سناریو: اطلاعات تماس شرکت).
- آیا پیشنیاز خاصی وجود دارد؟ (مانند نیاز به ساخت پوشه جدید یا تغییر در فایلهای دیگر).
با مشخص شدن این موارد، ذهن شما برای پیادهسازی آماده میشود.
ساخت شاخه (Branch) اختصاصی
در شرکتهای نرمافزاری، کدنویسی مستقیم روی شاخه اصلی (Main) اکیداً ممنوع است. برای اینکه تغییرات شما با کدهای پایدار پروژه تداخل پیدا نکند، باید یک محیط ایزوله و مستقل به نام شاخه (Branch) بسازید. این کار به شما اجازه میدهد تا بدون نگرانی از خراب شدن نسخه نهایی، روی تسک خود تمرکز کنید و در صورت نیاز، آن را به راحتی با کدهای تیم ادغام نمایید.
برای شروع این مرحله، دستور زیر را در ترمینال بنویسید تا شاخهای جدید به نام feature/add-contact ساخته شده و مستقیماً به آن وارد (Checkout) شوید:
git switch -c feature/add-contactبا اجرای این دستور، گیت یک کپی از آخرین وضعیت شاخه اصلی برمیدارد و محیطی اختصاصی برای کدنویسی شما فراهم میکند.
بررسی شاخه فعلی
دستور git status سریعترین روش برای شناسایی شاخه فعال است؛ این دستور در اولین خط خروجی، نام شاخهای را که در آن هستید به شما اعلام میکند. روش دیگر، اجرای دستور git branch است که لیست تمام شاخهها را نمایش داده و شاخه فعلی را با یک علامت ستاره (*) و معمولاً رنگ متفاوت متمایز میکند. اطمینان از حضور در شاخه صحیح، از ثبت اشتباه تغییرات روی کدهای اصلی (Main) جلوگیری میکند.
مدیریت فایلهای اضافی
مدیریت فایلهای غیرضروری با استفاده از فایل .gitignore یکی از نشانههای برنامهنویسان حرفهای در کار تیمی است. در هر پروژه، فایلهایی مانند تنظیمات شخصی ویرایشگر، پکیجهای حجیم (مثل node_modules) یا اطلاعات حساس (مثل .env) تولید میشوند که نباید به مخزن شرکت راه پیدا کنند.
نادیده گرفتن این فایلها باعث میشود حجم مخزن بیهوده بالا نرود و امنیت اطلاعات پروژه حفظ شود. برای تسک فعلی، تصور کنید سیستمعامل شما فایلهای موقتی (مانند DS_Store در مک یا Thumbs.db در ویندوز) ایجاد کرده است.
برای جلوگیری از ورود آنها به گیت، فایلی به نام .gitignore بسازید و نام این الگوها را در آن بنویسید. با این کار، گیت به صورت خودکار این پسماندهای دیجیتالی را نادیده میگیرد و فقط کدهای اصلی شما را ردیابی میکند.
کدنویسی و اعمال تغییرات
اکنون زمان آن رسیده است که وظیفه اصلی خود را در محیط ایزولهای که ساختهاید، اجرا کنید. در این مرحله، شما با استفاده از ویرایشگر متن یا محیط برنامهنویسی خود، تغییرات لازم را در فایلها اعمال میکنید. تمرکز بر روی اجرای دقیق نیازمندیها و پرهیز از اعمال تغییرات اضافی و نامربوط، از ویژگیهای بارز یک برنامهنویس حرفهای است.
برای اجرای این تسک، فایلی به نام contact.txt بسازید و اطلاعات فرضی زیر را در آن بنویسید:
- ایمیل: info@company.com
- تلفن: ۰۲۱-۱۲۳۴۵۶۷۸
با ذخیره این فایل، بخش فنی تسک شما به پایان میرسد.
نگارش کامیت استاندارد
ثبت تغییرات با پیامهای معنادار و حرفهای، بدنه اصلی کار شما در یک شرکت نرمافزاری است. پیامهای مبهم مانند "Fix" یا "Update" نه تنها کمکی به تیم نمیکند، بلکه باعث سردرگمی در ردیابی تاریخچه پروژه میشود. برای داشتن یک تاریخچه تمیز و مطابق با استانداردهای جهانی، از روش Conventional Commits و تگهایی مانند feat (برای ویژگی جدید) یا fix (برای اصلاح خطا) استفاده کنید.
ابتدا با دستور زیر فایل خود را به محیط استیج منتقل کنید:
git add contact.txt
سپس با پیامی دقیق و گویا، تغییر را ثبت نهایی کنید:
git commit -m "feat: add company contact information file"
نگارش اصولی پیام کامیت به همتیمیهای شما اجازه میدهد بدون نیاز به بررسی خط به خط کدها، از هدف و ماهیت تغییرات شما مطلع شوند.
اگر پیام کامیت را اشتباه نوشته باشیم، چگونه آن را اصلاح کنیم؟
برای اصلاح پیام آخرین کامیت، از دستور زیر در ترمینال استفاده کنید:
git commit --amendبا اجرای این دستور، ویرایشگر متن پیشفرض باز میشود و پیام قبلی را به شما نمایش میدهد [۱۵۹]. کافی است متن را ویرایش کرده، فایل را ذخیره و سپس ببندید. گیت به صورت خودکار یک کامیت جدید با پیام اصلاحشده ایجاد کرده و آن را جایگزین نسخه قبلی میکند.
نکته مهم: این کار را فقط برای کامیتهای محلی انجام دهید و اگر کامیت را قبلاً به سرور (Push) فرستادهاید، از اصلاح آن خودداری کنید تا نظم مخزن همتیمیهایتان به هم نخورد.
حل تعارض (Conflict) احتمالی
تعارض زمانی رخ میدهد که شما و یکی از همتیمیهایتان همزمان روی یک خط از یک فایل تغییراتی ایجاد کرده باشید و گیت نتواند به صورت خودکار تصمیم بگیرد کدام نسخه اولویت دارد. در پروژههای واقعی، این یک اتفاق کاملاً طبیعی است و نباید باعث نگرانی شما شود.
برای حل این چالش، باید فایلهای دارای تعارض را باز کرده و بخشهای نشانهگذاری شده توسط گیت را به صورت دستی بررسی کنید. پس از اینکه تصمیم گرفتید کدام بخش از کد باید باقی بماند، نشانههای تعارض را پاک کرده، فایل را ذخیره و دوباره با دستور git add آن را به محیط استیج بفرستید تا آماده ثبت نهایی شود.
اگر در حل تعارض اشتباه کنیم، راه برگشتی وجود دارد؟
بله، خوشبختانه گیت مانند یک ماشین زمان عمل میکند و برای هر اشتباهی در حل تعارض، راهی برای بازگشت در نظر گرفته است. این ویژگی به شما اجازه میدهد با جسارت بیشتری کدنویسی کنید، چرا که میدانید گیت پشتیبان شماست.
اگر در حین حل تعارض متوجه اشتباه شدید، میتوانید از این روشها استفاده کنید:
- لغو کامل ادغام: اگر در میانه حل تعارضات هستید و میخواهید همه چیز را به حالت قبل از شروع ادغام (Merge) برگردانید، دستور git merge --abort بهترین گزینه است.
- بازگرداندن یک فایل خاص: اگر فقط در یکی از فایلها اشتباه کردهاید، میتوانید با دستور git restore آن فایل را به وضعیت قبل از ویرایشهای دستی خود برگردانید.
- استفاده از Reset: حتی اگر اشتباهاً کامیت را ثبت کرده باشید، با دستور git reset میتوانید اشارهگر شاخه را به آخرین نقطه پایدار (قبل از ادغام) به عقب برگردانید.
ارسال کدهابه سرور (Push)
پس از ثبت کامیتها در سیستم خودتان، وقت آن است که آنها را به مخزن آنلاین شرکت (مانند گیتهاب) منتقل کنید تا همتیمیهایتان به کدهای شما دسترسی داشته باشند. این کار پل ارتباطی میان محیط کار شخصی شما و فضای همکاری تیمی است.
از آنجا که این اولین بار است که شاخه feature/add-contact را ارسال میکنید، باید از دستور زیر استفاده کنید:
git push -u origin feature/add-contactسوییچ -u یک رابطه ردیابی بین شاخه محلی و نسخه سروری آن ایجاد میکند تا در دفعات بعدی، تنها با نوشتن git push عملیات ارسال انجام شود. با اجرای این دستور، گیت تمام تاریخچه و فایلهای جدید شما را به سرور منتقل کرده و پیامی مبنی بر موفقیتآمیز بودن عملیات نمایش میدهد.
باز کردن Pull Request (PR)
Pull Request یا همان «درخواست بازبینی»، قلب تپنده همکاری تیمی در پلتفرمهایی مانند گیتهاب است. این مرحله حیاتیترین بخش کار در یک شرکت نرمافزاری محسوب میشود؛ زیرا جایی است که شما از مدیر فنی یا سایر همتیمیهای خود دعوت میکنید تا کدهای شما را بررسی، نقد و در نهایت برای ادغام در پروژه اصلی تایید کنند.
نوشتن یک درخواست شفاف
در محیط گیتهاب، پس از انتخاب شاخه feature/add-contact و کلیک روی دکمه "Compare & pull request"، باید شناسنامه دقیقی برای کار خود بسازید. یک PR حرفهای باید شامل یک عنوان گویا و توضیحات کامل باشد؛ در این بخش توضیح دهید که چه تغییری ایجاد کردهاید، هدف از انجام آن چه بوده و چه بخشهایی نیاز به توجه بیشتر همتیمیها دارد.
پایان یک چرخه موفق
باز کردن PR به تیم اجازه میدهد تا قبل از ورود کد به شاخه اصلی (Main)، آزمایشهای لازم را انجام داده و از سلامت پروژه مطمئن شوند. با تایید نهایی و ادغام (Merge) این درخواست، شاخه شما با شاخه اصلی ترکیب شده و تسک شما رسماً به پایان میرسد. فراموش نکنید که پس از ادغام موفق، شاخه فرعی خود را حذف کنید تا مخزن پروژه همیشه تمیز باقی بماند.
چگونه شاخه فرعی را بعد از PR حذف کنیم؟
پس از اینکه درخواست بازبینی (PR) شما تایید و در شاخه اصلی ادغام شد، دیگر نیازی به آن شاخه فرعی نخواهید داشت و بهتر است برای خلوت ماندن مخزن، آن را حذف کنید.
برای حذف شاخه، این دو مرحله را انجام دهید:
۱. حذف در سیستم خودتان (Local): ابتدا به شاخه اصلی بازگردید و سپس با دستور زیر، شاخه فرعی را حذف کنید:
git branch -d feature/add-contact۲. حذف در گیتهاب (Remote): معمولاً در محیط گیتهاب پس از بستن PR، دکمهای به نام Delete branch ظاهر میشود که با کلیک روی آن، شاخه از روی سرور پاک میشود.
همچنین میتوانید از دستور زیر در ترمینال استفاده کنید:
git push origin --delete feature/add-contactپاکسازی شاخهها کمک میکند تا همیشه بر اساس آخرین نسخه شاخه اصلی، کارهای جدید را شروع کنید.
خلاصه کاربردی: چرخه کامل یک روز کاری با گیت
این چکلیست، تمام مراحلی را که برای انجام حرفهای یک تسک در شرکت طی کردیم، به صورت فشرده نمایش میدهد:
- تحلیل نیازمندیها: درک دقیق وظیفه (تسک) پیش از شروع هرگونه تغییر.
- ساخت شاخه (Branch): جدا کردن محیط کار با دستور git switch -c <branch-name>.
- پاکسازی با Gitignore: نادیده گرفتن فایلهای سیستمی و اضافی در فایل .gitignore.
- اعمال تغییرات: ایجاد یا ویرایش فایلها (در این پروژه فایل contact.txt) .
- کامیت استاندارد: انتقال به استیج با git add و ثبت با پیام معنادار (مثل feat: ...).
- مدیریت تعارض: حل دستی تداخلات کدی در صورت بروز در زمان ادغام.
- ارسال به سرور (Push): انتقال شاخه به گیتهاب با دستور git push -u origin <branch-name>.
- Pull Request: باز کردن درخواست بازبینی برای همتیمیها و ادغام نهایی در شاخه Main.
- پاکسازی نهایی: حذف شاخه فرعی پس از ادغام برای تمیز ماندن مخزن.
با تسلط بر این چرخه، شما آماده همکاری در هر پروژه نرمافزاری بزرگی هستید.