سازماندهی و پاکسازی گیت‌هاب (برای علم داده)

منتشر‌شده در: towardsdatascience به تاریخ 25 ژانویه 2021
لینک منبع: Cleaning Up GitHub (for Data Science)

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

به هر حال، گیت‌هاب شما از بسیاری جهات چهره کدنویسی است که شما به بقیه جهان ارائه می‌دهید، و به این ترتیب، شما می‌خواهید (اگر نه با طراحی سایت Github پس با طراحی روح انسان) که مجموعه نمونه کارها به بخش‌های شعر، تجسم، دیالوگ تقسیم شده باشند و کاملا تمیز، مستند باشند، و به راحتی قابل پیمایش نیز باشند.

پنج راه عمده برای پاکسازی مخزن گیت‌هاب شما از آنچه که من دیده‌ام وجود دارد:

1. حذف مخازن قدیمی
2. تقلید یک معماری به سبک دایرکتوری در گیت‌هاب با یکی از این موارد:

• روش subtree / submodule
• پروژه‌ها
• سازمان‌ها

استراتژی ۱: حذف مخازن قدیمی

همه ما تاکنون Marie Kondo را خوانده‌ایم، صحیح است؟ به سراغ هر یک از مخازن خود بروید و از خودتان بپرسید، آیا این موجب شادی و خشنودی می‌شود؟ اگر پاسخ نه بود، از آن خلاص شوید.

در وب گشت‌وگذار کنید، این یک گزینه بسیار محبوب است. مخزن این دوره آموزشی که بعد از ظهر آن را تمام کردید؟ از شر آن خلاص شوید. چیزی که در چند ماه یا چند سال روی آن کار نکردید؟ از شر آن نیز خلاص شوید. من اعتراف می‌کنم که این گزینه تهدید، ( چه می‌شود اگر بعدا به این GAN تولیدکننده گربه نیاز داشته باشم؟) OCD من را تحریک می‌کند، اما این اولین توقف شایسته در پاکسازی گیت‌هاب است.
به تمام مخازن خود نگاه کنید، به خصوص اگر آن‌ها مثل من به صدها مخزن می‌رسند، و بپرسید که آیا واقعا به همه آن‌ها نیاز دارید. شاید بتوانید برخی از آنها را پاک کنید.

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

استراتژی ۲: تقلید از یک ساختار دایرکتوری

گیت‌هاب، از مفهوم خود، ساختار نسبتا مینیمالیستی را فراهم می‌کند. آن فاقد یک دایرکتوری واقعی یا ساختار فایل است. به عنوان مثال، اکثریت قریب به اتفاق این مخازن، از اردوگاه آموزشی علوم داده مدرسه فلاتیرون هستند، اما من نمی‌توانم همه آن‌ها را تنها در یک پوشه «فلاتیرون» قرار دهم، زیرا Github ذاتا فاقد آن ساختار است. هرچند گزینه‌های زیادی برای تقلید از این ساختار وجود دارد، با درجات مختلفی از بدل‌سازی که برای هدف اصلی ابزار لازم است.

روش subtree (یا Submodule)

به منظور پاکسازی صفحه مخازن گیت‌هاب شما، فکر می‌کنم که subtree برنده بین این دو باشد، اما من مطمئنم که کسی در خارج از اینجا از git submodule بهتر استفاده خواهد کرد. برای یک بحث نسبتا مفصل در مورد تفاوت بین این دو، این مقاله را بخوانید، اما تفاوت اصلی این است:

• ماژول فرعی (Submodule) یک اشاره‌گر را در مخزن خارجی قرار می‌دهد و به یک تعهد خاص در مخزن داخلی اشاره می‌کند (آن repo داخلی را به آن شکلی که ما در مورد یک فایل در حال حرکت در داخل یک پوشه فکر می‌کنیم به داخل رپو انتقال نمی‌دهد) و یک دستور صریح در گیت‌هاب، git submodule وجود دارد که راه‌اندازی آن را آسان می‌کند اما پس از آن نگهداری آن دشوار است.
• زیردرخت (Subtree)، از طرف دیگر، در واقع کد داخلی repo را به رپو خارجی منتقل می‌کند، مانند انتقال یک فایل به یک پوشه، اما فرمان پیش‌فرض در گیت ندارد، که راه‌اندازی آن را کمی سخت‌تر می‌کند اما نگهداری آن را بعد از آن راحت‌تر می‌کند.

این دو روش در صورتی می‌توانند به سرعت زمان بر شوند که تلاش کنید ساختار آن‌ها را در طول صدها نسخه اولیه به کار ببرید، اما شما می‌توانید نمودار سهم خود را حفظ کنید.

مطالعه مقاله با داشتن این مهارت‌های علوم داده، در هر شرکتی استخدام شوید توصیه می‌شود.

پروژه‌ها

درست همانند نام آن، این یکی امیدوار کننده به نظر می‌رسد - غریزه من هنگام شنیدن این نام چیزی مانند «من می‌توانم مخازن متعدد را با هم تحت یک پروژه گروه‌بندی کنم» است - اما دارای عملکردی بسیار نزدیک‌تر به یک لیست انجام کار برای پی‌گیری مسائل، درخواست‌ها، و یادداشت کردن است. با این حال، من شنیده‌ام که مردم از این ویژگی به عنوان روشی برای سازماندهی مخازن (تا ۵ repo در هر پروژه) استفاده می‌کنند.

سازمان‌ها

این یکی برگه برنده من بود. شما می‌توانید سازمان‌هایی را برای گروه‌بندی repo تحت آن ایجاد کنید و ۱) repo ها را از صفحه مخزن خود حذف کرده و ۲) در عوض نام سازمان را لیست کنید. بنابراین در این رابطه مهم، مسلما این نزدیک‌ترین چیزی است که شما می‌توانید برای شبیه‌سازی ساختار دایرکتوری در Github به آن بپردازید. آن اینگونه به نظر می‌رسد:

ماوس خود را روی آن بگذارید، و با این کار اطلاعاتی درباره سازمان فراهم می‌کند. در تصویر، هنوز هم می‌گوید که من حدود ۳۰۰ مخزن دارم، اما دلیل آن این است که من هنوز اکثر آن‌ها را به سازمان جدید انتقال نداده‌ام. انتقال یک مخزن به یک سازمان، حتی سازمانی که متعلق به شما است، مخزن را از فهرست مخازن در صفحه پروفایل شما حذف کرده و هر گونه مشارکت ایجاد شده در آن مخازن را از نمودار مخازن شما حذف می‌کند. برای من، این یک هزینه اندکی برای یک مکان خوب بود تا این ۳۰۰ مخزن را کنار هم و دور از دید نگه دارم، اما من مطمئن هستم که از دو نظر برای برخی بدترین است: repo ‌ها هنوز وجود دارند و من نمودار مشارکت را از دست دادم.

برای یک مثال بهتر، این مقاله را توسط آندریو کیوارا بررسی کنید.

هنگامی که پروفایل گیت‌هاب خود را پاکسازی کردید، فکر می‌کنم ایده خوبی است که به بهترین شکل ساختار حرکت رو به جلو گیت‌هاب خود را در نظر بگیرید.
یکی از بهترین راه‌ها برای انجام این کار این است که ببینیم دیگران چگونه سازمان دهی خود را انجام می‌دهند. شما می‌توانید از اینجا شروع کنید تا چند نمونه از کارهاب زیبای علم داده‌ را ببینید. یکی از موارد دلخواه شخصی من، وبسایت شخصی هانا یان هان، Github او است. او تعداد مخازن خود را در حد ۲۰ عدد نگه می‌دارد (حتی اگر پروژه‌های بیشتری نسبت به آن داشته باشد)، و پیدا کردن راه خود در آن‌ها به لطف نام‌ها و توصیفات معروف و هوشمند، آسان است.

و برای هر کسی که یک بوت‌کمپ فن‌آوری راه‌اندازی کند که خارج از مخازن گیت‌هاب عمل می‌کند، توصیه من این خواهد بود که فقط به آزمایشگاه‌هایی که شما در تلاش اصلی خود به آن‌ها کمک می‌کنید (به ترتیب ۱۰ ثانیه، نه ۱۰۰ ثانیه repo) ، و یا اینکه فقط یک سازمان در گیت‌هاب درست از همان ابتدا برای تمام آن درس‌ها راه‌اندازی کنید.

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