12 ویژگی شگفت انگیز GitHub

برای تمام عمرم نمی توانم به هیچ مقدمه ای فکر کنم، پس...

شماره 1 ویرایش کد در GitHub.com

من با چیزی شروع می کنم که فکر می کنم همه قبلاً می دانند (اگرچه من شخصاً یک هفته پیش هیچ ایده ای در مورد آن نداشتم). هنگام مشاهده هر فایل متنی در GitHub، در هر مخزن، می توانید یک مداد کوچک را در بالا سمت راست ببینید. اگر روی آن کلیک کنید، می توانید این فایل را ویرایش کنید. پس از تکمیل، روی پیشنهاد تغییر فایل کلیک کنید و GitHub یک فورک و Pull Request ایجاد می کند. شگفت انگیز است، اینطور نیست؟ او خود چنگال را ایجاد می کند! نیازی به فورک کردن و آپلود کد برای خودتان نیست، تغییرات را به صورت محلی انجام دهید و آن را با یک درخواست کشش به GitHub برگردانید. اگر شما نیاز به حداقل ویرایش دارید، بسیار راحت است. نه یک درخواست کشش واقعی

شماره 2 درج تصاویر

توضیحات مشکل فقط به نظرات متنی محدود نمی شود. آیا می‌دانستید می‌توانید تصاویر را مستقیماً از کلیپ بورد جای‌گذاری کنید؟ وقتی جای‌گذاری شد، می‌بینید که آن را آپلود می‌کند (بدون شک در فضای ابری) و به نشانه‌گذاری برای نمایش تصویر تبدیل می‌شود. برازنده!

شماره 3 قالب بندی کد

اگر نیاز به نوشتن یک بلوک از کد دارید، با سه بک تیک شروع کنید و GitHub سعی می کند حدس بزند که به چه زبان برنامه نویسی می نویسید. اما اگر یک قطعه کد را در یک زبان برنامه نویسی مانند Vue، Typescript یا JSX ارسال می کنید، می توانید به صراحت زبان را مشخص کنید تا برجسته سازی نحو درست باشد. به jsx در خط اول توجه کنید: ... اطمینان از نمایش صحیح قطعه کد: (به هر حال این در مورد Gist نیز صدق می کند. اگر پسوند .jsf را برای یک gist مشخص کنید، دستور JSF برجسته می شود). در اینجا لیستی از تمام نحوهای پشتیبانی شده وجود دارد .

شماره 4 بستن مشکلات با استفاده از "کلمات جادویی" در درخواست های کششی

فرض کنید یک Pull Request ایجاد کرده اید که مشکل #234 را برطرف می کند. می‌توانید متن "اصلاح مشکل #234" را در توضیحات درخواست خود (یا هر جایی از هر نظر درخواست تغییر) وارد کنید. پس از این، ادغام Pull Request "به طور خودکار" مشکل را بسته می کند. جالب است، اینطور نیست؟ در اینجا اطلاعات بیشتری در مورد این در اسناد وجود دارد .

شماره 5 پیوند به نظرات

آیا تا به حال نیاز به ایجاد پیوند به یک نظر خاص داشته اید و نمی دانید چگونه؟ آن روزها خیلی گذشته است زیرا من یک راز را به شما اجازه می دهم: برای ایجاد پیوند به یک نظر، کافی است روی تاریخ/زمان کنار عنوان کلیک کنید. ببین گائرون الان عکس داره!

لینک کد شماره 6

بنابراین شما می خواهید یک لینک به یک خط کد خاص ایجاد کنید. در این صورت این را امتحان کنید: روی شماره خط کنار کد مورد نظر در فایل باز شده کلیک کنید. وای، ببین؟ URL تغییر کرده است، شماره خط اکنون در آن قابل مشاهده است! اگر کلید SHIFT را نگه دارید و روی شماره خط دیگری کلیک کنید، پس voila! - URL دوباره تغییر می کند و محدوده ردیف ها برجسته می شود. این URL اکنون به این فایل و این محدوده از خطوط اشاره می کند. اما صبر کنید، به موضوع فعلی اشاره می کند. اگر فایل تغییر کند چه؟ احتمالاً در این مورد به یک پیوند دائمی به فایل در وضعیت فعلی نیاز دارید. من خیلی تنبل هستم، بنابراین از تمام موارد بالا یک اسکرین شات گرفتم: به هر حال، در مورد URL ...

شماره 7 استفاده از URL GitHub به عنوان خط فرمان

پیمایش در GitHub با استفاده از رابط کاربری بسیار راحت سازماندهی شده است. اما گاهی اوقات، برای رسیدن به یک مکان خاص، سریعتر آن را در URL تایپ کنید. به عنوان مثال، اگر بخواهم به شعبه ای که روی آن کار می کنم بروم و ببینم که چگونه با استاد مقایسه می شود، می توانم به سادگی /compare/branchname را بعد از نام مخزن تایپ کنم. این من را به صفحه تفاوت آن شاخه می برد: اما اینها با شاخه اصلی تفاوت دارند، اما اگر قبلا با شاخه ادغام کار کرده باشم، می توانم /compare/integration-branch...my-branch را در URL وارد کنم. برای دوستداران کلید میانبر: CTRL+L یا CMD+L مکان نما را به نوار URL (حداقل در مرورگرهای کروم و فایرفاکس) منتقل می کند. این، همراه با تکمیل خودکار مرورگر، پیمایش بین شاخه‌ها را بسیار آسان‌تر می‌کند. نکته حرفه ای: از فلش ها برای پیمایش در پیشنهادات تکمیل خودکار Chrome استفاده کنید و SHIFT+DELETE را فشار دهید تا موارد را از تاریخچه حذف کنید (به عنوان مثال، پس از ادغام یک شاخه). (نمی دانم که خواندن این کلیدهای میانبر با قرار دادن فاصله مانند SHIFT + DELETE آسانتر است یا نه. اما از نظر فنی "+" بخشی از آنها نیست، بنابراین من این گزینه را دوست ندارم. به دلیل چنین چیزهایی، من شبها نمی خوابم، روندا.)

#8 لیستی برای مشکلات ایجاد کنید

آیا می خواهید یک چک باکس در توضیحات مشکل خود داشته باشید؟ و آیا می‌خواهید وقتی مشکلی را از لیست مشاهده می‌کنید، نوار بسیار خوبی مانند «2 از 5» ظاهر شود؟ مشکلی نیست! می توانید چک باکس های تعاملی را با استفاده از نحو زیر ایجاد کنید:

• [ ] عرض صفحه (عدد صحیح)
• [x] پشتیبانی کارکنان خدمات
• [x] واکشی پشتیبانی
• [ ] پشتیبانی از CSS flexbox
• [ ] عناصر سفارشی

نحو: فاصله، خط تیره، فاصله، باز کردن کروشه، فاصله (یا x)، بسته شدن براکت، فاصله و چند کلمه. پس از آن، شما در واقع می توانید این دکمه ها را تیک بزنید یا علامت آن را بردارید! بنا به دلایلی، این به نظر من نوعی جادوی فنی است. شما می توانید جعبه ها را علامت بزنید! و در عین حال متن اصلی تغییر می کند! این ترسناک است که فکر کنیم بعداً چه چیزی به ذهنشان خطور می کند. اوه، و اگر این مشکل در پنل پروژه باشد، پیشرفت در آنجا نیز نمایش داده می شود: اگر منظور من از "پانل پروژه" را متوجه نشدید - زیر را بخوانید. فقط چند سانتی متر پایین تر در این صفحه.

شماره 9 پانل های پروژه در GitHub

برای پروژه های بزرگ من همیشه از Jira استفاده کرده ام. و برای پروژه های شخصی ام همیشه از Trello استفاده کرده ام. من هر دوی این ابزارها را خیلی دوست دارم. وقتی چند هفته پیش فهمیدم که GitHub گزینه خودش را درست در برگه Projects مخزن ارائه کرده است، فکر کردم منطقی است که مجموعه وظایفی را که قبلاً در Trello با آنها کار می کردم تکرار کنم. در اینجا هیچ چیز خنده‌داری وجود ندارد و اکنون همان چیز در پروژه GitHub: به تدریج چشمان شما به تصویر با کنتراست کم عادت می کنند به خاطر سرعت، من همه موارد بالا را به عنوان یادداشت اضافه کردم، به این معنی که آنها مسائل "واقعی" GitHub نیستند. اما قدرت مدیریت مسائل در GitHub در ادغام آن با بقیه مخزن نهفته است - بنابراین احتمالاً بهتر است مسائل موجود را از مخزن به داشبورد اضافه کنید. روی Add Cards در گوشه سمت راست بالا کلیک کنید و آنچه را که می خواهید اضافه کنید پیدا کنید. اینجاست که دستور جستجوی ویژه به کار می‌آید : به عنوان مثال، عبارت is:pr is:open را تایپ کنید و می‌توانید هر درخواست بازشده Pull را روی پانل بکشید، یا اگر نیاز به رفع اشکال دارید، برچسب: اشکال را بزنید. همچنین می توانید یادداشت های موجود را به مسائل تبدیل کنید. و در نهایت از فرم مشکل موجود آن را در پنل سمت راست به پروژه اضافه کنید. به لیست تریاژ آن پانل پروژه می رود، بنابراین می توانید انتخاب کنید که آن را در کدام ستون قرار دهید هنگامی که شرح یک "وظیفه" در همان مخزن کد اجرای این وظیفه باشد، بسیار (بسیار) راحت است. این به این معنی است که سال‌ها بعد، می‌توانید git blame را روی یک خط کد اجرا کنید و داستان کاملی را که در پشت مشکلی که منجر به آن خط شده است، بدون نیاز به ردیابی همه آن در Jira/Trello/جاهای دیگر کشف کنید. .

ایرادات

در سه هفته گذشته من به جای Jira (در یک پروژه کوچک، نوعی سبک کانبان) همه چیز را در GitHub انجام داده ام و آن را دوست دارم. اما من نمی توانم این را برای یک پروژه اسکرام تصور کنم که در آن سرعت توسعه و موارد مشابه باید به درستی ارزیابی و محاسبه شود. خبر خوب این است که پروژه‌های GitHub آنقدر «ویژگی‌های ویژه» کمی دارند که جابجایی به سیستم دیگری زمان زیادی نمی‌برد. پس آن را امتحان کنید و ببینید چقدر آن را دوست دارید. من نمی دانم چقدر این مهم است، اما من در مورد ZenHub شنیدم و آن را برای اولین بار 10 دقیقه پیش باز کردم. این اساساً توسعه‌ای از GitHub است که در آن می‌توانید مسائل را رتبه‌بندی کنید و "حماسه" و وابستگی ایجاد کنید. نمودارهایی از سرعت توسعه و فرسودگی وجود دارد. به نظر می رسد این فقط یک چیز شگفت انگیز است. مطالعه بیشتر: مستندات GitHub در پروژه ها.

شماره 10 گویکی

برای مجموعه‌ای از صفحات بدون ساختار - مانند ویکی‌پدیا - GitHub Wiki (که از این به بعد فقط Gwiki می‌نامم) عالی است. برای مجموعه ای ساختاریافته از صفحات - به عنوان مثال، مانند اسناد شما - نه چندان. هیچ راهی برای نشان دادن اینکه "این صفحه فرزند آن صفحه است" وجود ندارد؛ هیچ چیز مناسبی مانند دکمه های "بخش بعدی" و "بخش قبلی" وجود ندارد. هانسل و گرتل قطعاً در اینجا گم می شوند، زیرا در اینجا نیز هیچ "خرده نان" (عملگرهای ویژه اشکال زدایی - تقریباً ترجمه شده) وجود ندارد. (یادداشت نویسنده: آیا شما این داستان را خوانده اید ؟ این فقط غیرانسانی است. دو اراذل و اوباش جوان یک پیرزن بیچاره گرسنه را می کشند و او را زنده زنده در تنور خود می سوزانند . و البته یک آشفتگی کامل برای هیچکس باقی می گذارند. فکر می کنم به همین دلیل است. جوانان این روزها بسیار حساس هستند – داستان هایی که این روزها هنگام خواب برای کودکان خوانده می شود به اندازه کافی بی رحمانه نیستند!) در ادامه – برای آزمایش واقعی Gwiki، چند صفحه از NodeJS را به عنوان صفحات ویکی وارد کردم، سپس یک نوار کناری سفارشی ایجاد کردم. برای شبیه سازی ساختار واقعی سایت. این نوار کناری همیشه وجود دارد، اگرچه صفحه فعلی برجسته نشده است. پیوندها باید به صورت دستی نگهداری شوند، اما در کل همه چیز خوب کار می کند. در صورت تمایل می توانید نگاهی بیندازید : این به سختی می تواند با چیزی مانند GitBook (که در مستندات Redux استفاده می شود ) یا یک وب سایت سفارشی رقابت کند. اما این در حال حاضر 80٪ خوب است و همه چیز در مخزن شما درست است. من فقط طرفدار این هستم پیشنهاد می‌کنم اگر از فایل README.md پیشی گرفته‌اید و به چندین صفحه مختلف برای راهنمای کاربر یا مستندات دقیق‌تر نیاز دارید، منطقی است که از Gwiki استفاده کنید. اگر فقدان ساختار / مسیریابی شما را آزار می دهد، به سراغ چیز دیگری بروید.

شماره 11 صفحات GitHub

ممکن است قبلاً بدانید که صفحات GitHub می توانند برای میزبانی یک وب سایت ثابت استفاده شوند. و اگر نمی دانستید، اکنون می دانید. با این حال، این بخش به موضوع خاصی اختصاص یافته است: استفاده از Jekyll برای ایجاد یک وب سایت. در ساده‌ترین شکل، GitHub Pages + Jekyll می‌تواند فایل README.md را با استفاده از یک تم زیبا ارائه دهد. برای مثال، نگاهی به صفحه readme من از about-github بیندازید : اگر روی برگه تنظیمات این سایت GitHub کلیک کنید، GitHub Pages را فعال کنید و موضوع Jekyll را انتخاب کنید... سپس صفحه ای به سبک تم جکیل دریافت خواهیم کرد : سپس می توانید یک سایت کامل استاتیک را بر اساس فایل های نشانه گذاری به راحتی قابل ویرایش ایجاد کنید و اساساً GitHub را به یک CMS تبدیل کنید. اگرچه من واقعاً از این استفاده نکرده‌ام، اما وب‌سایت‌ها با استفاده از چارچوب Bootstrap با استفاده از React به این شکل ساخته می‌شوند، بنابراین هیچ چیز وحشتناکی در مورد آن وجود ندارد. توجه داشته باشم که Ruby باید روی ماشین محلی در حال اجرا باشد (کاربران ویندوز در اینجا نگاه های فهم خود را رد و بدل می کنند و به سمت دیگری می روند، کاربران macOS خواهند گفت: "مشکل چیست، کجا می روی؟ Ruby یک پلت فرم جهانی است! یک GEMS نیز وجود دارد. سیستم مدیریت بسته!») (همچنین شایان ذکر است که «محتوا یا رفتار تهاجمی یا تهدید آمیز» در صفحات GitHub مجاز نیست، بنابراین نمی توانید نسخه خود از داستان هانسل و گرتل را در آنجا پست کنید).

نظر من

هرچه بیشتر به ترکیب صفحات GitHub + Jekyll (برای این مقاله) نگاه کردم، بیشتر فکر کردم که کل ایده بوی عجیبی می دهد. ایده "ساخت وب سایت خود با حداقل تلاش" عالی است. اما برای کار بر روی آن همچنان به نسخه فعلی در دستگاه محلی نیاز دارید. و برای چیزی به این "ساده" دستورات خط فرمان بسیار زیادی وجود دارد. من هفت صفحه در بخش شروع کار را مرور کردم و احساس کردم که تنها چیز ساده در مورد آن من هستم . و من حتی نحو ساده صفحه اصلی یا اصول اولیه یک "مکانیسم قالب بندی مبتنی بر زبان مایع" را پیدا نکرده ام. ترجیح می دهم خودم یک وب سایت بنویسم! صادقانه بگویم، من کمی تعجب می کنم که فیس بوک از این برای اسناد React استفاده می کند، در حالی که آنها احتمالاً می توانند صفحات سیستم کمکی خود را با استفاده از React بسازند و هر روز به عنوان فایل های HTML ایستا پیش رندر شوند . تنها کاری که آنها باید انجام دهند این است که راهی برای دریافت فایل‌های نشانه‌گذاری موجود پیدا کنند که گویی از CMS می‌آیند. چه می شود اگر...

#12 استفاده از GitHub به عنوان CMS

فرض کنید یک وب سایت با مقداری متن داریم، اما نمی خواهیم آن متن را به عنوان نشانه گذاری HTML ذخیره کنیم. در عوض، ما می‌خواهیم تکه‌هایی از متن را در جایی ذخیره کنیم که توسط کاربران غیر توسعه‌دهنده به راحتی قابل ویرایش باشد. ترجیحا با برخی از گزینه های نسخه. شاید حتی با نوعی فرآیند بررسی همتایان. پیشنهاد من این است: از فایل های نشانه گذاری ذخیره شده در مخزن برای ذخیره متن استفاده کنید. و از کامپوننتی در سمت کلاینت استفاده کنید که این قطعات متن را بازیابی کرده و در صفحه نمایش دهد. من از طرفداران React هستم، بنابراین در اینجا یک مثال از یک کامپوننت <Markdown> مناسب است که با دادن مسیری به یک فایل markdown، آن را استخراج می کند، آن را تجزیه می کند و به صورت HTML ارائه می کند.

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(من از بسته علامت گذاری شده npm در اینجا برای تجزیه نشانه گذاری در HTML استفاده می کنم) URL به مخزن نمونه من اشاره می کند که حاوی فایل های نشانه گذاری در فهرست /text-snippets است . (شما همچنین می توانید از GitHub API برای واکشی محتوا استفاده کنید ، اما شک دارم که به آن نیاز داشته باشید.) می توانید از یک مؤلفه مانند این استفاده کنید:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

بنابراین اکنون GitHub به نوعی به عنوان CMS شما برای آن دسته از متن هایی که می خواهید میزبانی کنید عمل می کند. مثال بالا فقط پس از بارگیری کامپوننت در مرورگر، نشانه گذاری را بازیابی می کند. اگر به یک سایت ثابت نیاز دارید، باید آن را روی سرور رندر کنید. خبر خوب! هیچ چیزی مانع از بازیابی همه فایل های نشانه گذاری روی سرور (با استفاده از هر استراتژی ذخیره سازی که دوست دارید) نمی شود. اگر تصمیم به رفتن به این مسیر دارید، منطقی است که از GitHub API برای دریافت لیستی از تمام فایل های نشانه گذاری در یک فهرست استفاده کنید. پاداش - ابزارهای GitHub! من مدت زیادی است که از افزونه Octotree Chrome استفاده می کنم و آن را به شما توصیه می کنم. بدون رزرو نیست، اما من هنوز آن را توصیه می کنم. این یک پانل در سمت چپ با نمای درختی از مخزنی که در حال مرور آن هستید را نشان می دهد. و از این ویدیو در مورد octobox یاد گرفتم ، که به نظر من نیز تا به حال یک ابزار بسیار خوب است. این صندوق ورودی برای مشکلات GitHub شما است. این تمام چیزی است که باید در مورد او بدانید. در مورد رنگ ها، من تمام اسکرین شات های بالا را در یک تم روشن گرفتم تا شما را نترسانم. اما اگر من رنگ‌های تیره را در هر چیز دیگری ترجیح می‌دهم، پس چرا باید با GitHub کمرنگ و مرگبار کنار بیایم؟ در اینجا من از ترکیبی از افزونه Stylish برای مرورگر کروم (که می‌تواند تم‌ها را برای هر وب‌سایتی اعمال کند) و سبک GitHub Dark استفاده کردم . و برای شروع، تم تیره ابزارهای توسعه‌دهنده GitHub (به صورت داخلی، فقط باید آن را فعال کنید) و تم تاریک Atom One برای کروم.

بیت باکت

به طور دقیق، اینجا کاملاً مناسب نیست، اما نمی‌توانم به Bitbucket اشاره نکنم. دو سال پیش پروژه ای را شروع کردم و نیم روز را صرف انتخاب بهترین هاست گیت کردم. بنابراین، Bitbucket با اختلاف قابل توجهی برنده شد. خط لوله بررسی کد آنها بسیار جلوتر از رقبا است (این مدت ها قبل از اینکه GitHub حتی مفهوم یک بازبین را داشته باشد) بود. از آن زمان، GitHub نیز نقدهایی را به دست آورده است. متأسفانه، من در سال گذشته فرصتی برای استفاده از Bitbucket نداشتم - شاید آنها دوباره در چیزی پیشرفت کرده باشند. بنابراین توصیه می کنم کسانی که مسئولیت انتخاب سرویس میزبانی git را بر عهده دارند به بیت باکت نیز توجه کنند.

نتیجه

همین! امیدوارم حداقل توانسته باشم سه چیز را که قبلاً برای شما ناشناخته بود به شما بگویم. و همچنین امیدوارم که با خواندن مقاله من اوقات خوبی را سپری کرده باشید.