کنترل نسخه برای سخت افزار منبع باز: 10 مرحله

2024 نویسنده: John Day | [email protected]. آخرین اصلاح شده: 2024-01-30 08:56

تیم Brainbow تعدادی پروژه الکترونیکی تحت پوشش ما دارد و ما می خواستیم روند استفاده از کنترل نسخه برای مدیریت گردش کار طراحی الکترونیک خود را به اشتراک بگذاریم. این گردش کار برای پروژه های بزرگ و کوچک ، از تخته های 2 لایه ساده تا هیولاهای پیچیده 10 لایه استفاده می شود و بر اساس ابزارهای منبع باز است. امیدوارم دیگران بتوانند گردش کار ما را برای خودشان اتخاذ کنند و مزایای کنترل نسخه برای پروژه های خود را بدست آورند. اما کنترل نسخه چه مزایایی می تواند برای پروژه های الکترونیکی ارائه دهد؟

مرحله 1: چرا نسخه الکترونیک خود را کنترل می کنید؟

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

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

مرحله 2: ابزارها: KiCad و Git

ما در این پروژه از دو ابزار اصلی استفاده می کنیم: سیستم کنترل نسخه (VCS) و برنامه اتوماسیون طراحی الکترونیک (EDA یا ECAD).

بسیاری از سیستم های کنترل نسخه وجود دارد ، اما ما از VCS Git توزیع شده استفاده می کنیم. ما به دلایل مختلف از آن استفاده می کنیم ، اما مهمترین نکته این است که منبع باز است (بررسی کنید!) ، آسان برای استفاده است (بررسی کنید!) و VCS استاندارد عملا برای نرم افزارهای منبع باز (بررسی کنید!). ما از Git به عنوان VCS برای ردیابی تغییرات فایل هایی که برنامه ECAD ما استفاده می کند ، استفاده خواهیم کرد. این دستورالعمل نیازی به آشنایی با Git ندارد ، اما راحتی عمومی با استفاده از خط فرمان فرض می شود. من سعی می کنم در صورت لزوم به منابع مفید برای استفاده از Git و خط فرمان پیوند دهم.

اکثر سیستم های کنترل منبع به ویژه برای فایل های مبتنی بر متن خوب کار می کنند ، بنابراین یک برنامه ECAD که از فایل های متنی استفاده می کند عالی خواهد بود. وارد KiCad ، منبع باز "بسترهای نرم افزاری و مجموعه ابزارهای خودکار طراحی الکترونیک منبع باز" شوید که توسط محققان CERN پشتیبانی می شود. KiCad همچنین منبع باز است (بررسی کنید!) ، آسان برای استفاده (اگرچه برخی در این مورد با من مخالف هستند) و برای کارهای پیشرفته طراحی الکترونیک بسیار توانا است.

مرحله 3: نصب

برای نصب این برنامه ها ، دستورالعمل های سایت های بارگیری مختلف آنها را که در زیر پیوند خورده اند دنبال کنید.

• KiCad چند پلتفرم است (و به همین دلیل سرگیجه آور است ؛ صفحه بارگیری آنها 13 سیستم عامل پشتیبانی شده را فهرست می کند و در صورت عدم نیاز به کد منبع بارگیری کد را ارائه می دهد). از نصب پیش فرض یکپارچه kicad استفاده کنید ، نه ساخت برنامه توسعه شبانه. برای اطلاع از جزئیات اختیاری پیشرفته در مورد نصب کتابخانه به مرحله 4 مراجعه کنید.
• Git همچنین کراس پلتفرم است. در صورت استفاده از ویندوز ، من Git for Windows را برای تجربه مفیدتر و کامل تر پیشنهاد می کنم.

مستندات نصب موجود در هر دو سایت کاملتر از هر توضیحی است که می توانم در اینجا ارائه دهم. پس از بارگیری و نصب هر دو برنامه ، می توانید قالب پروژه Brainbow را از مخزن Github ما کلون کنید. دستور git clone ساختار `git clone {src directory} {target directory}` را می گیرد؛ برای پروژه ما ، از `git clone https://github.com/builtbybrainbow/kicad-starter.git {directory directory} استفاده کنید.

شبیه سازی یک repo git شکل خاصی از کپی است. وقتی پروژه ای را کلون می کنید ، یک کپی از تمام فایل های موجود در repo و همچنین کل سابقه پروژه Git-tracked پروژه دریافت می کنید. با شبیه سازی repo ما ، یک فهرست پروژه را دریافت می کنید که قبلاً با توصیه های ما برای استفاده از Git با KiCad ساختار یافته است. ما در مرحله 6 در مورد ساختار پروژه بیشتر توضیح خواهیم داد ، یا اگر برای کار کردن دچار خارش شدید ، می توانید به مرحله 7 بروید.

چند کار خانه داری سریع - "git remote rm origin" را اجرا کنید تا پیوند پروژه Github را که از آن کلون کرده اید حذف کنید. همچنین ، git commit --amend --author = "John Doe" را اجرا کرده و نام و ایمیل خود را جایگزین پارامتر نویسنده کنید. این آخرین تعهد (که در این مورد نیز اولین تعهد است) را اصلاح می کند و نویسنده را به جای Brainbow به شما تغییر می دهد.

مرحله 4: توجه به نصب: کتابخانه های KiCad

یک نکته سریع در مورد ساختار کتابخانه KiCad. KiCad مجموعه ای از کتابخانه ها را که توسط تیم توسعه دهنده برای طیف وسیعی از قطعات الکتریکی نگهداری می شود ، ارائه می دهد. سه کتابخانه اصلی وجود دارد:

• نمادهای شماتیک: نمادهایی که برای نمایش اجزای الکترونیکی در یک نقشه شماتیک مدار استفاده می شود.
• ردپای PCB: نقشه های دو بعدی نشان دهنده رد پای واقعی (پدهای مسی ، متن صفحه ابریشم و غیره) که باید هنگام چیدن مدار روی PCB استفاده شود.
• مدلهای سه بعدی: مدلهای سه بعدی قطعات الکترونیکی.

این کتابخانه ها به همراه مجموعه برنامه KiCad که به تازگی نصب کرده اید بارگیری می شوند. می توانید بدون هیچ زحمتی از KiCad استفاده کنید. با این حال ، برای "کاربران قدرتمند" ، فایلهای منبع کتابخانه ها در یک مخزن git در Github ذخیره می شوند ، و به کاربرانی که می خواهند از آخرین تغییرات مطلع شوند اجازه می دهد تا repo کتابخانه را در دستگاه خود کلون کنند. ردیابی کتابخانه ها با git دارای چندین مزیت است - شما می توانید زمانی را که می خواهید کتابخانه های خود را به روز کنید انتخاب کنید ، و به روزرسانی ها فقط باید تغییرات را در فایل ها ایجاد کنند ، نه اینکه کل مجموعه فایلهای کتابخانه را بارگیری کنید. با این حال ، شما مسئول به روز رسانی کتابخانه ها هستید ، که فراموش کردن آنها آسان است.

اگر می خواهید کتابخانه ها را کلون کنید ، این سایت پیشنهادات مختلف Github KiCad را ارائه می دهد. Git کتابخانه ها را روی رایانه خود کلون کنید (به عنوان مثال: `git clone https:// github.com/KiCad/kicad -mbol.git`) ، سپس KiCad را باز کنید ، نوار منو" Preferences "را انتخاب کرده و روی" Configure Paths… "کلیک کنید. " این به شما اجازه می دهد تا مسیر دایرکتوری را به KiCad بگویید تا هر کتابخانه ای را جستجو کند. این متغیرهای محیط به طور پیش فرض مسیر کتابخانه های نصب شده با نصب KiCad را تنظیم می کند. من این مقادیر را یادداشت کردم تا در صورت لزوم بتوانم به کتابخانه های پیش فرض برگردم. مسیر KICAD_SYMBOL_DIR باید به کتابخانه نمادین kicad-نمادهای شما ، KISYSMOD به کتابخانه شبیه سازی شده foot-footprints و KISYS3DMOD به کتابخانه کلون شده kicad-packages3d اشاره کند.

هنگامی که می خواهید کتابخانه ها را به روز کنید ، می توانید یک دستور ساده "git pull" را در repo کتابخانه اجرا کنید که به Git می گوید تفاوت بین نسخه محلی کتابخانه و repo "راه دور" Github را بررسی کرده و به طور خودکار خود را به روز کنید کپی محلی برای ایجاد تغییرات.

مرحله 5: مبانی Git

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

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

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

مرحله 6: ساختار پروژه KiCad

بیایید ساختار پروژه KiCad-Starter را که قبلاً کلون کرده اید ، دقیق تر بررسی کنیم. برای سهولت سازماندهی به تعدادی زیر شاخه تقسیم می شود:

• Circuit: این پوشه شامل فایلهای واقعی پروژه KiCad (شماتیک ، PCB و غیره) است. من نام این پوشه را تغییر نمی دهم ، اما تمام فایل های داخل را با نام پروژه (Circuit.pro => ArduinoMini.pro) تغییر نام می دهم.

  • Circuit.pro: فایل پروژه KiCad
  • Circuit.sch: فایل شماتیک KiCad.
  • Circuit.kicad_pcb: فایل چیدمان PCB KiCad.
• مستندات: این پوشه برای ذخیره اسناد مربوط به پروژه است. برنامه هایی برای بهبود این فضا در آینده داریم ، اما در حال حاضر شامل یک فایل ساده README است. از آن برای ذخیره یادداشت های پروژه استفاده کنید تا در آینده بتوانید آنها را مرور کنید.
• ساخت: این پوشه جایی است که شما می توانید فایل های gerber را که اکثر خانه های fab برای ساخت برد مدار شما استفاده می کنند ، ذخیره کنید. ما همچنین از آن برای ذخیره فایل های BOM و سایر اسناد که ممکن است برای ساخت و مونتاژ مورد نیاز باشد استفاده می کنیم.
• کتابخانه ها: این پوشه برای ذخیره فایلهای کتابخانه مخصوص پروژه است (در چند مرحله بیشتر به این موضوع می پردازیم).

ممکن است به چند فایل دیگر نیز توجه کرده باشید (مخصوصاً اگر دایرکتوری را ls -a) کنید. دایرکتوری.git جایی است که Git جادوی خود را انجام می دهد و تاریخچه مخزن را ذخیره می کند. فایل.gitignore برای گفتن به Git مورد استفاده قرار می گیرد که باید کدام فایل ها را نادیده بگیرد و در کنترل منبع ذخیره نشود. اینها بیشتر فایلهای پشتیبان هستند که KiCad تولید می کند ، یا چند فایل مختلف "ایجاد شده" ، مانند فهرستهای وب ، که نباید در کنترل منبع ذخیره شوند زیرا از منبعی که فایل شماتیک است تولید می شوند.

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

مرحله 7: استفاده از Git برای پروژه های KiCad

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

دایرکتوری kicad-starter را باز کنید ، سپس `git log` را برای نمایش سابقه وقوع اجرا کنید. در اینجا باید یک تعهد وجود داشته باشد ، راه اندازی مجدد بازپرداخت توسط Brainbow. اجرای "وضعیت git" وضعیت فایلهای موجود در repo شما (بدون ردیابی ، اصلاح ، حذف ، مرحله بندی) را به شما می گوید.

در حال حاضر ، شما نباید تغییری در repo خود داشته باشید. بیایید تغییری ایجاد کنیم. پروژه KiCad را باز کرده و یک مقاومت را به شماتیک اضافه کنید ، سپس ذخیره کنید. در حال حاضر اجرای "وضعیت git" باید نشان دهد که شما فایل شماتیک را تغییر داده اید ، اما هنوز آن تغییرات را برای انجام انجام نداده اید. اگر کنجکاو هستید که KiCad دقیقاً هنگام افزودن مقاومت چه کرد ، می توانید دستور diff را در فایل اصلاح شده `git diff Circuit/Circuit.sch` اجرا کنید. این تغییرات بین نسخه فعلی فایل در فهرست کار و وضعیت فایل را در آخرین مرتکب برجسته می کند.

اکنون که تغییری ایجاد کرده ایم ، بیایید سعی کنیم آن تغییر را در تاریخ پروژه خود اعمال کنیم. ما باید تغییرات را از فهرست راهنمای کاری خود به منطقه مرحله بندی منتقل کنیم. این در واقع فایل ها را در سیستم فایل جابجا نمی کند ، اما از نظر مفهومی راهی است که به Git اطلاع می دهد که شما تمام تغییرات برنامه ریزی شده خود را برای یک فایل خاص انجام داده اید و آماده انجام آن تغییرات هستید. وقتی GIT status را برای عملکرد بعدی اجرا می کنید ، مفید است. به پیام "(از" git add … "برای به روزرسانی آنچه انجام می شود استفاده کنید)" در زیر "تغییرات انجام نشده برای انجام:" استفاده کنید. Git به شما می گوید که چگونه تغییرات را به منطقه نمایش منتقل کنید. برای ایجاد تغییرات ، `git add Circuit/Circuit.sch` را اجرا کنید و سپس وضعیت git را ببینید تا ببینید چه اتفاقی افتاده است. اکنون می بینیم که فایل شماتیک تحت تغییراتی قرار دارد که باید انجام شود. اگر هنوز نمی خواهید این تغییرات را انجام دهید ، Git راهنمایی دیگری را ارائه می دهد: `(برای حذف مرحله از“git reset HEAD…”استفاده کنید). ما می خواهیم این تغییرات را انجام دهیم ، بنابراین `git commit -m" مقاومت اضافه شده به شماتیک "را اجرا می کنیم. این امر باعث ایجاد تغییرات با پیام ارائه شده می شود. اجرای گیت لاگ این تعهد را در سابقه تعهد پروژه نشان می دهد.

چند نکته دیگر در مورد تعهدات.

1. با هر صرفه جویی متعهد نشوید. وقتی احساس می کنید به نقطه ای رسیده اید که تغییرات شما تا حدودی محکم شده است ، متعهد شوید. پس از اتمام شماتیک ، متعهد می شوم ، نه بعد از هر افزودن جزء. شما همچنین نمی خواهید به ندرت متعهد شوید ، زیرا به خاطر سپردن زمینه ای که دلیل تغییراتی را که 3 هفته بعد انجام داده اید ، به سختی ممکن است دشوار باشد. تعیین زمان انجام تعهد کمی هنر است ، اما با استفاده بیشتر از Git راحت تر خواهید شد.
2. فقط منبع فروشگاه (بیشتر). این شامل فایلهای پروژه ، شماتیک و طرح بندی و همچنین کتابخانه های خاص پروژه است. این همچنین می تواند شامل فایل های مستندسازی باشد. هنگام ذخیره اشیاء مشتق شده مراقب باشید زیرا آنها می توانند به راحتی با منبع اصلی همگام شوند و این بعداً باعث سردرد می شود. فایلهای BOM و gerber بطور ساده به راحتی غیر همگام سازی می شوند ، بنابراین بهتر است از آنها اجتناب شود (اگرچه راهنمای دقیق تر در مرحله 9 آمده است).
3. پیام های متعهد بسیار مفید هستند ، اما پیام های متعهد با ساختار خوب بسیار ارزشمند هستند. این مقاله عالی چند دستورالعمل برای نوشتن پیام های واضح ، مختصر و مفید ارائه می دهد. انجام این کار ممکن است مستلزم استفاده از ویرایشگر متن خط فرمان باشد ، که ممکن است برای مبتدیان پیچیده باشد (`git commit` بدون گزینه پیام -m ویرایشگر متن را باز می کند). برای اکثر مردم ، ویرایشگر نانو را توصیه می کنم. StackOverflow توضیح خوبی در مورد تغییر ویرایشگر شما دارد

مرحله 8: پیشرفته: نسخه معنایی برای الکترونیک

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

در نرم افزار ، مفهومی از Semantic Versioning (semver) وجود دارد. سمور روش متداول نامگذاری را برای شناسایی نسخه های نرم افزاری با "شماره نسخه" ، طبق الگوی "Major. Minor. Patch" تعریف می کند. برای نقل قول مشخصات semver ، شماره نسخه را با توجه به دسته های تغییر زیر پیش می برید.

1. نسخه اصلی وقتی تغییرات API ناسازگار ایجاد می کنید ،
2. نسخه کوچک زمانی که عملکرد را به شیوه ای سازگار با گذشته اضافه می کنید ،
3. نسخه PATCH را هنگام رفع اشکال سازگار با عقب انجام دهید.

ما در Brainbow از نسخه خود semver که متناسب با نیازهای پروژه های سخت افزاری است استفاده می کنیم. مشخصات ما از همان الگوی "Major. Minor. Patch" پیروی می کند ، اگرچه تعاریف ما از اینکه چه تغییراتی تحت کدام دسته قرار می گیرد ، آشکارا متفاوت است.

1. نسخه اصلی: برای تغییرات قابل توجه در عملکرد اصلی مدار استفاده می شود (به عنوان مثال: تغییر پردازنده از ATmegaa به ESP8266).
2. نسخه MINOR: برای تعویض قطعاتی که می تواند بر عملکرد مدار تأثیر بگذارد (مانند: مبادله فلش SPI با قسمت سازگار با پین که ممکن است مجموعه فرمان متفاوتی داشته باشد) یا افزودن برخی ویژگی های اضافی جزئی (به عنوان مثال: سنسور دمای اضافی اضافه شده) استفاده می شود.
3. نسخه PATCH: برای رفع اشکالات جزئی که عملکرد مدار را تغییر نمی دهد ، مورد استفاده قرار می گیرد (مانند: تنظیم صفحه ابریشم ، تنظیم طرح جزئی ، تغییر اجزای ساده مانند خازن 0603 به 0805).

در سخت افزار سخت افزاری ، شماره نسخه فقط در تولید به روز می شود (درست مانند نرم افزار ، شماره نسخه فقط با انتشار تغییر می کند ، نه اینکه هر فرد به پروژه متعهد شود). در نتیجه ، تعداد زیادی از پروژه ها دارای شماره نسخه کم هستند. ما هنوز پروژه ای نداریم که از بیش از 4 نسخه اصلی استفاده کند.

علاوه بر مزایای سازگاری و درک پذیری که از تغییر سیستم انتخاب نامگذاری به دست می آورید ، در سازگاری سیستم عامل و رضایت مشتری نیز مزایایی کسب می کنید. سیستم عامل را می توان با در نظر گرفتن نسخه برد مورد نظر نوشت و اشکال زدایی را آسان کرد که چرا برنامه خاصی بر روی برد خاصی کار نمی کند ("درست است ، سیستم عامل 2.4.1 روی 1.2 اجرا نمی شود تخته چون ما نداریم … "). مشتریان نیز از نرم افزار سخت افزاری ما سود برده اند زیرا خدمات مشتری و عیب یابی با استاندارد تعریف شده بسیار آسان تر است.

مرحله 9: پیشرفته: استفاده از نسخه های معنایی سخت افزار

برای استفاده از سخت افزار semver در پروژه های خود ، از ویژگی Git به نام برچسب گذاری استفاده می کنیم. هنگامی که شما برای اولین بار یک تخته تولید می کنید ، این نسخه 1.0.0 آن برد است. اطمینان حاصل کنید که تمام تغییرات پروژه خود را انجام داده اید ، سپس `git tag -a v1.0.0` را اجرا کنید. با این کار ویرایشگری باز می شود تا بتوانید یک پیام حاشیه نویسی برای این برچسب بنویسید (بسیار شبیه به یک پیام متعهد). من جزئیات مربوط به تولید (که PCB را ساخت ، که هیئت مدیره را مونتاژ کرد) ذکر می کنم ، که بعداً می تواند اطلاعات مفیدی باشد.

برچسب انتشار به سابقه تعهد اضافه می شود و وضعیت فایل ها در ساخت 1.0.0 را نشان می دهد. این می تواند به ویژه در مواردی که بعداً برای عیب یابی به این نقطه مراجعه می کنید ، بسیار مفید واقع شود. بدون یک برچسب مشخص شده برای انتشار ، تشخیص اینکه کدام تعهد در زمان تولید جدیدترین بود ، دشوار است. یک برچسب 1.0.0 (و 1.1 ، 1.1.1 ، و غیره) به شما امکان می دهد مشخص کنید که این فایل های منبع خاص پرونده هایی هستند که در یک مرحله تولید خاص استفاده می شوند.

یادداشتی در مورد گربرز. برخی از خانه های فاب نیاز به فایل gerber برای ساخت برد شما دارند و شما می توانید آنها را با KiCad ایجاد کنید. این اشیاء مشتق شده هستند که از فایل.kicad_pcb منبع تولید می شوند و ما معمولاً نسخه های کنترل شده فایل ها را کنترل نمی کنیم. ما در Brainbow gerber ها را در کنترل نسخه ذخیره نمی کنیم مگر زمانی که نسخه ای را برچسب گذاری می کنیم. هنگامی که برای ساخت آماده هستیم ، فایل های gerber را تولید می کنیم ، آنها را در پوشه Fabrication ذخیره می کنیم ، و commit و tag می کنیم. سپس ژربرها را برداشته و حذف را مرتکب می شویم. این ممکن است در ابتدا کمی گیج کننده به نظر برسد ، اما این اطمینان را می دهد که برنامه های معمولی فقط فایل های منبع را ذخیره می کنند ، و نسخه های برچسب گذاری شده نیز فایل های دقیق مورد استفاده برای تولید تخته ها را ذخیره می کند. این امر در پیگیری خطاهای تولید هفته ها بعد بسیار مفید بوده است.

مرحله دهم: مراحل بعدی

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

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

با تشکر از شما برای خواندن ، و ما نمی توانیم منتظر بمانیم تا ببینیم شما چه می سازید!