استفاده از ابزارهای توسعه نرمافزار مانند گیت، برای راحتی کار مهندسان داده روی کار آمدهاند اما امروزه افرادی با مشاغل غیر مهندسی نیز از سیستمهای کنترل سورس مثل گیت و دیگر ابزارهایی که نیازمند نوشتن کد هستند، کمک میگیرند. به همین خاطر اشتباهاتی در این بین صورت میگیرد که افراد تازهکار را با مشکل مواجه میکند. برای جلوگیری از بروز اشتباهات git میتوانید به بررسی موارد ساده و ابتدایی بپردازید و نکات لازم را رعایت کنید تا با هیچگونه مشکلی مواجه نشوید. ما در این مقاله قصد داریم شما را با اشتباهات سادهای که نباید انجام دهید آشنا نموده و اصطلاحات لازم را برایتان شرح دهیم.
افرادی که با گیت سروکار دارند نیز با مشکلاتی مواجه میشوند که دلیل بروز این اشتباهات عدم داشتن اطلاعات کافی میباشد. از آنجایی که بسیاری از پروژهها به صورت تیمی به انجام میرسند نمیتوان عدم توانایی یا مهارت یک فرد را نادیده گرفت.
چراکه در انجام امور گروهی اثر کار هر فرد روی دیگری تاثیر میگذارد. افرادی که مهارت کدنویسی ندارند ممکن است هنگام انجام این کار دستورات ناصحیحی را در قالب اشتباهات git به انجام برسانند اما جدا از بحث کدنویسی ما در این مقاله قصد داریم شما را با مباحثی مثل ساختن کامیتهای بزرگ یا کار کردن مستقیم روی شاخه مستر و دیگر اشتباهاتی که پایه منطقی دارند آشنا کنیم و راه حل مقابله با این اشتباهات را بیان نماییم.
آیا تنها از شاخه مستر استفاده میکنید؟
اول از همه باید بدانید که گیت چه مفهومی دارد. هنگام کار روی پروژهها نباید تنها از شاخه مستر استفاده کرد، در واقع سیستمهای کنترل سورس آمدهاند که هر کس بتواند یک شاخه منحصر به فرد داشته باشد و به ارسال کامیتها در آن شاخه بپردازد تا در نهایت از بروز تداخل و هرگونه مشکل در انجام پروژه تیمی جلوگیری شود.
هر فرد در شاخه مختلفی میتواند به آزمایش قابلیتهای ایجاد شده بپردازد و آنها را پیاده سازی کند تا نتیجه دلخواه را از تغییرات به وجود آمده مشاهده نماید اما از شاخه مستر فقط برای نمایش سابقه پایداری کد استفاده میشود. هر یک از توسعهدهندگان میتوانند پس از اطمینان حاصل کردن از میزان کارایی تغییرات ایجاد شده و قابلیتهای تایید شده آن را در شاخه مستر قرار دهند.
در چنین شرایطی که هر فرد بهترین و صحیحترین تغییرات را در شاخه مستر اعلام می کند، انتشار نسخهها نیز به آسانی صورت گرفته و به راحتی کد شاخه مستر در اکثر موارد بدون هیچ گونه مشکل و اشتباهی بیلد میشود.
روششناسی مشخص برای شاخهسازی
تا به اینجا متوجه شدهاید که شاخههای مختلف برای انجام آزمایش و شاخه مستر برای بیلد کردن نسخه اصلی به کار گرفته میشود. یکی دیگر از مشکلاتی که ممکن است با آن مواجه شوید مربوط به مدیریت شاخه هاست.
Gitflow یکی از بهترین و متداولترین روشهایی است که برای شاخهسازی بهکار گرفته میشود و این روش برای همه افراد مناسب و قابل استفاده خواهد بود. افرادی که با نوشتن کد در محیطهای مختلف سروکار دارند یا حتی افرادی که مهندسان داده هستند و از روش دلخواه خود در انجام امور استفاده میکنند، در هر صورت Gitflow یک روششناسی مشخص برای شاخهسازی در انجام کارهایشان محسوب میشود.
Gitflow متشکل از سطوح مختلفی از شاخهسازی به صورت master ،develop و feature میباشد که هر یک از این سطوح به صورت مستقل از هم تعریف شدهاند.
Gitflow چیست؟
اگر به صورت تیمی کار کرده باشید حتماً با مشکلاتی مثل Merge Conflict یا تداخل و همزمانی توسعه ویژگیها آشنا هستید. اشتباهات git زمان زیادی از ما تلف کرده و روند انجام پروژه را کند مینمایند، در واقع برای ادغام کردن برنچهای مختلف و Deploy کردن آنها زمان و حوصله زیادی نیاز خواهد بود.
GitFlow مفهومی برای مدیریت برنچها است که به ما اجازه می دهد بدون ایجاد هرگونه مشکل به توسعه پروژه خود بپردازیم و بتوانیم به طور همزمان روی ویژگیهایی که قرار است به پروژه اضافه شود، کار کنیم بدون آنکه مشکلی در جهت مرج یا لانچ کردن بخش های مختلف پیش بیاید.
Branch Model
با gitflow میتوان اقدام به مدیریت محیط توسعه نمود و همچنین برنجها را مدیریت کرد و برای Merge شدن Branch ها با هم از روش مناسبی استفاده نمود. پس از نصب گیت با اجرای دستور زیر می توانید آن را در پروژه خود به کار بگیرید. این روش شاخهسازی توسط Vincent Driessen ابداع شده و تا به امروز استقبال زیادی از این روش به انجام رسیده چراکه استفاده از آن برای مقیاس پذیری و همکاری در تیم توسعه بسیار کارآمد میباشد.
git flow init
مزیتهای اصلی Gitflow
حال که با مفهوم گیتفلو آشنا شدهاید و بخشی از اشتباهات git را درک کرده اید در این بخش قصد داریم به مزیت های اصلی Gitflow بپردازیم.
توسعه موازی
از مهمترین نکاتی که در مورد گیتفلو مطرح است، این است که موجب میشود توسعه موازی کد تبدیل به یک عمل آسان شود. در واقع در این روش بخشهای جدید از کارهای پایانیافته جدا میشوند. برای توسعه قسمتهای جدید مثل رفع اِرورها و باگها، همچنین گسترش قابلیتها، از شاخه feature استفاده میشود و وقتی کد به بدنه اصلی برگشته و با آن ادغام میشود که فرد یا افراد توسعهدهنده، مطمئن شوند کد برای انتشار آماده میباشد.
اگر چه به وجود آمدن وقفه در یک کار تیمی اصلا خوشایند نیست اما اگر از شما درخواست سوئیچ از کاری به کار دیگر بشود، تنها لازم به کامیت کردن تغییرات خودتان خواهید داشت و پس از آن میتوانید برای کار جدید یک شاخه feature جدید بسازید. در نهایت وقتی کار جدیدتان پایان یافت، میتوانید به انجام دادن ادامه کار خود، در شاخه فیچر اصلی بپردازید.
همکاری
برای تسهیل امور بین همکاران(چند توسعهدهنده) روی فیچر اصلی، میتوان از شاخههای feature استفاده نمود. در دوقع هر شاخه فیچر یک sandbox است که تنها شامل تغییراتی میشود که برای راهاندازی فیچر جدید مورد نیاز میباشند. به این ترتیب مشاهده و پیگیری کارهایی که هر یک از اعضای تیم انجام میدهند به آسانی امکانپذیر میشوند.
ناحیه استیجینگ انتشار
وقتی توسعه بخشهای جدید تمام شد، مجدداً در شاخه develop ترکیب میشود. ناحیه staging مخصوصِ همه فیچرهای تکمیلشدهای است که هنوز منتشر نشدهاند.
پشتیبانی از اصلاحیه اضطراری
Staging از شاخههایhotfix پشتیبانی میکند که این شاخهها نیز ساخته شده از روی انتشارهای تگخورده هستند. میتوان برای ایجاد تغییرات ضروری از این شاخهها استفاده نمو. به این ترتیب میتوان مطمئن بود که hotfix فقط از اصلاحیه اضطراری تشکیل شده است. با این شرایط دیگر ریسک ادغام تصادفی در توسعه جدید از بین میرود.
طرز کار GitFlow چگونه است؟
ایجاد قابلیتهای جدید و همچنین رفع اِرور و باگهای غیراضطراری منجر به توسعه کد جدید میشود که همه این اعمال در شاخههای feature ساخته میشوند.
شاخههای feature انشعاب گرفته از شاخههای Develop هستند. شاخه release نیز از شاخه های تکمیلشده و اصلاحیههای آمادهی انتشاری تشکیل شده است که در این محل با یکدیگر ادغام شدهاند.
هر بار که قرار باشد یک نسخه جدید انتشار پیدا کند شاخه release از روی develop ایجاد می شود .
اگر مشکلی وجود داشته باشد مستقیماً در شاخه release اصلاحیه انجام شده و اقدامات لازم صورت میگیرد. در واقع کدها روی شاخه release آماده تست و توزیع میشوند و در همین محیط همه اقدامات لازم به انجام می رسد.
در نتیجه میتوان گفت که تا زمان انتشار نسخه اصلی و نهایی چرخه زیر ادامه مییابد
-> test -> fix -> redeploy -> retest
پس از پایان انتشار در شاخههای master و develop شاهد ادغام شدن شاخه release خواهیم بود. به این ترتیب میتوانیم مطمئن شویم که تغییرات صورت گرفته در این شاخه بر اثر توسعه کد جدید به صورت اتفاقی از بین نرفتهاند.
در چنین شرایطی شاخه master فقط برای ردگیری کدهای منتشر شده مورد استفاده قرار میگیرد پس فقط از طرف شاخههای release و hotfix به master کامیت ارسال میشود.
در چنین شرایطی انتشارات شامل تگ، به طور مستقیم در شاخه master منشعب شده و در صورت پایان یافتن، مجدداً در هر دو شاخه ادغام خواهند شد.( master و develop) به این ترتیب میتوانیم اطمینان حاصل کنیم که hotfix به صورت تصادفی در زمان انتشار نسخه بعدی از بین نرفته است.
کامیت کردن هزار فایل در یک کامیت
با کامیت کردن فایلهای زیاد در یک کامیت، اشتباه فنی رخ نمیدهد اما در کل این رویه چندان مناسب و خوشایند نیست. کامیت اولیه که در ریپازیتوری قرار می گیرد بحث جداگانهای دارد اما دیگر کامیتها تنها باید شامل تغییراتی باشند که قابل توضیح در یک خط بوده و تمام توضیحات نیز باید در همین سطر کوتاه درج شوند.
در مجموع روند کامیت کردن باید به این صورت باشد که همواره این عمل به انجام رسیده اما طول آن متناسب با قوانین، کوتاه باشد. برای این منظور می توانید پس از انجام هر نوع تغییر کوچکی اقدام به یک کامیت مناسب نمایید.
مشکلات رایج گیت و نحوه رفع آنها برای داشتن یک گردش کار روان
گیت یک ابزار قدرتمند برای کنترل نسخه است که به توسعهدهندگان اجازه میدهد کد خود را سازماندهی کرده و با هم همکاری کنند. با این حال، گیت میتواند برای افراد مبتدی کمی پیچیده باشد و منجر به اشتباهاتی شود که جریان کار شما را مختل کند. اما نگران نباشید! این اشتباهات رایج هستند و به راحتی قابل رفع میباشند.
در این بخش، به برخی از مشکلات رایج گیت که توسعهدهندگان مرتکب میشوند و نحوه رفع آنها برای داشتن یک گردش کار روانتر و کارآمدتر میپردازیم.
فراموش کردن کامیت [Forgetting to Commit]
یکی از رایجترین مشکلات گیت، فراموش کردن کامیت کردن تغییرات است. کامیت کردن به معنای ثبت مجموعه ای از تغییرات در کد شما به مخزن (repository) است. این کار به شما امکان میدهد تا به راحتی به نسخههای قبلی کد خود بازگردید و تاریخچهای از تغییرات را برای خود و همکارانتان ایجاد کنید.
راه حل: عادت کنید که به طور مرتب کامیت بزنید. یک قانون کلی این است که هر زمان که یک ویژگی جدید را تمام میکنید یا یک باگ را رفع میکنید، یک کامیت انجام دهید. برای کامیت کردن تغییرات خود، میتوانید از دستور git commit در ترمینال استفاده کنید.
پیامهای کامیت مبهم [Vague Commit Messages]
پیامهای کامیت به شما کمک میکنند تا بفهمید چه تغییراتی در هر نسخه از کد شما رخ داده است. پیامهای مبهم مانند ” تغییرات” یا “رفع باگ” برای شما یا همکارانتان مفید نخواهند بود.
راه حل: پیامهای کامیت خود را واضح، مختصر و گویا بنویسید. پیام باید توضیح دهد که چه چیزی تغییر کرده است و چرا.
کامیت نکردن به صورت منظم [Not Committing Regularly]
برخی از توسعهدهندگان تمایل دارند تا زمانی که کارشان روی یک ویژگی به طور کامل تمام نشده است، کامیت نزنند. این کار باعث میشود که ردیابی تغییرات و بازگشت به نسخههای قبلی در صورت لزوم، دشوار شود و این یکی دیگر از مشکلات رایج گیت است.
راه حل: همانطور که در بخش قبلی گفتیم، به طور مرتب کامیت بزنید. این کار نه تنها به شما کمک میکند تا تاریخچهای از تغییرات خود را حفظ کنید، بلکه به شما امکان میدهد تا در صورت بروز هر گونه مشکلی، به راحتی به نسخههای قبلی بازگردید.
نداشتن استراتژی برای شاخهها [No Branching Strategy]
یکی از قدرتمندترین ویژگیهای گیت، قابلیت ایجاد شاخهها (branch) است. شاخهها به شما این امکان را میدهند تا روی ویژگیهای جدید یا رفع باگها بدون تأثیرگذاری بر کد اصلی کار کنید. با این حال، نداشتن استراتژی برای شاخهها میتواند منجر به سردرگمی و درگیری در مخزن شود.
راه حل: یک استراتژی برای ایجاد و مدیریت شاخهها در پروژه خود داشته باشید. یک رویکرد رایج این است که برای هر ویژگی جدید یا رفع باگ یک شاخه جداگانه ایجاد کنید. به این ترتیب، میتوانید به راحتی روی یک کار خاص تمرکز کنید و قبل از ادغام آن با شاخه اصلی، آن را آزمایش کنید.
فراموش کردن پول (Pull) کردن تغییرات [Forgetting to Pull Changes]
هنگامی که با همکاران روی یک پروژه کار میکنید، مهم است که تغییرات آنها را به شاخه محلی خود ادغام کنید (merge). این کار با دستور git pull انجام میشود. فراموش کردن پول کردن تغییرات میتواند منجر به درگیری در کد شود، زیرا ممکن است شما و همکارتان روی نسخههای متفاوتی از کد کار کنید.
راه حل: عادت کنید که به طور مرتب تغییرات را از مخزن راه دور (remote repository) پول کنید. این کار به شما اطمینان میدهد که همیشه آخرین نسخه کد را در شاخه محلی خود دارید.
اینها تنها چند نمونه از اشتباهات رایج گیت هستند. در ادامه به برخی دیگر از اشتباهات رایج و نحوه رفع آنها میپردازیم.
فشار (Push) مستقیم به شاخه اصلی [Pushing Directly to Main Branch]
فشار مستقیم به شاخه اصلی (Main Branch) یک اشتباه رایج است که میتواند منجر به مشکلات بزرگی شود. شاخه اصلی معمولاً به عنوان پایهای برای کد پایدار در نظر گرفته میشود و باید تا حد امکان دست نخورده باقی بماند. فشار مستقیم به این شاخه میتواند تغییرات ناتمام یا ناپایدار را به آن وارد کند و منجر به شکستن کد برای سایر توسعهدهندگان شود.
راه حل: به جای فشار مستقیم به شاخه اصلی، از شاخههای جداگانه برای کار روی ویژگیهای جدید یا رفع باگها استفاده کنید. پس از اتمام کار خود، میتوانید تغییرات را به شاخه اصلی ادغام کنید. برای ادغام تغییرات، میتوانید از دستور git merge استفاده کنید.
عدم حل تعارضهای [Not Resolving Merge Conflicts]
هنگامی که تغییرات را از یک شاخه به شاخه دیگر ادغام میکنید، ممکن است با تعارضهای ادغام مواجه شوید. این زمانی اتفاق میافتد که دو توسعهدهنده روی بخشهای مشابه کد کار میکنند و تغییرات آنها با هم همپوشانی دارد. اگر تعارضهای ادغام را به درستی حل نکنید، میتواند منجر به مشکلات بزرگی شود.
راه حل: برای حل تعارضهای ادغام، باید کد را به صورت دستی بررسی کنید و مشخص کنید که کدام نسخه از کد را باید نگه دارید. برای انجام این کار، میتوانید از ویرایشگر متن خود یا یک ابزار ادغام بصری مانند GitKraken استفاده کنید.
عدم استفاده از فایلهای .gitignore [Not Using .gitignore Files]
فایلهای .gitignore به شما این امکان را میدهند تا مشخص کنید که کدام فایلها و پوشهها نباید به مخزن گیت اضافه شوند. این میتواند مفید باشد، زیرا شما نمیخواهید هر فایلی را که در پروژه خود دارید، مانند فایلهای پیکربندی یا فایلهای موقت، به مخزن اضافه کنید.
راه حل: برای هر پروژه خود یک فایل .gitignore ایجاد کنید و تمام فایلها و پوشههایی را که نمیخواهید به مخزن اضافه شود، در آن لیست کنید. میتوانید لیست نمونهای از فایلهای .gitignore را در وب سایت Git پیدا کنید.
عدم استفاده از گیتفلو (GitFlow) [Not Using GitFlow]
گیتفلو یک رویکرد محبوب برای مدیریت شاخهها در پروژههای گیت است و یکی از مشکلات رایج گیت عدم استفاده از این ابزار محسوب میشود. این رویکرد به شما کمک میکند تا یک ساختار شاخه منظم را حفظ کنید و از بروز مشکلات ناشی از ادغام جلوگیری کنید.
راه حل: اگر در حال کار روی یک پروژه بزرگ هستید، استفاده از گیتفلو را در نظر بگیرید. میتوانید اطلاعات بیشتری در مورد گیتفلو را در وب سایت Atlassian پیدا کنید.
عدم استفاده از ابزارهای گیت [Not Using Git Tools]
تعداد زیادی ابزار گیت وجود دارد که میتواند به شما در انجام کارهایتان به طور کارآمدتر کمک کند. این ابزارها میتوانند برای کارهایی مانند بررسی تاریخچه کد، حل تعارضهای ادغام و بررسی کد استفاده شوند.
راه حل: با برخی از ابزارهای گیت محبوب آشنا شوید و ببینید که کدام یک برای شما مفیدتر هستند. برخی از ابزارهای محبوب عبارتند از:
- GitKraken
- SourceTree
- Visual Studio Code with GitLens extension
- GitHub Desktop
عدم درخواست کمک [Not Asking for Help]
اگر در استفاده از گیت با مشکلی مواجه هستید، نترسید که از دیگران کمک بخواهید. منابع زیادی برای کمک به شما در یادگیری گیت و حل مشکلاتتان وجود دارد.
راه حل: اگر در استفاده از گیت با مشکلی مواجه هستید، میتوانید از موارد زیر کمک بگیرید:
- مستندات رسمی گیت
- انجمن گیت
- Stack Overflow
- همکارانتان
کلام پایانی
گیت یک ابزار قدرتمند است که میتواند به شما در سازماندهی کد و همکاری با دیگران کمک کند. با این حال، یادگیری گیت میتواند کمی دشوار باشد و منجر به اشتباهاتی شود که جریان کار شما را مختل کند. با آگاهی از اشتباهات رایج و نحوه رفع آنها، میتوانید از گیت به طور کارآمدتر استفاده کنید و یک گردش کار روانتر و کارآمدتر داشته باشید.
در مجموع باید بدانید که گیت نیز مثل دیگر فناوریهایی که امروزه کاربرد زیادی دارند، مبحثی است که حتماً باید نسبت به آن آگاهی داشته باشید و با دانش کافی به استفاده از آن بپردازید. با انجام اشتباهات git ممکن است روند انجام یک پروژه را کند کرده یا برای آن مشکلاتی را ایجاد کنید که بهرهوری کار شما را کاهش دهد. بنابراین یادگیری گیت از همان پایه و مبانی ابتدایی گرفته تا دستورات پیچیدهتر و نوشتن کدهای کاربردیتر، برای همه افرادی که با سیستمهای کنترل سورس کار می کنند، امری ضروری محسوب میشود. برای این هدف میتوانید از دورههای آموزش گیت و آموزش برنامه نویسی مکتب خونه استفاده کنید.
