<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Nima Bastani</title>
        <link>https://virgool.io/feed/@nima.bastani</link>
        <description>برنامه نویسِ ساحلِ فرانت.</description>
        <language>fa</language>
        <pubDate>2026-07-07 12:57:54</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/30856/avatar/Sdlh2h.png?height=120&amp;width=120</url>
            <title>Nima Bastani</title>
            <link>https://virgool.io/@nima.bastani</link>
        </image>

                    <item>
                <title>پیشنهاد ساده در حل معضل تکدی گری</title>
                <link>https://virgool.io/@nima.bastani/%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF-%D8%B3%D8%A7%D8%AF%D9%87-%D8%AF%D8%B1-%D8%AD%D9%84-%D9%85%D8%B9%D8%B6%D9%84-%D8%AA%DA%A9%D8%AF%DB%8C-%DA%AF%D8%B1%DB%8C-ykzjib5kovsv</link>
                <description>خیلی کوچک بودم، با مادرم که قدم می زدیم گاهی پیش می آمد که به تکدی گری کمک می کرد. انگار که برخی را می شناخت. در کودکی ام سکه های 5 تومانی قدرتی باور نکردنی داشتند، تکدی گران اندک بودند و راضی به رزق.تقریبا 10 سال گذشت، روزی در منطقه سعادت آباد پشت چراغی گدایی نزدیک شد. من یک سکه شاید 25 تومانی در دست داشتم و مشغول بازی باهاش بودم، از پی نگاه پسر نسبتا جوانی که کنار ماشین منتظر گرفتن صدقه ای از دست یکی از سرنشینان بود خواستم سکه رو بهش بدم. در کمال تعجب من، گدا با حالتی که انگار بهش برخورده باشه، &quot;این چیه ای&quot; زمزمه کرد و از کنار خودرو دور شد.این سرگذشت رو براتون تعریف میکنم، تا به عنوان راه حلی برای معضل تکدی گری در کلان شهر ها تبدیلش کنیم، باور کنید چیزی که به دستشون می رسونیم خیلی زیاد هست. و این موضوع سبب شده این تعداد کثیر از زن و مرد و کودک به تکدی گری بپردازند. اگر شخصی کارش به گدایی در خیابان رسیده، احتمالا محتاج به نان شب است، و این نان و پنیر با دریافت 200 تومن از هر شخص در روز هم فراهم خواهد شد چه بسا بیشتر.به جای سعی در عدم کمک به تکدی گران، که با روحیه انسان دوستی اون هم در نوع شرقی و ایرانیش خیلی همخونی نداره، بیایم الگوی ساده تری رو تغییر بدهیم. تکدی گران را با دستمزد متناسب با عمل خود، با پرداخت مبالغ کم می تونیم به دو دسته تکدی گر نما و نیازمند واقعی تقسیم کنیم. با در پیش گرفتن این رویه فقط کسانی به گدایی ادامه خواهد داد که واقعا نیازمند این پول هستند. نه آن تکدی گری که دستی به شیشه خودروی شما می کشد، اسپندی می گرداند، فالی در دست می گیرد، و نه هیچکس دیگر نمی تواند شما را قضاوت کند که چیزی کمتر ار حق به گدایی داده اید. به جای هزاری و پنجی و دهی دادن به یک تکدی گر سکه های حداکثر 200 تومانی استفاده کنیم، یک حساب و کتاب ساده نشون میده او در پایان روز درآمد بیشتری از بسیاری انسان های شریف، تحت فعالیت در مشاغل غیر کاذب می تواند داشته باشد اگر حتی از هر نفر 500 تومان هم دریافت کنه. امیدوارم اگر به نظرتون این موضوع میتونه به تمیز تر شدن و امن تر شدن شهر هامون کمک کنه به هر نوعی در ترویج اون همراهی کنید.پی نوشت : در این میان خدمات درمانی و هزینه های مربوط به آن به جهت در دسترس نبودن خدمات رایگان پزشکی همانند بسیاری کشور های جهان اول شمار تکدی گرانی را که با این معضل دست و پنجه نرم می کنند را برای مدتی با مشکل مواجه خواهد کرد، حال آنکه همکاری منسجم نهاد های خیریه به جهت رسیدگی و کمک رسانی به افراد با پرونده پزشکی می توانند بسیاری از نیازمندان واقعی به خدمات درمانی را در برآوردن شرایط یک زندگی سالم یاری نمایند.</description>
                <category>Nima Bastani</category>
                <author>Nima Bastani</author>
                <pubDate>Thu, 12 Sep 2019 01:45:52 +0430</pubDate>
            </item>
                    <item>
                <title>زیر پوستۀ git</title>
                <link>https://virgool.io/@nima.bastani/%D8%B2%DB%8C%D8%B1-%D9%BE%D9%88%D8%B3%D8%AA%DB%80-%DA%AF%DB%8C%D8%AA-awbdwc6d6aos</link>
                <description>در این مقاله سعی دارم، به نقش گیت (git)؛ راهکار مدیریت محتوای توزیع شده ای، که به محض پیدایش توانست نظر کاربران و برنامه نویسان بسیاری را به خود جلب و در اشاعه فرهنگ اپن سورس نقش کلیدی را عهده دار شود بپردازم. با این امید که خواندن این مطلب بتونه به روشن تر شدن ماهیت درونی &quot;روال گیت&quot; و بهره مندی از توان ایجاد داکیومنتری و کد بیس منسجم تری در توسعه پروژه هاتون، و در نهایت به تبحر لازم در استفاده از گیت به منظور پیوستن به میلیون ها برنامه نویس اجتماع اُپن سورس منجر بشه.   لطفا در نظر داشته باشید، که من قصد آموزش کامند های گیت را ندارم، بلکه در پی ایجاد ذهنیت روشنی در رابطه با چگونگی به کارگیری گیت، با هدف تسهیل روند تولید نرم افزار، و بالطبع روال مستند سازی، تست و پشتیبانی یک محصول هستم. با این حال در بخشی از مقاله تمامی دستورات gitflow و مشابه آنها اگر، تنها از گیت برای مدیریت همان مخزن استفاده می شد را جهت شفاف سازی مطالب گنجانده ام.سخنی با برنامه نویسان متاثر از فرهنگ متن باز و در پی استقبال شگفت انگیز جامعه برنامه نویسان از این ساختارِ اجتماعی، که با محوریت توسعه و پیشرفت برای بشر، به دور از منازعات حاکم بر دنیای &quot;سخت&quot; پدید آمده است، جهان نرم افزار این روزها در دوران باشکوهی از حیات خود به سر می برد. نبرد کمپانی های بزرگ تولیدات نرم افزاری، هر روز کمرنگ و کمرنگ تر، و جدال ها، جای خود را به همکاری و تعامل برای نیل به شکوفایی روز افزون تکنولوژی داده است. در این میان  سهم برنامه نویسان ایرانی همچون گذشته از این تجارت، و از آن مهم تر، این جریان همراهی جهانی در قالب نام اُپن سورس (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  و به عنوان یکی دیگر از پروژه های اُپن سورس تحت نظارت لینوکس، که خود به عنوان اولین نرم افزار متن باز تاریخ، در حال رشد بود، شروع شد. این برنامه در پی نیاز برنامه نویسانی پدید آمد که از نقاط مختلف جهان در کد نویسی و طراحی پروژه لینوکس مشارکت داشتند. بستری که تا آن زمان عملیات مدیریت مخازن کد آنها را بر عهده داشت، به دلایلی از ادامه سرویس رسانی به آنها شانه خالی کرده و گزینه مناسبی که جوابگوی حجم تراکنشهای آنها باشد وجود نداشت. گیت تنها پس از دو ماه  به مرحله استفاده رسیده و به عنوان نرم افزار کنترل نسخه رسمی برای گسترش لینوکس معرفی گردید.گیت با مهارت باور نکردنی در درک حروف و هر گونه محتوای تایپی دیگر، سالهاست موزیسین ها را در نوشتن آهنگ، مؤلفان و ناشران را در ترجمه‌ و تدوین کتاب و مجله و روزنامه، و از همه مهمتر توسعه دهندگان نرم افزار را در پیشبرد پروژه های نرم افزاری بزرگ و کوچک، به صورت مشارکتی، یاری نموده است.توانایی گیت در مدیریت کدهای توزیع شده مابین برنامه نویسان متعدد به صورت &quot;local&quot; و مرکزیت دادن به نسخه اصلی کد در فضای &quot;remote&quot;  با ایجاد قوانین ساده ای برای یکسان سازی نسخه ها توانسته به معنای حقیقی کلمه، مصداقی از یک سیستم &quot;توزیع شده&quot; باشد. گیت با توانایی ایجاد نسخه های کم حجم و متعدد از وضعیت های مختلف محتویات فایلهای روی یه مخزن،  به عنوان یک ابزار قدرتمند، توانسته است عنوان محبوب ترین نرم افزار ورژن کنترل جهان را از آن خود کند.  امکان کار به صورت متمرکز بر روی مخازن کد که گیت آنها را repository میخواند. نگهداری حالت دقیق محتویات مخزن در قالب شاخه های مجزا که گیت اصطلاح branch را بر آنها نهاده.ثبت وضعیت موجود مخزن یا commit که همراه با هش-کد منحصر به همراه تاریخ، اطلاعات یوزر کامیت کننده، پیام کامیت، آی-دی کامیت پیشین، و کل محتوای ریپوزیتوری و نه فقط تغییرات آن است امکان ایجاد برچسب ( tag ) برای مشخص کردن حالت های کلیدی سیستم در روال توسعه.اینها چند مورد از مهمترین ویژگی ها و امکاناتی است،که گیت برای کاربست برنامه نویسان، جهت نوشتن برنامه های متعدد با کمترین اتلاف زمان و مصائب، فراهم آورده. حتی در صورتی که در حال کار بر روی یک پروژه بصورت انفرادی هستید، یعنی به قسمتی از کاربردهای برجسته گیت، یعنی کار گروهی بر روی یک کد منبع، نیازی ندارید، باز هم گیت امکانات بسیار دیگری را عرضه داشته که به خروجی مطلوب تر کار شما منجر خواهد شد.جابجایی های غول آسا!چه چیز گیت را انقدر خاص کرده است؟ بیایید سناریویی که به یکی از بحث برانگیزترین رویداد های دنیای نرم افزار در سالهای اخیر بدل شده، یعنی تغییر رویکرد شرکت مایکروسافت در سیاست هایش، آن هم از زاویۀ شناخت بهتر گیت نگاهی کنیم.بسیاری از توسعه دهندگان نرم افزار که با ویژوال استدیو سروکار داشته اند، با سرویس &quot;تیم فاندیشن&quot; مایکروسافت آشنایی دارند. 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 analysis2- Design3- Implementation or coding4- Testing5- Deployment6- Maintenanceنقش مستندات در استفاده از gitداشتن چیزی به غیر از کد برنامۀ تحت توسعه در کد بیس، می تواند بسیار ارزشمند باشد. مستند سازی در تولیدات نرم افزاری یکی از اولین فاز های طراحی قلمداد می شود. مکتوباتی که با پیش بینی سناریو های مختلف، اصطلاحاً Roadmap پروژه را مشخص و روال طراحی آن را شفاف میکند. حال چه در قالب اسپرینت هایی تحت قرارداد های چارچوب چابک (َAgile) یا هر الگوی مقیاسیِ دیگری.گیت از فایل هایی با فرمت MD برای نگهداری و ثبت مستندات پشتیبانی میکند. در روال گیت، تغییرات و فیچر های هر رلیز و در کل هر نوع اطلاعات مرتبط با سیستم مورد طراحی در قالب فایل هایی با نام های مشترک و قراردادی، مانند CHANGELOG، README به جهت سهولت استفاده و مشارکت دیگران در ساختار ریپوزیتوری ایجاد و در طول زمان همراه با روال توسعه تکمیل می شوند.هر بار که صفحه اصلی یک ریپوزیتوری را در گیت هاب، گیت لب، و دیگر سرویس های مبتنی بر گیت، مشاهده می کنید، اطلاعات موجود در فایل README.MD موجود در شاخه اصلی مخزن، در قسمتی از صفحه به نمایش در میاید. فایلی که در هر پروژه گیت به عنوان یک قرارداد ایجاد می شود تا در طی روند طراحی، مطالبی در رابطه با قابلیت های برنامه و همینطور نحوه راه اندازی آن، در آن ثبت گردد.این مستندات به همراه کدهای نوشته شده در طی پروسه دولوپ، با چند دستور ساده و رعایت چند قرارداد در قالب &quot;روال طراحی&quot; به ماشین مفسر و تحلیلگر متن گیت تزریق میشود و قابلیت های بسیاری را برای کنترل کد مخازن به افراد تیم طراحی توفیض می نمایند.کاربرد git در کدنویسیپس از فازهای تحلیل و طراحی، در ادامۀ چرخه توسعه نرم افزار با شروع کد نویسی در صورتی که بخواهیم از گیت استفاده کنیم باید این دایرکتوری را به عنوان محیط کاری جهت پایش ( Tracking ) به گیت بسپاریم:λ git initقبل از شروع بحث در مورد روال گیت و اسلوب های مختلف به کارگیری آن، باید به تفاوت تفسیر علامت &quot;/&quot; توسط گیت با دیگر بسیاری از سرویس دهندگان دیگر بپردازیم.  که گرچه در اشاره به محل ذخیره یک فایل توسط گیت نیز مانند بسیاری از سرویس دهندگان دیگر  از بک اسلش استفاده می شود، با این حال گیت به به طور کامل با مفهوم پوشه بیگانه است. git به سبب وفاداری به سیستم فایلی یونیکس، به جای موجودیت &quot;folder&quot;، اطلاعات وارد شده در کد بیس را در قالب  یک &quot;object&quot; با نام repository، و در مرحله بعد به branch هایی تقسیم میکند.اشاره گری هوشمند به نام Branchهر بار که در گیت از فرمان commit  استفاده می کنید، آبجکتی از نوع  کامیت که حاوی اسنپ شاتی از وضعیتِ stage شده است، ایجاد و ذخیره می شود. این عمل با اجرای توامان این دو کامند صورت میگیرد: λ git add .   &amp;&amp;   λ git commit -m &amp;quotcommit message&amp;quot  این آبجکتِ کامیت محتوای کل کد مخزن (نه فقط تغییرات بین دو کامیت)، اطلاعات یوزری که دستور کامیت را اجرا کرده و متادیتای کامیت به همراه صفر یا بیشتر اشاره گرهایی به کامیت یا کامیت هایی که والد مستقیم این وضعیت هستند، میباشد. صفر برای اولین کامیت (وقتی هیچ ریفرنس پیشینی وجود نداشته) و چند اشاره گر برای کامیت هایی که محصول merge دو یا بیشتر branch بوده اند.برنچ ها دقیقا همین اشاره گر ها هستند. آبجکت هایی که با دسترسی به اطلاعات کامیت هایی که به آنها مرتبط شده اند، و تفسیر متادیتای این وضعیت ها، میتوانند محتویات تمام فایل ها و پوشه های یک ریپوزیتوری را به صورت پویا تغییر داده، مثلا کد و چینش دایرکتوری های شما را به قبل از وضعیت بروز یک باگ بازگردانند. البته این در صورتی محقق است که شما به درستی از لااقل یکی از متدهای اجرای دستورات git یا gitflow در طول کدنویسی استفاده کرده باشید و مثلا قراردادِ کامیت به ازای هر تغییر را رعایت کرده باشید.λ git checkout feature//befor-bang برنچ ها، این اشاره گر های  کوچک ( lightweight) و قابل حرکت میتواند در طول فعالیت شما و با هر بار کامیت به وضعیت تازه کد و اطلاعات آن کامیت ارجاء داشته باشد. به صورت پیش فرض نام برنچ اصلی در مخزن در گیت، master است. به محض اجرای اولین کامیت اشاره گری در این برنچ به نام HEAD ایجاد میشود که به این کامیت اشاره میکند.جریان کاری Workflowروند توسعه نرم افزار، مانند تولید هر چیز دیگر معلول و محصور موجودیتِ زمان است. وقتی از گیت برای کنترل مخازن کد استفاده میکنید، برای منظم کردن وضعیت زمان و توانایی ارجاع به دیگر حالت ها در روند پیشرفت کار ترتیبِ اجرای دستورات گیت بر روی کد مخزن و استراکچر گروه بندی محتوای کد بیس با عنوان  &quot;جریان کاری&quot; یا workflow شناخته میشود.قرارداد های روال گیت ( git-flow )  گیت_فلو توسط  Vincent Driessen در قالب چند اسلوب متفاوت به عنوان استراتژی های مشخصی که در تعداد بی شماری پروژه به کار رفته اند و کاربرد آنها در توانمندتر کردن تیم توسعه، در غلبه بر چالشهای طراحی نرم افزار مسجل گشته معرفی شده است. این تعمیم در پی ساده سازی و در عین حال استاندارد کردن روند کار با گیت در طول جریان کاری پروسۀ توسعه یک نرم افزار می باشد.در روال گیت (git-flow)، به عنوان یک قرارداد از سه پوشه اصلی برای مرتب نگه داشتن فایلهای پروژه استفاده میکنیم:feature[s]hotfix[es]/fixesrelease[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 &quot;vX.X/&quot; | xargs git branch -Dاسلوب تیکت محور (Ticket-based)این استایل در پروژه های گروهی که زبان مشترکی بین تیمی  که بر پروژه فعالیت دارند در جریان است، زبانی که در قالب tickets  ،   issues   یا هر چیزی که تیم آن را  قلمداد میکند به حل و فصل موضوعات و اصولا روال طراحی می پردازند.استایل های متفاوتِ روال گیت، عمدتا به تفاوت در اولویت های پروژه و نحوه چینش و گروه بندی محتویات آن دلالت دارند و بسته به نیاز، قابلیت ترکیب شدن با هم را نیز دارند.قانون طلاییِ Commitیکی از مهمترین قرارداد های مشترک و اولیه در روال توسعه نرم افزار با استفاده از گیت میگوید:هر چیزی که در برنچ master قرار گرفته باید قابل اجرا و بدون باگ باشد، در وضعیت deployable. این موضوع بر این اصل تکیه دارد که اگر کدی مرحله تست را نگذرانده برنچ مستر جای آن نیست، چون نهایتا این نسخه تا چند ساعت دیگر قرار است بر روی سرور قرار گیرد (در مراحلی که نرم افزار پس از ریلیز همچنان در حال دولوپ است و کد روی سرور که در حال سرویس رسانی است در فواصلی به روز میشود). دستورات git VS gitflowحال بر اساس مدلی که برای توسعه و مدیریت کد بیس  اتخاذ نموده ایم، قادریم دستورات تعمیم گیت_فلو و یا مجموعه دستوراتی که در صورت عدم استفاده از آن و بکارگیری گیت به تنهایی باید برای رسیدن به همان نتیجه اجرا شوند، را یک به یک اجرا و نتیجه را با git log --graph مورد بررسی قرار دهیم. Initializegitflow:λ git flow init git:λ git init  λ git commit --allow-empty -m &amp;quotInitial commit&amp;quot λ git checkout -b develop masterConnect to the remote repositorygitflow: N/Agit:λ git remote add origin git@github.com:MYACCOUNT/MYREPOFeaturesCreate a feature branchgitflow: λ git flow feature start MYFEATUREgit:λ git checkout -b feature/MYFEATURE developShare a feature branchgitflow: λ git flow feature publish MYFEATURE git:λ git heckout feature/MYFEATURE λ git push origin feature/MYFEATUREGet latest for a feature branchgitflow:λ git flow feature pull origin MYFEATURE git:λ git checkout feature/MYFEATURE λ git pull --rebase origin feature/MYFEATUREFinalize a feature branchgitflow: λ git flow feature finish MYFEATURE git:λ git checkout develop λ git merge --no-ff feature/MYFEATURE λ git branch -d feature/MYFEATUREPush the merged feature branchgitflow: N/Agit:λ git push origin develop λ git push origin :feature/MYFEATURE (if pushed)ReleasesCreate a release branchgitflow: λ git flow release start 1.2.0git:λ git checkout -b release/1.2.0 developShare a release branchgitflow:λ git flow release publish 1.2.0git:λ git checkout release/1.2.0 git push origin release/1.2.0Get latest for a release branchgitflow: N/Agit:λ git checkout release/1.2.0 λ git pull --rebase origin release/1.2.0Finalize a release branchgitflow: λ 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.0Push the merged feature branchgitflow: N/Agit:λ git push origin master λ git push origin develop λ git push origin --tags λ git push origin :release/1.2.0 (if pushed)HotfixesCreate a hotfix branchgitflow: λ git flow hotfix start 1.2.1 [commit]git:λ git checkout -b hotfix/1.2.1 [commit]Finalize a hotfix branchgitflow: λ 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.1Push the merged hotfix branchgitflow: N/Agit:λ 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 استفاده می کنید، احتمال دارد رویه نصب از شما بخواهد، کیت توسعه نرم افزار شرکت آوسومیوم &quot;Awesomium 1.6.6 SDK&quot; را نیز بر روی سیستم خود نصب کنید. گرچه در صورت آشنایی با سینتکسِ نشانه های مارک داون نیازی به ادیتور مخصوصی نمی باشد، و هر ویرایشگری می تواند مورد استفاده قرار گیرد. همین کافیست که پسوند فایل را به md. تغییر دهیم. همچنین افزونه های متعدد، جهت پشتیبانی و نمایش خروجی این پسوند برای ویژوال استودیو کُد در دسترس هستند. کنسول خط فرمان Cmderنه cmd ویندوز و نه git-bash، کنسول پیشنهادیِ خود گیت هیچ یک مطلوبیت کار با Cmder را برای من به همراه نداشته اند. این کنسول شبیه سازی شده تحت یک پروژه اُپن سورس ایجاد، و با پشتیبانی از گیت و ارایه اطلاعاتی مناسبی مانند نام ریپوزیتوری و برنچ فعال در اعلان خط فرمان و تغییرات رنگ نام ریپو در صورتی که شامل تغییرات کامیت نشده باشد، امکانات خوبی را برای کار با گیت فراهم آورد.استفاده از آن را به شما هم پیشنهاد میکنم. ضمنا علامت λدر ابتدای دستوراتی که در قسمت مقایسه مابین کامندهای گیت و تعمیم گیت فلو مشاهده میکنید لوگوی Cmder است که مانند علامت $ در کامند پرامپت لینوکس، برای تمیز دادن خط جاری و وضعیتهای نمایش و ویرایش با حالت اجرای دستورات استفاده شده است.پکیج گیت_فلو git-flowبه عنوان یکی از سه روال مشهور برنچینگ git-flow با پیروی از جریان کاری استاندارد گیت مجموعه دستوراتی را در قالب پکیج قابل نصب ارائه می کند که همراه با گیت میتواند به روال منظم تری در مدیریت مخازن کد منجر شود. این استاندارد تنها با در نظر گرفتن چند قرارداد، توانسته به تسهیل روند ثبت تغییرات در ریپوزیتوری کمک نماید. با نصب این بسته و استفاده از آن با دستوراتی که پیشتر بیان کردیم میتوانید پروسه یادگیریِ استفاده کاربردی از گیت را به ساده ترین شکل ممکن شروع نماییم.جمع بندیدر این مطلب سعی نمودم رئوس کلی تر موضوع مدیریت کد منبع را مطرح نمایم، و با معرفی gitflow راه ساده تری را برای شروع یادگیری و استفاده از گیت حضورتان معرفی کنم. امید که مؤثر افتد. گرچه مطالب بسیاری در رابطه با چگونگی کار با گیت در دسترس است و در طول نگارش این مطلب نیز به چند منبع فارسی مناسب برخورد کردم، با این حال به سبب تمرکز بیشتر به جنبه های عملیِ استفاده از گیت، و گستردگی حوزه دستورات و توانایی های گیت، متاسفانه در نهایت از پیچیدگی موضوع برای مخاطب به مقدار لازم کاسته نشده و رغبت در بکارگیری این ابزار قدرتمند آنگونه که باید بوجود نیامده است. ناگفته نماند که گیت خود بهترین راهنماست، با اجرای هر دستور در صورت هر نوع مغایرت، گیت به صورت واضحی در پیام های خود شما را برای ادامه روند کار راهنمایی می کند. gitflow تنها یک مدل انتزاعی از چگونگی استفاده از git می باشد.git-flow  با ضریب نفوذ زیادی در پروژه های open source  به کار گرفته شده، با این حال این خود git است که با خصوصیت های منحصر بفرد خود در نهایت راه حل مناسبی برای مدیریت مخازن کد پروژه های نرم افزاری ارائه میدهد.این مقاله حاصل جمع بندی بخش کوچکی از مواردی است که در مواجهه با سناریو های متفاوتِ استفاده از git گردآوری و در قالب یک repository با نام docs جهت استفاده و مشارکت برنامه نویسان و علاقه مندان در تکمیل و تدوین آن در اکانت github کامیونیتی ری_اکت ایران  انتشار یافته است.</description>
                <category>Nima Bastani</category>
                <author>Nima Bastani</author>
                <pubDate>Fri, 03 May 2019 21:10:10 +0430</pubDate>
            </item>
            </channel>
</rss>