اشتباهات ساده Git که نباید انجام بدهید | راهنمای کاربردی

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

تیم‌های غیر مهندسی غالباً در زمان استفاده از گیت با مشکلاتی مواجه می‌شوند، چون کارفرما توجه کافی به آموزش تیم خود نمی‌کند و یا از سوی همتایان مهندس خود پشتیبانی کافی دریافت نمی‌کنند. در این موقعیت، مدل «هر کس مسئول کارهای خودش است» جواب نمی‌دهد، چون آموزش بخش بسیار مهمی از توسعه و رشد یک تیم محسوب می‌شود.

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

آیا تنها از شاخه مستر استفاده می‌کنید؟

اگر در پروژه خود تنها از شاخه مستر استفاده می‌کنید، احتمالاً مفهوم Git یا به طور کلی سیستم‌های کنترل سورس را به درستی متوجه نشده‌اید. اگر جزئی از یک تیم هستید و تنها از شاخه مستر استفاده می‌کنید، هر کس یک شاخه مستر لوکال خواهد داشت که کامیت‌ها را به آن شاخه ارسال می‌کند که موجب بروز هزاران تداخل می‌شود. برای اجتناب از این مشکل باید از شاخه‌های مختلف استفاده کنید.

فیلم آموزش گیت Git، گیت هاب و گیت لب (رایگان) در فرادرس

کلیک کنید

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

روش‌شناسی مشخص برای شاخه‌سازی

اینک که با مفهوم اساسی شاخه‌ها آشنا شدید و می‌توانید شاخه‌ها را ساخته و در شاخه مستر ادغام کنید، مشکل بعدی که ممکن است مواجه شوید، رویه مدیریت شاخه‌ها است. رایج‌ترین و ارزشمندترین روش‌شناسی برای شاخه‌سازی به صورت gitflow است. چه مهندس داده باشید و چه مشغول نوشتن کوئری‌های SQL یا کاری مانند نوشتن اسکریپت‌های پایتون با استفاده از pandas‌ ،numpy ،scipy و غیره باشید در هر حال Gitflow به کمک شما می‌آید.

Gitflow شامل سه سطح از شاخه‌سازی به صورت master ،develop و feature به عنوان سه سطح مستقل از هم است. البته استثناهایی در مورد این سه سطح وجود دارد، اما شما به عنوان مبتدی کافی است روی همین سه سطح متمرکز شوید.

Gitflow چیست؟

گیت‌فلو یک مدل «شاخه‌سازی» (branching) برای Git است که از سوی «وینسنت دریزن» (Vincent Driessen) ابداع شده است. این مدل با استقبال زیادی مواجه شده است، زیرا برای همکاری و مقیاس‌پذیری تیم توسعه بسیار مناسب است.

فیلم آموزش گیت Git – تکمیلی در فرادرس

کلیک کنید

مزیت‌های اصلی Gitflow

در این بخش برخی مزایای عمده روش‌شناسی Gitflow را بررسی می‌کنیم.

توسعه موازی

یکی از مهم‌ترین نکات در مورد Gitflow این است که موجب می‌شود توسعه موازی کد به امر آسانی تبدیل شود. این کار از طریق جداسازی توسعه بخش‌های جدید از کار‌های پایان یافته صورت می‌گیرد. توسعه بخش‌های جدید مانند قابلیت‌ها و اصلاح باگ‌های غیر اضطراری در شاخه‌های feature انجام می‌یابد و تنها زمانی دوباره در بدنه اصلی کد ادغام می‌شوند که توسعه‌دهنده-(گان) مطمئن باشند که کد آماده انتشار است.

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

همکاری

شاخه‌های فیچر امکان همکاری بین دو یا چند توسعه‌دهنده روی فیچر واحد را نیز تسهیل می‌کنند، زیرا هر شاخه فیچر یک «سندباکس» (sandbox) است که تنها تغییراتی را شامل می‌شود که برای راه‌اندازی فیچر جدید مورد نیاز هستند. به این ترتیب امکان مشاهده و پیگیری کارهایی که هر یک از اعضای تیم انجام می‌دهد به آسانی میسر می‌شود.

ناحیه استیجینگ انتشار

زمانی که توسعه بخش‌های جدید پایان یافت، دوباره در شاخه develop ادغام می‌شود که ناحیه staging برای همه فیچرهای تکمیل‌شده‌ای است که هنوز انتشار نیافته‌اند. بنابراین زمانی که انتشار نسخه بعدی از شاخه develop منشعب شد، به صورت خودکار شامل همه موارد جدیدی که پایان یافته هستند خواهد بود.

پشتیبانی از اصلاحیه اضطراری

Staging از شاخه‌های hotfix پشتیبانی می‌کند. این شاخه‌ها از روی انتشارهای تگ‌خورده ساخته می‌شوند. شما می‌توانید از این موارد برای ساخت تغییرهای ضروری استفاده کنید و می‌توانیم مطمئن باشیم که hotfix تنها شامل اصلاحیه اضطراری است. بدین ترتیب این ریسک که همزمان به صورت تصادفی در توسعه جدید نیز ادغام کنید از میان می‌رود.

طرز کار GitFlow چگونه است؟

توسعه کد جدید یعنی قابلیت جدید و اصلاح‌های باگ‌های غیر اضطراری در شاخه‌های فیچر ساخته می‌شوند:

شاخه‌های فیچر از شاخه Develop منشعب می‌شوند و فیچرهای تکمیل‌شده و اصلاحیه‌ها زمانی که آماده انتشار باشند، دوباره در شاخه release ادغام می‌شوند.

زمانی که موعد یک انتشار جدید فرا می‌رسد، شاخه release از روی develop ایجاد می‌شود:

کد موجود در شاخه release روی یک محیط مناسب برای تست توزیع و تست می‌شود و هر مشکلی که وجود داشته باشد به صورت مستقیم در شاخه release اصلاح خواهد شد. بنابراین چرخه deploy -> test -> fix -> redeploy -> retest تا زمانی که از نسخه انتشار راضی شوید و بدانید که برای توزیع نهایی آماده است ادامه می‌یابد.

زمانی که انتشار پایان یافت، شاخه release در شاخه master و همچنین develop ادغام می‌شود تا مطمئن شویم که تغییرات صورت گرفته در شاخه release به صورت تصادفی بر اثر توسعه کد جدید از دست نرفته است.

به این ترتیب شاخه master تنها برای ردگیری کدهای منتشر شده مورد استفاده قرار می‌گیرد و تنها کامیت‌ها به master از سوی شاخه‌های release و hotfix هستند.

این موارد مستقیماً از انتشارهای شامل تگ در شاخه master منشعب می‌شوند و زمانی که پایان یابند دوباره در هر دو شاخه master و develop ادغام می‌شوند تا مطمئن باشیم که hotfix در زمان انتشار دوره‌ای بعدی به صورت تصادفی پاک نشده است.

کامیت کردن هزار فایل در یک کامیت

با این که این کار از نظر فنی یک اشتباه محسوب نمی‌شود، اما رویه‌ای کاملاً بد به حساب می‌آید. جدا از کامیت اولیه در ریپازیتوری، کامیت‌ها شما باید شامل تنها آن تغییرهایی باشند که بتوان به روشنی در یک خط پیام کامیت آن‌ها را توضیح داد. بنابراین پیامی مانند «کامیت کردن همه تغییرهای کامیت نشده» نمی‌تواند یک پیام خوب برای کامیت کردن هزاران تغییر در فایل‌های مختلف باشد. شعار زیر را همواره به خاطر داشته باشید:

کم کامیت کن، همیشه کامیت کن.

ایده کلی این است که هر زمان کوچک‌ترین واحد کاری را به انجام رساندید، آن را کامیت کنید.

سخن پایانی

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