زیر پوستۀ git

در این مقاله سعی دارم، به نقش گیت (git)؛ راهکار مدیریت محتوای توزیع شده ای، که به محض پیدایش توانست نظر کاربران و برنامه نویسان بسیاری را به خود جلب و در اشاعه فرهنگ اپن سورس نقش کلیدی را عهده دار شود بپردازم. با این امید که خواندن این مطلب بتونه به روشن تر شدن ماهیت درونی "روال گیت" و بهره مندی از توان ایجاد داکیومنتری و کد بیس منسجم تری در توسعه پروژه هاتون، و در نهایت به تبحر لازم در استفاده از گیت به منظور پیوستن به میلیون ها برنامه نویس اجتماع اُپن سورس منجر بشه.

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

سخنی با برنامه نویسان

متاثر از فرهنگ متن باز و در پی استقبال شگفت انگیز جامعه برنامه نویسان از این ساختارِ اجتماعی، که با محوریت توسعه و پیشرفت برای بشر، به دور از منازعات حاکم بر دنیای "سخت" پدید آمده است، جهان نرم افزار این روزها در دوران باشکوهی از حیات خود به سر می برد. نبرد کمپانی های بزرگ تولیدات نرم افزاری، هر روز کمرنگ و کمرنگ تر، و جدال ها، جای خود را به همکاری و تعامل برای نیل به شکوفایی روز افزون تکنولوژی داده است. در این میان سهم برنامه نویسان ایرانی همچون گذشته از این تجارت، و از آن مهم تر، این جریان همراهی جهانی در قالب نام اُپن سورس (open source)، بسیار ناچیز است.
عدم شناخت بسیاری از برنامه نویسان نسبت به هویت جدیدی که جامعه جهانی به صورت مجموعه ای از قراردادها که به دور از تعصب و تنها در جهت هرچه توانمندتر شدن یکایک افراد بشر، با نام open-source مدون و حلقه مفقودی که بر پیدایش شکاف عظیم میان جامعه برنامه نویسان ایرانی در مقایسه با همکاران انگلیسی زبانشان دامن زده. در حالی که ضعف عمومی در زبان انگلیسی می تواند از دلایل اصلی این فاصله محسوب گردد، با این حال نه دلایل و نه راهکار ها به یادگیری زبان ختم نمی شوند. عدم شناخت و کاربستِ فرهنگ کد باز و نقش ابزار گیت در فراهم آوردن بستر لازم برای تحقق این همراهیِ جهانی نیز میتوانند از موضوعاتی باشند که بر این نقصان تاثیر گذارده است.

اصطلاحات و کلمات کلیدی:

گیت (به انگلیسی: Git) یک نرم‌افزار کنترل نسخه و از مدل نرم‌افزارهای آزاد و متن‌باز برای بازنگری کد منبع توزیع شده و مدیریت منبع کد است که برای دنبال کردن تغییر فایلهای کامپیوتری و دنبال کردن کارهای انجام شده روی آن‌ها توسط افراد مختلف است.

نرم‌افزار آزاد و متن‌باز (به انگلیسی: Free and open source software یا FLOSS، F/OSS، FOSS)، نرم‌افزاری است که به‌منظور تأمین حق کاربران برای مطالعه، تغییر، و بهبود طراحی آن، با دردسترس‌بودن کد مبدأ نرم‌افزار، به‌شکل آزاد پروانه‌دار گشته است.

کنترل نسخه یا کنترل منبع (به انگلیسی: Revision control) عبارت است از سیستمی برای کنترل و پی‌گیری تغییرات واحد اطلاعاتی دخیل در ایجاد یک برنامهٔ نرم‌افزاری. واحد اطلاعاتی مزبور می‌تواند شامل فایل‌های سورس، راهنماها، میک فایل‌ها، اشیاء نرم‌افزاری و ... سورس کنترل به خصوص در جایی اهمیت پیدا می‌کند که چند برنامه‌نویس بخواهند روی منابع مشترکی کار کنند. در این صورت است که مفاهیمی همانند مقایسه، ترکیب، تداخل و ... پیش می‌آیند که سورس کنترل باید بتواند راه حل مناسبی برای هر یک ارائه دهد.

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

جریان یا روال گیت (به انگلیسی :Gitflow) یکی از سیستم های اتوماسیون و همسان سازیِ ساختار branch سازی، و منظم سازیِ توالیِ اجرای فرامین گیت بر روی مخزن کد پروژه است. gitflow در قالب کامند هایی با همراهی git می تواند روال version controlling با استفاده از git را در پروژه های مشارکتی یکپارچه و منظم نماید.

چگونگی پیدایش git

هسته اصلی این نرم افزار در سال 2005، توسط Linus Torvalds و به عنوان یکی دیگر از پروژه های اُپن سورس تحت نظارت لینوکس، که خود به عنوان اولین نرم افزار متن باز تاریخ، در حال رشد بود، شروع شد. این برنامه در پی نیاز برنامه نویسانی پدید آمد که از نقاط مختلف جهان در کد نویسی و طراحی پروژه لینوکس مشارکت داشتند. بستری که تا آن زمان عملیات مدیریت مخازن کد آنها را بر عهده داشت، به دلایلی از ادامه سرویس رسانی به آنها شانه خالی کرده و گزینه مناسبی که جوابگوی حجم تراکنشهای آنها باشد وجود نداشت. گیت تنها پس از دو ماه به مرحله استفاده رسیده و به عنوان نرم افزار کنترل نسخه رسمی برای گسترش لینوکس معرفی گردید.

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

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

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

• امکان کار به صورت متمرکز بر روی مخازن کد که گیت آنها را repository میخواند.
• نگهداری حالت دقیق محتویات مخزن در قالب شاخه های مجزا که گیت اصطلاح branch را بر آنها نهاده.
• ثبت وضعیت موجود مخزن یا commit که همراه با هش-کد منحصر به همراه تاریخ، اطلاعات یوزر کامیت کننده، پیام کامیت، آی-دی کامیت پیشین، و کل محتوای ریپوزیتوری و نه فقط تغییرات آن است
• امکان ایجاد برچسب ( tag ) برای مشخص کردن حالت های کلیدی سیستم در روال توسعه.

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

جابجایی های غول آسا!

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

بسیاری از توسعه دهندگان نرم افزار که با ویژوال استدیو سروکار داشته اند، با سرویس "تیم فاندیشن" مایکروسافت آشنایی دارند. Team Foundation Server یا به اختصار TFS، یک نرم افزار کنترل پروژه بین اعضا بوده که با ارایه ویژگی های مناسبی در مدیریت زمان پروژه، استفاده از آن را در میان شرکت های تولید نرم افزار، بسیار مرسوم نموده بود.

مایکروسافت در سال 2013 رسما اعلام نمود که به سیستم گیت مهاجرت خواهد کرد.

آمار ها تا سال 2017، نشان میداد حدود 90 درصد از مهندسان شرکت مایکروسافت از گیت استفاده می کنند و تا آن زمان جابجایی 3.5 میلیون فایل در قالب 300 گیگابایت فضای ذخیره سازی انجام پذیرفته، که تنها بر روی ریپوزیتوری ویندوز روزانه 8500 کامیت صورت میگرفت.

اما تحقق کامل این تغییر استراتژی مایکروسافت، در سال 2018 و با خرید گیت‌هاب، بزرگترین ارائه دهنده سرویس ورژن کنترلینگِ مبتنی بر گیت، تقریبا شش سال پس از اولین اعلان آنها مبنی بر روي آوردن به git به عنوان سیستم رسمی مدیریت کد منبع که خود نیز در توسعه محصولات از آن بهره می گیرد، صورت پذیرفت.

این سرمایه گذاری هنگفت، بحث های بسیاری را در پی داشته، چرا که مایکروسافت برای سالها به سیستم متن بسته وفادار بوده و حالا با تغییر استراتژی در پروژه های بزرگی همچون NET Core. و VS Code به open-source توانسته نظر بسیاری از برنامه نویسان این حوزه را نیز به تولیدات خود جلب کند.

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

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

الگوی بکارگیری git در git-flow

برای روشن شدن چگونگی استفاده از گیت، در توسعه نرم افزار، بر مبنای gitflow ، ابتدا با هم نگاهی می اندازیم به چرخه تولید نرم افزار. شش فاز مختلف در این چرخه عبارتند از:

• 1- Requirement gathering and analysis
• 2- Design
• 3- Implementation or coding
• 4- Testing
• 5- Deployment
• 6- Maintenance

نقش مستندات در استفاده از git

داشتن چیزی به غیر از کد برنامۀ تحت توسعه در کد بیس، می تواند بسیار ارزشمند باشد. مستند سازی در تولیدات نرم افزاری یکی از اولین فاز های طراحی قلمداد می شود. مکتوباتی که با پیش بینی سناریو های مختلف، اصطلاحاً Roadmap پروژه را مشخص و روال طراحی آن را شفاف میکند. حال چه در قالب اسپرینت هایی تحت قرارداد های چارچوب چابک (َAgile) یا هر الگوی مقیاسیِ دیگری.

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

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

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

کاربرد git در کدنویسی

پس از فازهای تحلیل و طراحی، در ادامۀ چرخه توسعه نرم افزار با شروع کد نویسی در صورتی که بخواهیم از گیت استفاده کنیم باید این دایرکتوری را به عنوان محیط کاری جهت پایش ( Tracking ) به گیت بسپاریم:

λ git init

قبل از شروع بحث در مورد روال گیت و اسلوب های مختلف به کارگیری آن، باید به تفاوت تفسیر علامت "/" توسط گیت با دیگر بسیاری از سرویس دهندگان دیگر بپردازیم.

که گرچه در اشاره به محل ذخیره یک فایل توسط گیت نیز مانند بسیاری از سرویس دهندگان دیگر از بک اسلش استفاده می شود، با این حال گیت به به طور کامل با مفهوم پوشه بیگانه است. git به سبب وفاداری به سیستم فایلی یونیکس، به جای موجودیت "folder"، اطلاعات وارد شده در کد بیس را در قالب یک "object" با نام repository، و در مرحله بعد به branch هایی تقسیم میکند.

اشاره گری هوشمند به نام Branch

هر بار که در گیت از فرمان commit استفاده می کنید، آبجکتی از نوع کامیت که حاوی اسنپ شاتی از وضعیتِ stage شده است، ایجاد و ذخیره می شود. این عمل با اجرای توامان این دو کامند صورت میگیرد:

 λ git add .   &&   λ git commit -m &quotcommit message&quot 

این آبجکتِ کامیت محتوای کل کد مخزن (نه فقط تغییرات بین دو کامیت)، اطلاعات یوزری که دستور کامیت را اجرا کرده و متادیتای کامیت به همراه صفر یا بیشتر اشاره گرهایی به کامیت یا کامیت هایی که والد مستقیم این وضعیت هستند، میباشد. صفر برای اولین کامیت (وقتی هیچ ریفرنس پیشینی وجود نداشته) و چند اشاره گر برای کامیت هایی که محصول merge دو یا بیشتر branch بوده اند.

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

λ git checkout feature//befor-bang 

برنچ ها، این اشاره گر های کوچک ( lightweight) و قابل حرکت میتواند در طول فعالیت شما و با هر بار کامیت به وضعیت تازه کد و اطلاعات آن کامیت ارجاء داشته باشد. به صورت پیش فرض نام برنچ اصلی در مخزن در گیت، master است. به محض اجرای اولین کامیت اشاره گری در این برنچ به نام HEAD ایجاد میشود که به این کامیت اشاره میکند.

جریان کاری Workflow

روند توسعه نرم افزار، مانند تولید هر چیز دیگر معلول و محصور موجودیتِ زمان است. وقتی از گیت برای کنترل مخازن کد استفاده میکنید، برای منظم کردن وضعیت زمان و توانایی ارجاع به دیگر حالت ها در روند پیشرفت کار ترتیبِ اجرای دستورات گیت بر روی کد مخزن و استراکچر گروه بندی محتوای کد بیس با عنوان "جریان کاری" یا workflow شناخته میشود.

قرارداد های روال گیت ( git-flow )

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

در روال گیت (git-flow)، به عنوان یک قرارداد از سه پوشه اصلی برای مرتب نگه داشتن فایلهای پروژه استفاده میکنیم:

• feature[s]
• hotfix[es]/fixes
• release[s]

همچنین با افزودن دو دایرکتوری دیگر بنا به نیاز سیستم مورد طراحی، یکی برای نگهداری مستندات با نام docs و دیگری با نام tasks به جهت مدیریت برنامه ریزی پروژه میتوانیم قرارداد ها و مستندات agile را نیز مرکزیت دهیم.

اسلوب های برنچینگ در gitflow

سیستم مدیریت سورس کد گیت ( Git revision control )، به تغییراتی که در طول زمان بر روی کد برنامه و هر گونه محتوای تایپی دیگری صورت میگیرد، نظارت دارد. این موضوع دست شما را در انتخاب استراتژیِ تقسیم بندی فضای کاری و محل نگهداری کد های هر قسمت، بر اساس نیاز های پروژۀ در حال طراحی، باز میگذارد.

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

اسلوب (BPMP (Branch-Push-Merge-Prune

این اسلوبِ به کارگیری گیت، مدلی ضد پوشه است. برای پروژه های کوچک و متوسط کاربرد داشته و با روال بسیار ساده ای قابل پیاده سازی است:

• ایجاد برنچ
• پوش
• ایجاد پول ریکوئست
• حذف برنچ

(چه به صورت دستی با اجرای دستورات git fetch prune، وچه اتوماتیک این عملیات حذف صورت پذیرد)

اسلوب ماژول-محور (Module-based)

این اسلوب در پروژه های بزرگ، با فیچر های زیاد کاربرد دارد، در این مدل برنچ ها را همنام با ماژولها در نظر می گیریم. (به عکس موجود در عنوان مراجعه شود)

اسلوب ورژن-محور (version-based)

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

λ git branch | grep -e "vX.X/" | xargs git branch -D

اسلوب تیکت محور (Ticket-based)

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

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

قانون طلاییِ Commit

یکی از مهمترین قرارداد های مشترک و اولیه در روال توسعه نرم افزار با استفاده از گیت میگوید:

هر چیزی که در برنچ master قرار گرفته باید قابل اجرا و بدون باگ باشد، در وضعیت deployable.

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

دستورات git VS gitflow

حال بر اساس مدلی که برای توسعه و مدیریت کد بیس اتخاذ نموده ایم، قادریم دستورات تعمیم گیت_فلو و یا مجموعه دستوراتی که در صورت عدم استفاده از آن و بکارگیری گیت به تنهایی باید برای رسیدن به همان نتیجه اجرا شوند، را یک به یک اجرا و نتیجه را با git log --graph مورد بررسی قرار دهیم.

Initialize

gitflow:λ git flow init 

git:λ git init  

λ git commit --allow-empty -m &quotInitial commit&quot 

λ git checkout -b develop master

• Connect to the remote repository

gitflow: N/A

git:λ git remote add origin git@github.com:MYACCOUNT/MYREPO

Features

• Create a feature branch

gitflow: λ git flow feature start MYFEATURE

git:λ git checkout -b feature/MYFEATURE develop

• Share a feature branch

gitflow: λ git flow feature publish MYFEATURE 

git:λ git heckout feature/MYFEATURE λ git push origin feature/MYFEATURE

• Get latest for a feature branch

gitflow:λ git flow feature pull origin MYFEATURE 

git:λ git checkout feature/MYFEATURE λ git pull --rebase origin feature/MYFEATURE

• Finalize a feature branch

gitflow: λ git flow feature finish MYFEATURE 

git:λ git checkout develop 

λ git merge --no-ff feature/MYFEATURE 

λ git branch -d feature/MYFEATURE

• Push the merged feature branch

gitflow: N/A

git:λ git push origin develop λ git push origin :feature/MYFEATURE (if pushed)

Releases

• Create a release branch

gitflow: λ git flow release start 1.2.0

git:λ git checkout -b release/1.2.0 develop

• Share a release branch

gitflow:λ git flow release publish 1.2.0

git:λ git checkout release/1.2.0 git push origin release/1.2.0

• Get latest for a release branch

gitflow: N/A

git:λ git checkout release/1.2.0 λ git pull --rebase origin release/1.2.0

• Finalize a release branch

gitflow: λ git flow release finish 1.2.0 

git:λ git checkout master λ git merge --no-ff release/1.2.0 λ git tag -a 1.2.0 λ git checkout develop λ git merge --no-ff release/1.2.0 λ git branch -d release/1.2.0

• Push the merged feature branch

gitflow: N/A

git:λ git push origin master λ git push origin develop λ git push origin --tags λ git push origin :release/1.2.0 (if pushed)

Hotfixes

• Create a hotfix branch

gitflow: λ git flow hotfix start 1.2.1 [commit]

git:λ git checkout -b hotfix/1.2.1 [commit]

• Finalize a hotfix branch

gitflow: λ git flow hotfix finish 1.2.1 

git:λ git checkout master λ git merge --no-ff hotfix/1.2.1 λ git tag -a 1.2.1 λ git checkout develop λ git merge --no-ff hotfix/1.2.1 λ git branch -d hotfix/1.2.1

• Push the merged hotfix branch

gitflow: N/A

git:λ git push origin master λ git push origin develop λ git push origin --tags λ git push origin :hotfix/1.2.1 (if pushed)

توزیع شده، مرکزیت یافته جدید است!

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

یادگیری و تسلط بر گیت با استفاده از تعمیمهای گیت_فلو و دستورات آن که با نصب به گیت اضافه میشوند.

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

ابزار هایی برای استفاده موثرتر از گیت

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

گرچه تعمیم هایی همراه با رابط گرافیکی برای کار با گیت بصورت محدود امکاناتی را عرضه کرده اند، با این وجود کامند پرامپت تنها جایی است که می توانیم از تمام امکانات گیت استفاده نماییم.

مستند سازی خود را ایجاد کنیم؟

داشتن آشنایی با فایلهای ایجاد شده تحت استاندارد نشانه گذاری MarkDown برای تدوین و بکارگیری مستندات لازم است. این زبان نشانه گذاری در سال 2004 با هدف ممکن ساختن ایجاد محتوای مناسب برای مطالعه در قالب تنها متن، به همراه علایمی برای مشخص کردن نوع نمایش ایجاد شده است. پارسر مارک دان با توانایی درک و تفسیر تگ های HTML قابلیت کاربست توامان این دو زبان نشانه گذاری را داشته، میتواند شما را در تنظیم اسناد مرتبط با داکیومنت، از هر ابزار دیگری بی نیاز کند.

نرم افزار رایگان MarkDown، که برای تسهیل ایجاد فرمت مورد نظر با رابط کاربری گرافیکی بر اساس قواعد مارک داون ارائه شده، مشهور ترین نرم افزار مرتبط با ایجاد فایل های md میباشد که در صورت تمایل به نصب آن، در صورتی که از سیستم عامل ویندوز 10 استفاده می کنید، احتمال دارد رویه نصب از شما بخواهد، کیت توسعه نرم افزار شرکت آوسومیوم "Awesomium 1.6.6 SDK" را نیز بر روی سیستم خود نصب کنید. گرچه در صورت آشنایی با سینتکسِ نشانه های مارک داون نیازی به ادیتور مخصوصی نمی باشد، و هر ویرایشگری می تواند مورد استفاده قرار گیرد. همین کافیست که پسوند فایل را به md. تغییر دهیم. همچنین افزونه های متعدد، جهت پشتیبانی و نمایش خروجی این پسوند برای ویژوال استودیو کُد در دسترس هستند.

کنسول خط فرمان Cmder

نه cmd ویندوز و نه git-bash، کنسول پیشنهادیِ خود گیت هیچ یک مطلوبیت کار با Cmder را برای من به همراه نداشته اند. این کنسول شبیه سازی شده تحت یک پروژه اُپن سورس ایجاد، و با پشتیبانی از گیت و ارایه اطلاعاتی مناسبی مانند نام ریپوزیتوری و برنچ فعال در اعلان خط فرمان و تغییرات رنگ نام ریپو در صورتی که شامل تغییرات کامیت نشده باشد، امکانات خوبی را برای کار با گیت فراهم آورد.

استفاده از آن را به شما هم پیشنهاد میکنم. ضمنا علامت λدر ابتدای دستوراتی که در قسمت مقایسه مابین کامندهای گیت و تعمیم گیت فلو مشاهده میکنید لوگوی Cmder است که مانند علامت $ در کامند پرامپت لینوکس، برای تمیز دادن خط جاری و وضعیتهای نمایش و ویرایش با حالت اجرای دستورات استفاده شده است.

پکیج گیت_فلو git-flow

به عنوان یکی از سه روال مشهور برنچینگ git-flow با پیروی از جریان کاری استاندارد گیت مجموعه دستوراتی را در قالب پکیج قابل نصب ارائه می کند که همراه با گیت میتواند به روال منظم تری در مدیریت مخازن کد منجر شود. این استاندارد تنها با در نظر گرفتن چند قرارداد، توانسته به تسهیل روند ثبت تغییرات در ریپوزیتوری کمک نماید. با نصب این بسته و استفاده از آن با دستوراتی که پیشتر بیان کردیم میتوانید پروسه یادگیریِ استفاده کاربردی از گیت را به ساده ترین شکل ممکن شروع نماییم.

جمع بندی

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

ناگفته نماند که گیت خود بهترین راهنماست، با اجرای هر دستور در صورت هر نوع مغایرت، گیت به صورت واضحی در پیام های خود شما را برای ادامه روند کار راهنمایی می کند. gitflow تنها یک مدل انتزاعی از چگونگی استفاده از git می باشد.git-flow با ضریب نفوذ زیادی در پروژه های open source به کار گرفته شده، با این حال این خود git است که با خصوصیت های منحصر بفرد خود در نهایت راه حل مناسبی برای مدیریت مخازن کد پروژه های نرم افزاری ارائه میدهد.

این مقاله حاصل جمع بندی بخش کوچکی از مواردی است که در مواجهه با سناریو های متفاوتِ استفاده از git گردآوری و در قالب یک repository با نام docs جهت استفاده و مشارکت برنامه نویسان و علاقه مندان در تکمیل و تدوین آن در اکانت github کامیونیتی ری_اکت ایران انتشار یافته است.