قسمت اول:
استفاده از Git، نه تنها برای هر یک اعضای یک تیم چابک، بلکه برای تجارت چابک نیز، مزایایی دارد. لیست زیر، مواردی است که می‌خواهیم در این بخش به آن‌ها بپردازیم:
• Git برای توسعه‌دهندگان
• Git برای بازاریابی
تغییر از سیستم کنترل نسخه متمرکز به Git، نحوه ایجاد نرم‌افزار توسط تیم توسعه‌دهنده شما را تغییر می‌دهد. همچنین اگر شرکتی هستید که برای استفاده از برنامه‌های مهم خود به نرم‌افزار خود اعتماد می‌کنید، تغییر روند کار توسعه شما، بر کل کسب‌وکار شما تأثیر می‌گذارد.
در این مقاله، در مورد چگونگی تأثیر مزاياى Git بر جنبه هاى مختلف سازمان شما، از تیم توسعه شما گرفته تا تیم بازاریابی و موارد دیگر، بحث خواهیم کرد. در پایان این مقاله، باید مشخص شود که Git فقط برای توسعه نرم‌افزار چابک نیست بلکه برای تجارت چابک نیز هست.
Git برای توسعه‌دهندگان :
گردش کار شاخه Feature
یکی از بزرگ‌ترین مزایای Git قابلیت شاخه بندی آن است. برخلاف سیستم‌های کنترل نسخه متمرکز، شاخه های Git ارزان هستند و Merge آن‌ها آسان است. این کار، گردش کار شاخه Feature را که در بین بسیاری از کاربران Git محبوب است، آسان می‌کند.
شاخه های Feature، یک محیط جداگانه برای هر تغییر در کد فراهم می‌کنند. وقتی یک توسعه‌دهنده بخواهد روی چیزی کار کند - مهم نیست چه بزرگ و چه کوچک – شاخه جدیدی ایجاد می‌کند. این تضمین می‌کند که شاخه Master همیشه دارای کد محصول با کیفیت، است.
استفاده از شاخه های Feature نه تنها از ویرایش مستقیم کد محصول، مطمئن تر است، بلکه مزایای سازمانی را نیز به همراه دارد. آن‌ها به شما این امکان را می‌دهند که کارهای توسعه را با همان Backlog چابک خود نشان دهید. برای مثال، ممکن است سیاستی را اجرا کنید که هر تیکت Jira در شاخه Feature خاص خود آدرس دهی شود.
توسعه توزیع شده
درSVN ، هر توسعه‌دهنده یک کپی کاری (نسخه فعال یا Working Copy) دریافت می‌کند که به یک مخزن مرکزی واحد برمی‌گردد. با این حال،Git یک سیستم کنترل نسخه توزیع شده است. به جای کپی کار، هر توسعه‌دهنده مخزن محلی خود را با یک تاریخچه کامل از Commit ها دریافت می‌کند.
داشتن یک تاریخچه محلی کامل، Git را سریع می‌کند. زیرا این بدان معناست که برای ایجاد Commit ها، بازرسی نسخه‌های قبلی یک فایل یا دریافت تفاوت بین Commit ها، به اتصال شبکه نیازی ندارید.
توسعه توزیع شده، مقیاس بندی تیم مهندسی شما را آسان می‌کند. اگر کسی شاخه محصول خود را در SVN نقض کند، سایر توسعه‌دهندگان نمی‌توانند تغییرات خود را بررسی کنند تا زمانی که مشکل برطرف شود. با Git، این نوع مسدود کردن وجود ندارد. همه می‌توانند به کار خود در مخازن محلی خود ادامه دهند.
همچنین مشابه شاخه های Feature، توسعه توزیع شده فضای مطمئن تری ایجاد می‌کند. حتی اگر یک توسعه‌دهنده مخزن خود را از بین ببرد، می‌تواند به سادگی یک مورد دیگر را Clone کرده و از نو شروع کند.
درخواست های Pull
بسیاری از ابزارهای مدیریت کد مرجع مانند Bitbucket عملکرد Git اصلی را با درخواست Pull افزایش می‌دهند. درخواست Pull راهی است که می‌توانید از توسعه‌دهنده دیگری بخواهید یکی از شاخه های شما را در مخزن خود Merge کند. این امر علاوه بر این که منجر به پیگیری تغییرات در پروژه می‌شود، به توسعه‌دهندگان نیز این امکان را می‌دهد که قبل از Merge آن با بقیه کد ها، در مورد آن بحث و گفت و گو کنند.
از آنجا که درخواست های Pull اساسا یک موضوع متصل به شاخه Feature هستند، بسیار متنوع می‌باشند. هنگامی که یک توسعه‌دهنده با یک مشکل سخت رو به رو می‌شود، می‌تواند یک درخواست Pull برای کمک گرفتن از بقیه اعضای تیم، ایجاد کند. از سوی دیگر، توسعه‌دهندگان تازه‌کار می‌توانند اطمینان داشته باشند که با در نظر گرفتن درخواست های Pull به عنوان بازبینی کد رسمی، کل پروژه را از بین نمی‌برند.
انجمن (Community)
در بسیاری از تیم ها، Git به عنوان سیستم کنترل نسخه مورد انتظار برای پروژه‌های جدید در آمده است. اگر تیم شما از Git استفاده می‌کند، این احتمال وجود دارد که نیاز به آموزش روند کاری، به کسانی که جدید استخدام می‌شوند، نباشد، زیرا آن‌ها قبلا با توسعه توزیع شده آشنا هستند.
علاوه بر این،Git در میان پروژه‌های منبع باز بسیار محبوب است. این بدان معناست که استفاده از کتابخانه های third-party آسان است و دیگران را تشویق می‌کنید که کد منبع باز خود را Fork کنند.
چرخه انتشار (Release) سریع تر
نتیجه نهایی شاخه های Feature، توسعه توزیع شده، درخواست های Pull و یک جامعه پایدار، یک چرخه انتشار سریع تر است. این قابلیت ها، گردش کاری چابک را تسهیل می‌کنند، جایی که توسعه‌دهندگان تشویق می‌شوند تغییرهای کوچک‌تر را به طور مکرر به اشتراک بگذارند. تغییر ها می‌توانند به نوبه خود، سریع تر از نسخه‌های یکپارچه متداول در سیستم‌های کنترل نسخه متمرکز، به Pipeline توسعه، Push شوند.
همان‌طور که انتظار دارید،Git با یکپارچه سازی مداوم و محیط‌های تحویل مداوم، بسیار خوب کار می‌کند. Hook های Git به شما این امکان را می‌دهند که در صورت وقوع برخی حوادث در مخزن، Script ها را اجرا کنید، که به شما امکان می‌دهد محتوای دلخواه خود را به طور خودکار نصب کنید. حتی می‌توانید از شاخه های خاص در سرورهای مختلف، کدی را ایجاد کرده یا توسعه دهید.
برای مثال، ممکن است بخواهید Git را به شیوه‌ای پیکربندی کنید تا هر زمان کسی درخواست Pull را در آن Merge کند، آخرین Commit را از شاخه Develop به یک سرور تست بفرستید. ترکیب این نوع ایجاد خودکار با بررسی دقیق به این معنی است که وقتی کد از مرحله توسعه به مرحله تولید می‌رود، بالاترین اطمینان ممکن را به کد خود دارید.
Git برای بازاریابی:
برای درک این که چگونه تغییر سیستم کاربری به Git بر فعالیت های بازاریابی شرکت شما تأثیر می‌گذارد، تصور کنید تیم توسعه شما سه تغییر مشخصی، برای برنامه‌ریزی در چند هفته آینده در نظر گرفته است:
• کل تیم در حال اتمام ویژگی تغییر بازی (game-changing) هستند که طی 6 ماه گذشته روی آن کار کرده‌اند.
• شخصی (علی) در حال اجرای ویژگی کوچک‌تر و غیر مرتبطی است که فقط مشتریان فعلی را تحت تأثیر قرار می‌دهد.
• شخص دیگری (رضا) در حال انجام برخی از به‌روزرسانی های مورد نیاز رابط کاربری است.
اگر از یک گردش کار سنتی برای توسعه استفاده می‌کنید که متکی به VCS متمرکز است، بدون شک همه این تغییرات در یک نسخه واحد جمع می‌شوند. بازاریابی فقط می‌تواند یک اعلامیه را در وهله اول بر روی ویژگی تغییر بازی، متمرکز کند و پتانسیل بازاریابی از دو به‌روزرسانی دیگر، به طور مؤثر چشم پوشی می‌کند.
Git، چرخه توسعه را کوتاه‌تر کرده، تقسیم این موارد به Release های فردی را بسیار آسان تر می‌کند. این به بازاریابان کمک می‌کند تا بیشتر در مورد آن‌ها صحبت کنند. در سناریوی بالا، بازاریابی می‌تواند سه کمپین ایجاد کند که پیرامون هر Feature می چرخند، و بنابراین بخش‌های بسیار خاصی از بازار را هدف قرار می‌دهد.
برای مثال، آن‌ها ممکن است یک Push بزرگ PR آماده کنند. این Push برای ویژگی تغییر بازی، یک پست وبلاگ شرکتی و اخبار خبرنامه برای ویژگی علی خواهد بود. همچنین برخی پست های مهمان در مورد تئوری UX مربوط به رضا برای ارسال به وبلاگ های طراحی خارجی را در بر دارد. همه این فعالیت ها می‌توانند با Release جداگانه ای هماهنگ شوند.
این قسمت ادامه دارد ودر قسمت بعدی این مقاله به عناوین زیر می‌پردازیم.
· Git برای مدیریت محصول
· Git برای طراحان
· Git برای پشتیبانی مشتری
· Git برای منابع انسانی
· Git برای مدیر مالی