12 ميزة مذهلة لـ GitHub

طوال حياتي، لا أستطيع التفكير في أي مقدمة، لذا...

#1 تحرير التعليمات البرمجية على GitHub.com

سأبدأ بما أعتقد أن الجميع يعرفه بالفعل (على الرغم من أنني شخصيًا لم يكن لدي أي فكرة عنه قبل أسبوع). عند عرض أي ملف نصي على GitHub، في أي مستودع، يمكنك رؤية قلم رصاص صغير في أعلى اليمين. إذا قمت بالنقر فوقه، يمكنك تحرير هذا الملف. بمجرد الانتهاء، انقر فوق اقتراح تغيير الملف وسيقوم GitHub بإنشاء طلب شوكة وسحب. مذهل، أليس كذلك؟ يصنع الشوكة بنفسه! ليست هناك حاجة لتقسيم الكود وتحميله لنفسك، وإجراء التغييرات محليًا وإرساله مرة أخرى إلى GitHub مع طلب السحب. مناسب جدًا إذا كنت بحاجة إلى إجراء الحد الأدنى من التعديلات. ليس طلب سحب حقيقيًا تمامًا

#2 إدراج الصور

لا تقتصر أوصاف المشكلة على التعليقات النصية فقط. هل تعلم أنه يمكنك لصق الصور مباشرة من الحافظة؟ عند اللصق، سترى أنه تم تحميله (إلى السحابة، بلا شك) وتحويله إلى علامة لعرض الصورة. رشيقة!

#3 تنسيق الكود

إذا كنت بحاجة إلى كتابة مجموعة من التعليمات البرمجية، فابدأ بثلاث علامات خلفية وسيحاول GitHub تخمين لغة البرمجة التي تكتب بها. ولكن إذا كنت تنشر جزءًا من التعليمات البرمجية بلغة برمجة مثل Vue أو Typescript أو JSX، فيمكنك تحديد اللغة بشكل صريح بحيث يكون تمييز بناء الجملة صحيحًا. لاحظ ```jsx في السطر الأول: ...ضمان العرض الصحيح لمقتطف الشفرة: (ينطبق هذا أيضًا على Gist، بالمناسبة. إذا قمت بتحديد ملحق .jsf لـ Gist، فسيتم تمييز بناء جملة JSF). فيما يلي قائمة بجميع تركيبات الجملة المدعومة .

#4 حل المشكلات باستخدام "الكلمات السحرية" في طلبات السحب

لنفترض أنك قمت بإنشاء طلب سحب يعمل على إصلاح المشكلة رقم 234. يمكنك إدراج النص "إصلاح المشكلة رقم 234" في وصف طلبك (أو في أي مكان في أي تعليق لطلب التغيير). بعد ذلك، سيؤدي دمج طلب السحب إلى إغلاق المشكلة "تلقائيًا". رائع، أليس كذلك؟ إليك المزيد من المعلومات حول هذا في الوثائق .

#5 رابط للتعليقات

هل سبق لك أن كنت بحاجة إلى إنشاء رابط لتعليق معين ولم تعرف كيف؟ لقد ولت تلك الأيام منذ فترة طويلة لأنني سأخبرك بسر: لإنشاء رابط لتعليق، ما عليك سوى النقر على التاريخ/الوقت بجوار العنوان. انظر، لدى Gaearon الآن صورة!

#6 رابط الكود

لذلك تريد إنشاء رابط لسطر معين من التعليمات البرمجية. في هذه الحالة، جرب ما يلي: انقر فوق رقم السطر الموجود بجوار الكود المطلوب في الملف المفتوح. واو، ترى؟ لقد تغير عنوان URL، وأصبح رقم السطر مرئيًا فيه الآن! إذا ضغطت باستمرار على المفتاح SHIFT وانقرت على رقم سطر آخر، فهاهو الأمر! - سيتغير عنوان URL مرة أخرى وسيتم تمييز نطاق الصفوف. سيشير عنوان URL هذا الآن إلى هذا الملف وهذا النطاق من الأسطر. ولكن مهلا، فإنه يشير إلى الموضوع الحالي. ماذا لو تغير الملف؟ ربما تحتاج، في هذه الحالة، إلى رابط دائم للملف في حالته الحالية. أنا كسول جدًا، لذا التقطت لقطة شاشة واحدة لكل ما سبق: بالمناسبة، بخصوص عناوين URL...

#7 استخدام عنوان URL لـ GitHub كسطر أوامر

يتم تنظيم التنقل عبر GitHub باستخدام واجهة المستخدم بشكل مريح للغاية. لكن في بعض الأحيان، للوصول إلى موقع معين، يكون من الأسرع كتابته في عنوان URL. على سبيل المثال، إذا كنت أرغب في الذهاب إلى الفرع الذي أعمل عليه ومعرفة كيفية مقارنته بالفرع الرئيسي، فيمكنني ببساطة كتابة /compare/branchname بعد اسم المستودع. سينقلني هذا إلى صفحة الفرق لهذا الفرع: لكن هذه اختلافات عن الفرع الرئيسي، لكن إذا عملت مع فرع التكامل من قبل، فيمكنني إدخال /compare/integration-branch...my-branch في عنوان URL لمحبي مفاتيح التشغيل السريع: يقوم CTRL+L أو CMD+L بنقل المؤشر إلى شريط URL (على الأقل في متصفحات Chrome وFirefox). وهذا، بالإضافة إلى الإكمال التلقائي للمتصفح، يجعل التنقل بين الفروع أسهل بكثير. نصيحة احترافية: استخدم الأسهم للتنقل عبر اقتراحات الإكمال التلقائي في Chrome، واضغط على SHIFT+DELETE لإزالة العناصر من السجل (على سبيل المثال، بعد دمج فرع). (لا أعرف ما إذا كان سيكون من الأسهل قراءة مفاتيح الاختصار هذه إذا وضعت مسافة فيها، مثل SHIFT + DELETE. لكن "+" من الناحية الفنية ليس جزءًا منها، لذا لا أحب هذا الخيار. إنه بسبب أشياء كهذه لا أنام ليلاً يا روندا.)

# 8 إنشاء قوائم للمشاكل

هل تريد مربع اختيار في وصف مشكلتك؟ وهل تريد أن يظهر شريط أنيق مثل "2 من 5" عند عرض مشكلة من القائمة؟ لا مشكلة! يمكنك إنشاء مربعات اختيار تفاعلية باستخدام بناء الجملة التالي:

• [ ] عرض الشاشة (عدد صحيح)
• [x] دعم عمال الخدمة
• [x] جلب الدعم
• [] دعم CSS flexbox
• [ ] العناصر المخصصة

بناء الجملة: مسافة، واصلة، مسافة، قوس مربع مفتوح، مسافة (أو x)، قوس إغلاق مربع، مسافة وبعض الكلمات. بعد ذلك، يمكنك بالفعل تحديد/إلغاء تحديد هذه الأزرار! لسبب ما، يبدو هذا وكأنه نوع من السحر التقني بالنسبة لي. يمكنك تحديد المربعات! وفي نفس الوقت يتغير النص الأصلي! إنه لأمر مخيف أن نفكر فيما سيتوصلون إليه بعد ذلك. أوه، وإذا كانت هذه المشكلة موجودة في لوحة المشروع، فسيتم عرض التقدم هناك أيضًا: إذا كنت لا تفهم ما أعنيه بـ "لوحة المشروع" - اقرأ أدناه. فقط بضعة سنتيمترات أقل في هذه الصفحة.

#9 لوحات المشروع في جيثب

بالنسبة للمشاريع الكبيرة، كنت أستخدم Jira دائمًا. وبالنسبة لمشاريعي الشخصية، كنت أستخدم Trello دائمًا. أنا حقا أحب كل من هذه الأدوات. عندما علمت قبل بضعة أسابيع أن GitHub عرض خياره الخاص، مباشرة في علامة تبويب "المشاريع" في المستودع، اعتقدت أنه سيكون من المنطقي تكرار مجموعة المهام التي أعمل بها بالفعل في Trello. لا يوجد شيء مضحك هنا، والآن نفس الشيء في مشروع GitHub: تدريجيًا، ستعتاد عيناك على الصورة ذات التباين المنخفض من أجل السرعة، أضفت كل ما سبق كملاحظات، مما يعني أنها ليست مشكلات GitHub "حقيقية". لكن قوة إدارة المشكلات في GitHub تكمن في تكاملها مع بقية المستودع - لذلك ربما يكون من الأفضل إضافة المشكلات الحالية من المستودع إلى لوحة المعلومات. انقر فوق "إضافة بطاقات" في الزاوية اليمنى العليا وابحث عن ما ترغب في إضافته. هذا هو المكان الذي تكون فيه صيغة البحث الخاصة مفيدة : على سبيل المثال، اكتب is:pr is:open ويمكنك سحب أي طلب سحب مفتوح إلى اللوحة، أو label:bug إذا كنت بحاجة إلى إصلاح أي أخطاء. يمكنك أيضًا تحويل الملاحظات الموجودة إلى مشكلات. وأخيرًا، من نموذج المشكلة الموجود، قم بإضافته إلى المشروع في اللوحة اليمنى. سيتم نقله إلى قائمة الفرز الخاصة بلوحة المشروع، بحيث يمكنك اختيار العمود الذي تريد وضعه فيه عندما يكون وصف "المهمة" موجودًا في نفس المستودع حيث يوجد الكود الذي ينفذ هذه المهمة، يكون ذلك مناسبًا جدًا (جدًا). هذا يعني أنه بعد عدة سنوات من الآن، ستتمكن من تشغيل gitlem على سطر من التعليمات البرمجية ومعرفة القصة الكاملة وراء المشكلة التي أدت إلى هذا السطر، دون الحاجة إلى تعقبها بالكامل في Jira/Trello/في مكان آخر .

عيوب

على مدى الأسابيع الثلاثة الماضية، قمت بتجربة القيام بكل شيء في GitHub بدلاً من Jira (في مشروع صغير، نوع من أسلوب Kanban) وأحببته. لكن لا يمكنني أن أتخيل هذا بالنسبة لمشروع Scrum حيث يجب تقييم وحساب سرعة التطوير وما شابه ذلك بشكل صحيح. والخبر السار هو أن مشاريع GitHub تحتوي على عدد قليل جدًا من "الميزات الخاصة" بحيث أن التبديل إلى نظام آخر لن يستغرق الكثير من الوقت. لذا جربها وشاهد مدى إعجابك بها. لا أعرف مدى أهمية هذا الأمر، لكنني سمعت عن ZenHub وفتحته لأول مرة منذ 10 دقائق. إنه في الأساس امتداد لـ GitHub حيث يمكنك تقييم المشكلات وإنشاء "الملاحم" والتبعيات. هناك رسوم بيانية لسرعة التطوير والإرهاق؛ يبدو أنه مجرد شيء مذهل. مزيد من القراءة: وثائق جيثب على المشاريع.

#10 جويكي

بالنسبة لمجموعة غير منظمة من الصفحات - مثل ويكيبيديا - فإن GitHub Wiki (الذي سأسميه Gwiki من الآن فصاعدًا) يعد أمرًا رائعًا. بالنسبة لمجموعة منظمة من الصفحات - على سبيل المثال، مثل الوثائق الخاصة بك - ليس كثيرًا. لا توجد طريقة للإشارة إلى أن "هذه الصفحة تابعة لتلك الصفحة"، ولا توجد أشياء مريحة مثل أزرار "القسم التالي" و"القسم السابق". من المؤكد أن هانسيل وجريتل سوف يضيعان هنا، لأنه لا توجد "فتات الخبز" (عوامل تصحيح الأخطاء الخاصة - تقريبًا.) هنا أيضًا. (ملاحظة المؤلف: هل قرأت هذه القصة؟ إنها غير إنسانية تمامًا. يقتل اثنان من البلطجية سيدة عجوز فقيرة جائعة، ويحرقونها حية في فرنها الخاص . وبالطبع، يتركون فوضى كاملة لا يستطيع أحد أن يفهمها. أعتقد أن هذا هو السبب الشباب هذه الأيام حساسون للغاية - القصص التي تُقرأ للأطفال في وقت النوم هذه الأيام ليست قاسية بما فيه الكفاية!) للمضي قدمًا - لتجربة Gwiki بشكل حقيقي، أدخلت بضع صفحات من NodeJS كصفحات wiki، ثم قمت بإنشاء صفحة مخصصة الشريط الجانبي لمحاكاة البنية الفعلية للموقع. هذا الشريط الجانبي موجود دائمًا، على الرغم من عدم تمييز الصفحة الحالية. يجب صيانة الروابط يدويًا، ولكن بشكل عام كل شيء يعمل بشكل جيد. إذا أردت، يمكنك إلقاء نظرة : لا يمكن أن يتنافس هذا مع شيء مثل GitBook (المستخدم في وثائق Redux ) أو موقع ويب مخصص. ولكن هذا يمثل بالفعل 80٪ منه وكل شيء على ما يرام في مستودعك. أنا مجرد معجب بهذا. أقترح أنه إذا تجاوزت حجم ملف README.md الفردي وتحتاج إلى عدة صفحات مختلفة لأدلة المستخدم أو وثائق أكثر تفصيلاً، فمن المنطقي الالتزام بـ Gwiki. إذا كان الافتقار إلى البنية/التنقل يزعجك، فانتقل إلى شيء آخر.

#11 صفحات جيثب

ربما تعلم بالفعل أنه يمكن استخدام صفحات GitHub لاستضافة موقع ويب ثابت. وإذا كنت لا تعرف، فأنت تعرف الآن. ومع ذلك، هذا القسم مخصص لموضوع أكثر تحديدًا: استخدام Jekyll لإنشاء موقع ويب. في أبسط أشكاله، يمكن لـ GitHub Pages + Jekyll عرض ملف README.md باستخدام مظهر جميل. على سبيل المثال، ألقِ نظرة على صفحتي التمهيدية من about-github : إذا قمت بالنقر فوق علامة تبويب الإعدادات لموقع GitHub هذا، فقم بتمكين صفحات GitHub، وحدد سمة Jekyll... ثم سنحصل على صفحة بأسلوب موضوع Jekyll : يمكنك بعد ذلك إنشاء موقع ثابت بالكامل يعتمد بشكل أساسي على ملفات ترميزية قابلة للتحرير بسهولة، وتحويل GitHub إلى نظام إدارة محتوى (CMS). على الرغم من أنني لم أستخدم هذا فعليًا، إلا أن هذه هي الطريقة التي يتم بها إنشاء مواقع الويب باستخدام إطار عمل Bootstrap باستخدام React، لذلك لا يوجد شيء فظيع في ذلك. ألاحظ أن روبي يجب أن يعمل على الجهاز المحلي (سيتبادل مستخدمو Windows هنا نظرات الفهم ويذهبون في الاتجاه الآخر، وسيقول مستخدمو macOS: "ما المشكلة، إلى أين أنت ذاهب؟ روبي هي منصة عالمية! هناك أيضًا نظام GEMS" نظام إدارة الحزم!") (من الجدير بالذكر أيضًا أن "المحتوى أو السلوك العدواني أو التهديدي" غير مسموح به على صفحات GitHub، لذلك لن تتمكن من نشر نسختك من قصة Hansel and Gretel هناك).

رأيي

كلما بحثت أكثر في مجموعة GitHub Pages + Jekyll (في هذه المقالة)، كلما اعتقدت أن الفكرة بأكملها تبدو غريبة. فكرة "إنشاء موقع الويب الخاص بك بأقل جهد" رائعة. ولكن للعمل عليه، لا تزال بحاجة إلى الإصدار الحالي على الجهاز المحلي. وبالنسبة لشيء "بسيط" جدًا، يوجد عدد كبير جدًا من أوامر سطر الأوامر. لقد قمت بتصفح الصفحات السبع الموجودة في قسم "البدء" وشعرت أن الشيء الوحيد البسيط فيها هو أنا . ولم أتمكن حتى من اكتشاف بناء الجملة البسيط للصفحة الرئيسية أو أساسيات "آلية القوالب البسيطة المستندة إلى اللغة السائلة". أفضل أن أكتب موقعًا بنفسي! لأكون صادقًا، أنا مندهش قليلًا من أن Facebook يستخدم هذا لتوثيق React بينما من المحتمل أن يتمكنوا من إنشاء صفحات نظام المساعدة الخاصة بهم باستخدام React والعرض المسبق كملفات HTML ثابتة كل يوم . كل ما يتعين عليهم فعله هو إيجاد طريقة لتلقي ملفات العلامات الموجودة كما لو كانت قادمة من نظام إدارة المحتوى (CMS). ماذا إذا...

#12 استخدام GitHub كنظام إدارة المحتوى (CMS).

لنفترض أن لدينا موقع ويب يحتوي على بعض النصوص، لكننا لا نريد تخزين هذا النص كعلامة HTML. وبدلاً من ذلك، نرغب في تخزين أجزاء من النص في مكان ما بحيث يمكن للمستخدمين غير المطورين تحريرها بسهولة. ويفضل أن يكون ذلك مع بعض خيارات الإصدار. ربما حتى مع وجود نوع ما من عملية مراجعة النظراء. إليك ما أقترحه: استخدم ملفات العلامات المخزنة في المستودع لتخزين النص. واستخدم مكونًا في جانب العميل يمكنه استرداد هذه الأجزاء من النص وعرضها على الصفحة. أنا معجب بـ React، لذا إليك مثالًا لمكون <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 لجلب المحتوى ، لكنني أشك في أنك ستحتاج إلى ذلك.) يمكنك استخدام مكون مثل هذا مثل هذا:

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 للحصول على قائمة بجميع ملفات الترميز في الدليل. المكافأة - المرافق جيثب! أنا أستخدم ملحق Octotree Chrome منذ بعض الوقت وأوصيك به. ليس بدون تحفظات، ولكن ما زلت أوصي به. يعرض لوحة على اليسار مع عرض شجرة للمستودع الذي تتصفحه. ومن هذا الفيديو تعرفت على octobox ، والذي يبدو لي أيضًا أنه أداة جيدة جدًا حتى الآن. هذا هو البريد الوارد الخاص بمشكلات GitHub الخاصة بك. هذا كل ما تحتاج لمعرفته عنه. عند الحديث عن الألوان، قمت بالتقاط جميع لقطات الشاشة المذكورة أعلاه بمظهر خفيف حتى لا تخيفك. ولكن إذا كنت أفضّل الألوان الداكنة في كل شيء آخر، فلماذا أتحمل GitHub الشاحب المميت؟ استخدمت هنا مزيجًا من الامتداد Stylish لمتصفح Chrome (والذي يمكنه تطبيق السمات على أي موقع ويب) ونمط GitHub Dark . وبالنسبة للمبتدئين، فإن المظهر الداكن لأدوات مطور GitHub (مدمج، تحتاج فقط إلى تمكينه) وموضوع Atom One Dark لمتصفح Chrome.

بيتبوكيت

بالمعنى الدقيق للكلمة، هذا ليس مناسبًا تمامًا هنا، لكن لا يسعني إلا أن أذكر Bitbucket. منذ عامين بدأت مشروعًا وقضيت نصف يوم في اختيار أفضل استضافة git. لذلك، فازت Bitbucket بهامش كبير. يعد خط أنابيب مراجعة التعليمات البرمجية الخاص بهم متقدمًا جدًا على المنافسة (كان هذا قبل فترة طويلة من ظهور مفهوم المراجع لدى GitHub). منذ ذلك الحين، حصل GitHub أيضًا على مراجعات. لسوء الحظ، لم تتح لي الفرصة لاستخدام Bitbucket خلال العام الماضي - ربما يكونون قد تقدموا في شيء ما مرة أخرى. لذلك أوصي المسؤولين عن اختيار خدمة استضافة git بالاهتمام أيضًا بـ Bitbucket.

خاتمة

هذا كل شئ! أتمنى أن أكون قد تمكنت من إخبارك على الأقل بثلاثة أشياء لم تكن تعرفها من قبل. وآمل أيضًا أن تكون قد قضيت وقتًا ممتعًا في قراءة مقالتي.