GitHub کی 12 حیرت انگیز خصوصیات

میری زندگی کے لیے، میں کسی تعارف کے بارے میں سوچ بھی نہیں سکتا، اس لیے...

#1 GitHub.com پر کوڈ میں ترمیم کرنا

میں اس کے ساتھ شروع کروں گا جس کے بارے میں میرے خیال میں ہر کوئی پہلے سے جانتا ہے (حالانکہ مجھے ذاتی طور پر ایک ہفتہ پہلے اس کے بارے میں کوئی اندازہ نہیں تھا)۔ GitHub پر کسی بھی ٹیکسٹ فائل کو دیکھتے وقت، کسی بھی ریپوزٹری میں، آپ اوپر دائیں طرف ایک چھوٹی پنسل دیکھ سکتے ہیں۔ اگر آپ اس پر کلک کرتے ہیں، تو آپ اس فائل میں ترمیم کر سکتے ہیں۔ ایک بار مکمل ہونے کے بعد، فائل میں تبدیلی کی تجویز پر کلک کریں اور GitHub ایک فورک اور پل کی درخواست بنائے گا۔ حیرت انگیز، ہے نا؟ وہ کانٹا خود بناتا ہے! کوڈ کو فورک کرنے اور اپ لوڈ کرنے کی ضرورت نہیں ہے، مقامی طور پر تبدیلیاں کریں اور اسے پل کی درخواست کے ساتھ GitHub کو واپس بھیجیں۔ اگر آپ کو کم سے کم ترامیم کرنے کی ضرورت ہو تو بہت آسان۔ بالکل حقیقی پل کی درخواست نہیں ہے۔

#2 تصاویر داخل کرنا

مسئلہ کی تفصیل صرف متنی تبصروں تک محدود نہیں ہے۔ کیا آپ جانتے ہیں کہ آپ کلپ بورڈ سے براہ راست تصاویر پیسٹ کر سکتے ہیں؟ چسپاں ہونے پر، آپ اسے اپ لوڈ ہوتے ہوئے دیکھیں گے (کلاؤڈ پر، کوئی شک نہیں) اور تصویر کو ظاہر کرنے کے لیے مارک اپ میں تبدیل ہو گیا ہے۔ مکرم!

#3 کوڈ فارمیٹنگ

اگر آپ کو کوڈ کا ایک بلاک لکھنے کی ضرورت ہے تو، تین بیک ٹِکس سے شروع کریں اور GitHub یہ اندازہ لگانے کی کوشش کرے گا کہ آپ کس پروگرامنگ زبان میں لکھ رہے ہیں۔ لیکن اگر آپ Vue، Typescript، یا JSX جیسی پروگرامنگ زبان میں کوڈ کا ایک ٹکڑا پوسٹ کر رہے ہیں، تو آپ واضح طور پر زبان کی وضاحت کر سکتے ہیں تاکہ نحو کو نمایاں کرنا درست ہو۔ پہلی لائن پر ```jsx پر توجہ دیں: ... کوڈ کے ٹکڑوں کے درست ڈسپلے کو یقینی بنانا: (ویسے یہ Gist پر بھی لاگو ہوتا ہے۔ اگر آپ خلاصہ کے لیے .jsf ایکسٹینشن بتاتے ہیں تو JSF نحو کو نمایاں کیا جائے گا)۔ یہاں تمام تعاون یافتہ نحو کی فہرست ہے ۔

#4 پل کی درخواستوں میں "جادوئی الفاظ" کا استعمال کرتے ہوئے مسائل کو بند کرنا

ہم کہتے ہیں کہ آپ ایک پل کی درخواست بناتے ہیں جو مسئلہ #234 کو ٹھیک کرتی ہے۔ آپ اپنی درخواست کی تفصیل (یا کسی بھی تبدیلی کی درخواست کے تبصرے میں کہیں بھی) "مسئلہ #234 کو حل کرتا ہے" کا متن داخل کر سکتے ہیں۔ اس کے بعد، پل کی درخواست کو ضم کرنے سے مسئلہ "خود بخود" بند ہو جائے گا۔ ٹھنڈا، ہے نا؟ دستاویزات میں اس کے بارے میں مزید معلومات یہاں ہیں ۔

#5 تبصروں کا لنک

کیا آپ کو کبھی کسی مخصوص تبصرے کا لنک بنانے کی ضرورت پڑی ہے اور نہیں معلوم کہ کیسے؟ وہ دن گزر چکے ہیں کیونکہ میں آپ کو ایک راز بتاؤں گا: تبصرے کا لنک بنانے کے لیے، آپ صرف عنوان کے آگے تاریخ/وقت پر کلک کریں۔ دیکھو، گیرون کے پاس اب ایک تصویر ہے!

#6 کوڈ کا لنک

لہذا آپ کوڈ کی ایک مخصوص لائن کا لنک بنانا چاہتے ہیں۔ اس صورت میں، اسے آزمائیں: اوپن فائل میں مطلوبہ کوڈ کے آگے لائن نمبر پر کلک کریں۔ واہ، دیکھا؟ یو آر ایل بدل گیا ہے، لائن نمبر اب اس میں نظر آ رہا ہے! اگر آپ SHIFT کلید کو دبائے رکھتے ہیں اور دوسرے لائن نمبر پر کلک کرتے ہیں، تو voila! - URL دوبارہ تبدیل ہو جائے گا اور قطاروں کی حد کو نمایاں کیا جائے گا۔ یہ URL اب اس فائل اور لائنوں کی اس حد کی طرف اشارہ کرے گا۔ لیکن انتظار کریں، یہ موجودہ تھریڈ کی طرف اشارہ کرتا ہے۔ اگر فائل بدل جائے تو کیا ہوگا؟ آپ کو اس معاملے میں، اس کی موجودہ حالت میں فائل کا مستقل لنک درکار ہے۔ میں بہت سست ہوں، اس لیے میں نے مندرجہ بالا سب کا ایک اسکرین شاٹ لیا: ویسے، URLs کے بارے میں...

#7 GitHub URL کو بطور کمانڈ لائن استعمال کرنا

UI کا استعمال کرتے ہوئے GitHub کے ذریعے تشریف لے جانا بہت آسانی سے ترتیب دیا گیا ہے۔ لیکن بعض اوقات، کسی مخصوص مقام تک پہنچنے کے لیے، اسے صرف URL میں ٹائپ کرنا تیز تر ہوتا ہے۔ مثال کے طور پر، اگر میں کسی ایسی برانچ میں جانا چاہتا ہوں جس پر میں کام کر رہا ہوں اور دیکھنا چاہتا ہوں کہ اس کا موازنہ ماسٹر سے کیسے ہوتا ہے، تو میں صرف ذخیرہ نام کے بعد /compare/branchname ٹائپ کر سکتا ہوں۔ یہ مجھے اس شاخ کے مختلف صفحہ پر لے جائے گا: لیکن یہ ماسٹر برانچ سے اختلافات ہیں، لیکن اگر میں نے پہلے انٹیگریشن برانچ کے ساتھ کام کیا ہے، تو میں URL میں /compare/integration-branch...my-branch درج کر سکتا ہوں ہاٹکی سے محبت کرنے والوں کے لیے: CTRL+L یا CMD+L کرسر کو یو آر ایل بار میں لے جاتا ہے (کم از کم کروم اور فائر فاکس براؤزرز میں)۔ یہ، براؤزر کی خودکار تکمیل کے ساتھ مل کر، شاخوں کے درمیان نیویگیٹ کرنا بہت آسان بنا دیتا ہے۔ پرو ٹِپ: کروم کی خودکار تکمیل کی تجاویز پر تشریف لے جانے کے لیے تیروں کا استعمال کریں، اور تاریخ سے آئٹمز کو ہٹانے کے لیے SHIFT+DELETE دبائیں (مثال کے طور پر، برانچ کو ضم کرنے کے بعد)۔ (مجھے نہیں معلوم کہ ان شارٹ کٹ کیز کو پڑھنا آسان ہو گا یا نہیں اگر میں ان میں جگہ رکھوں، جیسے SHIFT + DELETE۔ لیکن تکنیکی طور پر "+" ان کا حصہ نہیں ہے، اس لیے مجھے یہ آپشن پسند نہیں ہے۔ اس طرح کی چیزوں کی وجہ سے مجھے رات کو نیند نہیں آتی، رونڈا۔)

# 8 مسائل کے لیے فہرستیں بنائیں

کیا آپ اپنے مسئلے کی تفصیل میں ایک چیک باکس چاہتے ہیں؟ اور کیا آپ چاہتے ہیں کہ جب آپ فہرست سے کوئی مسئلہ دیکھیں تو "5 میں سے 2" جیسا نفٹی بار ظاہر ہو؟ کوئی مسئلہ نہیں! آپ درج ذیل نحو کا استعمال کرتے ہوئے انٹرایکٹو چیک باکس بنا سکتے ہیں۔

• اسکرین کی چوڑائی (انٹیجر)
• [x] سروس ورکر سپورٹ
• [x] سپورٹ حاصل کریں۔
• سی ایس ایس فلیکس باکس سپورٹ
• حسب ضرورت عناصر

نحو: اسپیس، ہائفن، اسپیس، ابتدائی مربع بریکٹ، اسپیس (یا ایکس)، بند مربع بریکٹ، اسپیس اور کچھ الفاظ۔ اس کے بعد، آپ اصل میں ان بٹنوں کو چیک/ان چیک کر سکتے ہیں! کسی وجہ سے، یہ مجھے کسی قسم کا تکنیکی جادو لگتا ہے۔ آپ خانوں پر نشان لگا سکتے ہیں! اور اسی وقت اصل متن بدل جاتا ہے! یہ سوچنا خوفناک ہے کہ وہ آگے کیا کریں گے۔ اوہ، اور اگر یہ مسئلہ پروجیکٹ پینل میں ہے، تو وہاں بھی پیشرفت دکھائی جائے گی: اگر آپ نہیں سمجھتے ہیں کہ "پروجیکٹ پینل" سے میرا کیا مطلب ہے - نیچے پڑھیں۔ اس صفحہ پر صرف چند سینٹی میٹر نیچے۔

GitHub میں #9 پروجیکٹ پینل

بڑے منصوبوں کے لیے میں نے ہمیشہ جیرا کا استعمال کیا ہے۔ اور اپنے ذاتی منصوبوں کے لیے، میں نے ہمیشہ ٹریلو کا استعمال کیا ہے۔ مجھے واقعی یہ دونوں ٹولز پسند ہیں۔ جب میں نے کچھ ہفتے پہلے سیکھا کہ GitHub نے اپنے آپشن کی پیشکش کی ہے، بالکل ریپوزٹری کے پروجیکٹس ٹیب میں ، میں نے سوچا کہ ٹریلو میں پہلے سے ہی کام کرنے والے کاموں کے سیٹ کو نقل کرنا سمجھ میں آئے گا۔ یہاں کچھ بھی مضحکہ خیز نہیں ہے۔ اور اب وہی چیز GitHub پروجیکٹ میں: آہستہ آہستہ آپ کی آنکھیں کم کنٹراسٹ والی تصویر کی عادت ڈالیں گی۔ رفتار کی خاطر، میں نے مذکورہ بالا سبھی کو بطور نوٹ شامل کیا ہے، یعنی وہ "حقیقی" GitHub کے مسائل نہیں ہیں۔ لیکن GitHub میں ایشو مینجمنٹ کی طاقت باقی ریپوزٹری کے ساتھ اس کے انضمام میں مضمر ہے - لہذا موجودہ ایشوز کو ریپوزٹری سے ڈیش بورڈ میں شامل کرنا شاید بہتر ہے۔ اوپر دائیں کونے میں کارڈز شامل کریں پر کلک کریں اور تلاش کریں کہ آپ کیا شامل کرنا چاہتے ہیں۔ یہ وہ جگہ ہے جہاں خصوصی تلاش کا نحو کام آتا ہے : مثال کے طور پر، is :pr is:open ٹائپ کریں اور آپ کسی بھی کھلے پل کی درخواست کو پینل پر گھسیٹ سکتے ہیں، یا label:bug اگر آپ کو کچھ کیڑے ٹھیک کرنے کی ضرورت ہے۔ آپ موجودہ نوٹوں کو بھی ایشوز میں تبدیل کر سکتے ہیں۔ اور آخر میں، موجودہ مسئلہ فارم سے، اسے دائیں پینل میں پروجیکٹ میں شامل کریں۔ یہ اس پروجیکٹ پینل کی ٹریج لسٹ میں جائے گا، لہذا آپ منتخب کر سکتے ہیں کہ اسے کون سا کالم رکھنا ہے۔ جب کسی "ٹاسک" کی تفصیل اسی ذخیرے میں ہوتی ہے جس کوڈ اس کام کو نافذ کرتا ہے، تو یہ بہت (بہت) آسان ہوتا ہے۔ اس کا مطلب یہ ہے کہ اب سے کئی سال بعد، آپ کوڈ کی ایک لائن پر git blame چلانے کے قابل ہو جائیں گے اور جیرا/Trello/کسی اور جگہ پر اس سب کو ٹریک کیے بغیر، اس لائن کی وجہ سے ہونے والے مسئلے کی مکمل شناخت کر سکیں گے۔

خامیوں

پچھلے تین ہفتوں سے میں جیرا کے بجائے GitHub میں سب کچھ کرنے کا تجربہ کر رہا ہوں (ایک چھوٹے سے پروجیکٹ پر، کنبن کی طرز پر) اور اس سے پیار کر رہا ہوں۔ لیکن میں ایک سکرم پروجیکٹ کے لیے اس کا تصور نہیں کر سکتا جہاں ترقی کی رفتار اور اس جیسی چیزوں کا صحیح اندازہ لگانے اور حساب لگانے کی ضرورت ہے۔ اچھی خبر یہ ہے کہ GitHub پروجیکٹس میں اتنی کم "خصوصی خصوصیات" ہیں کہ دوسرے سسٹم میں سوئچ کرنے میں زیادہ وقت نہیں لگے گا۔ تو اسے آزمائیں اور دیکھیں کہ آپ اسے کتنا پسند کرتے ہیں۔ میں نہیں جانتا کہ یہ کتنا اہم ہے، لیکن میں نے ZenHub کے بارے میں سنا اور اسے 10 منٹ پہلے پہلی بار کھولا۔ یہ بنیادی طور پر GitHub کی توسیع ہے جہاں آپ مسائل کی درجہ بندی کر سکتے ہیں اور "ایپکس" اور انحصار تخلیق کر سکتے ہیں۔ ترقی کی رفتار اور برن آؤٹ کے گراف موجود ہیں۔ ایسا لگتا ہے کہ یہ صرف ایک حیرت انگیز چیز ہے۔ مزید پڑھنا: پروجیکٹس پر گٹ ہب دستاویزات۔

#10 گوکی

صفحات کے غیر ساختہ سیٹ کے لیے — جیسے ویکیپیڈیا — GitHub Wiki (جسے میں اب سے Gwiki کہوں گا) بہت اچھا ہے۔ صفحات کے ایک منظم سیٹ کے لیے - مثال کے طور پر، آپ کی دستاویزات کی طرح - اتنا زیادہ نہیں۔ یہ بتانے کا کوئی طریقہ نہیں ہے کہ "یہ صفحہ اس کا بچہ ہے"؛ "اگلا سیکشن" اور "پچھلا حصہ" بٹن جیسی کوئی آسان چیزیں نہیں ہیں۔ ہینسل اور گریٹیل یقینی طور پر یہاں گم ہو جائیں گے، کیونکہ یہاں بھی کوئی "بریڈ کرمبس" (خصوصی ڈیبگنگ آپریٹرز - تقریباً ٹرانس) نہیں ہیں۔ (مصنف کا نوٹ: کیا آپ نے یہ کہانی پڑھی ہے ؟ یہ صرف غیر انسانی ہے۔ دو نوجوان غنڈوں نے ایک غریب بھوکی بوڑھی عورت کو قتل کر دیا، اسے اپنے ہی تندور میں زندہ جلا دیا۔ اور ظاہر ہے کہ کسی کو سمجھ نہ آنے کے لیے ایک مکمل گڑبڑ چھوڑ دی گئی۔ میرے خیال میں اسی لیے نوجوان لوگ آج کل جہنم کی طرح حساس ہیں – ان دنوں سونے کے وقت بچوں کو پڑھی جانے والی کہانیاں کافی ظالمانہ نہیں ہیں!) آگے بڑھتے ہوئے – Gwiki کو حقیقی طور پر آزمانے کے لئے، میں نے NodeJS سے چند صفحات کو وکی پیجز کے طور پر درج کیا، پھر ایک اپنی مرضی کے مطابق بنایا۔ سائڈبار سائٹ کی اصل ساخت کی نقالی کرنے کے لیے۔ یہ سائڈبار ہمیشہ موجود ہے، حالانکہ موجودہ صفحہ کو نمایاں نہیں کیا گیا ہے۔ لنکس کو دستی طور پر برقرار رکھنا پڑے گا، لیکن مجموعی طور پر سب کچھ ٹھیک کام کرتا ہے۔ اگر آپ چاہیں تو ایک نظر ڈال سکتے ہیں : یہ مشکل سے کسی چیز کا مقابلہ کر سکتا ہے جیسے GitBook (جو Redux دستاویزات میں استعمال ہوتا ہے ) یا ایک bespoke ویب سائٹ۔ لیکن یہ پہلے سے ہی اس کا ایک اچھا 80٪ ہے اور آپ کے ذخیرے میں سب کچھ ٹھیک ہے۔ میں صرف اس کا پرستار ہوں۔ میرا مشورہ ہے کہ اگر آپ نے واحد README.md فائل کو بڑھا دیا ہے اور صارف کے دستورالعمل یا مزید تفصیلی دستاویزات کے لیے کئی مختلف صفحات کی ضرورت ہے، تو Gwiki کے ساتھ قائم رہنا سمجھ میں آتا ہے۔ اگر ساخت/نیویگیشن کی کمی آپ کو پریشان کرتی ہے، تو کسی اور چیز کی طرف بڑھیں۔

#11 گٹ ہب صفحات

آپ کو پہلے ہی معلوم ہو سکتا ہے کہ GitHub صفحات کو ایک جامد ویب سائٹ کی میزبانی کے لیے استعمال کیا جا سکتا ہے۔ اور اگر آپ نہیں جانتے تھے، تو آپ اب جانتے ہیں. تاہم، یہ سیکشن ایک خاص موضوع کے لیے وقف ہے: ویب سائٹ بنانے کے لیے Jekyll کا استعمال۔ اپنی آسان ترین شکل میں، GitHub Pages + Jekyll ایک اچھی لگ رہی تھیم کا استعمال کرتے ہوئے README.md فائل کو رینڈر کر سکتا ہے۔ مثال کے طور پر، about-github سے میرے ریڈمی صفحہ پر ایک نظر ڈالیں : اگر آپ اس GitHub سائٹ کے لیے ترتیبات کے ٹیب پر کلک کرتے ہیں، GitHub صفحات کو فعال کریں، اور Jekyll تھیم کو منتخب کریں... پھر ہمیں جیکیل تھیم کے انداز میں ایک صفحہ ملے گا : اس کے بعد آپ بنیادی طور پر آسانی سے قابل تدوین مارک اپ فائلوں پر مبنی ایک مکمل جامد سائٹ بنا سکتے ہیں، بنیادی طور پر GitHub کو CMS میں تبدیل کر سکتے ہیں۔ اگرچہ میں نے حقیقت میں اس کا استعمال نہیں کیا ہے، اس طرح ویب سائٹس بوٹسٹریپ فریم ورک کا استعمال کرتے ہوئے React کا استعمال کرتے ہوئے بنائی جاتی ہیں، اس لیے اس میں کوئی خوفناک بات نہیں ہے۔ میں نوٹ کرتا ہوں کہ روبی مقامی مشین پر چل رہی ہو گی (ونڈوز کے صارفین یہاں پر نظروں کا تبادلہ کریں گے اور دوسری طرف جائیں گے، macOS صارفین کہیں گے: "کیا مسئلہ ہے، آپ کہاں جا رہے ہیں؟ روبی ایک عالمگیر پلیٹ فارم ہے! یہاں ایک GEMS بھی ہے پیکیج مینجمنٹ سسٹم!") (یہ بات بھی قابل غور ہے کہ GitHub پیجز پر "جارحانہ یا دھمکی آمیز مواد یا رویے" کی اجازت نہیں ہے، اس لیے آپ ہینسل اور گریٹیل کی کہانی کا اپنا ورژن وہاں پوسٹ نہیں کر سکیں گے)۔

میری رائے

جتنا میں نے GitHub Pages + Jekyll کے امتزاج (اس مضمون کے لیے) کو دیکھا، اتنا ہی میں نے سوچا کہ پورا خیال عجیب سا محسوس ہوا۔ "کم سے کم کوشش کے ساتھ اپنی ویب سائٹ بنانے" کا خیال بہت اچھا ہے۔ لیکن اس پر کام کرنے کے لیے آپ کو ابھی بھی مقامی مشین پر موجودہ ورژن کی ضرورت ہے۔ اور اتنی "سادہ" چیز کے لیے بہت زیادہ کمانڈ لائن کمانڈز ہیں۔ میں نے شروع کرنے والے سیکشن میں سات صفحات کو چھیڑا اور محسوس کیا کہ اس کے بارے میں صرف ایک ہی آسان چیز میں ہوں ۔ اور میں نے مرکزی صفحہ کے لیے سادہ نحو یا ایک سادہ "مائع زبان پر مبنی ٹیمپلیٹنگ میکانزم" کی بنیادی باتوں کا بھی پتہ نہیں لگایا۔ میں خود ایک ویب سائٹ لکھنا پسند کروں گا! سچ پوچھیں تو، میں قدرے حیران ہوں کہ Facebook اسے React دستاویزات کے لیے استعمال کر رہا ہے جب وہ ممکنہ طور پر React کا استعمال کرتے ہوئے اپنے ہیلپ سسٹم پیجز بنا سکتا ہے اور ہر روز static 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)}} />
      );
    }
}

(میں HTML میں مارک اپ کو پارس کرنے کے لیے یہاں npm نشان زد پیکیج کا استعمال کرتا ہوں ) 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 کی افادیت! میں کافی عرصے سے آکٹوٹری کروم ایکسٹینشن استعمال کر رہا ہوں اور آپ کو اس کی سفارش کرتا ہوں۔ تحفظات کے بغیر نہیں، لیکن میں پھر بھی اس کی سفارش کرتا ہوں۔ یہ آپ جس ریپوزٹری کو براؤز کر رہے ہیں اس کے درخت کے نظارے کے ساتھ بائیں طرف ایک پینل دکھاتا ہے۔ اور اس ویڈیو سے میں نے octobox کے بارے میں سیکھا ، جو مجھے اب تک ایک بہت اچھی افادیت بھی لگتا ہے۔ یہ آپ کے GitHub مسائل کے لیے ان باکس ہے۔ آپ کو اس کے بارے میں بس اتنا ہی جاننے کی ضرورت ہے۔ رنگوں کی بات کرتے ہوئے، میں نے اوپر کے تمام اسکرین شاٹس ہلکے تھیم میں لیے ہیں تاکہ آپ کو خوفزدہ نہ کریں۔ لیکن اگر میں ہر چیز میں گہرے رنگوں کو ترجیح دیتا ہوں تو پھر جان لیوا پیلا گٹ ہب کیوں برداشت کریں؟ یہاں میں نے کروم براؤزر کے لیے اسٹائلش ایکسٹینشن کا ایک مجموعہ استعمال کیا (جو کسی بھی ویب سائٹ پر تھیمز لگا سکتا ہے) اور GitHub Dark سٹائل ۔ اور شروع کرنے والوں کے لیے، GitHub ڈویلپر ٹولز ڈارک تھیم (بلٹ ان، آپ کو بس اسے فعال کرنے کی ضرورت ہے) اور کروم کے لیے ایٹم ون ڈارک تھیم۔

بٹ بکٹ

سخت الفاظ میں، یہ یہاں مکمل طور پر مناسب نہیں ہے، لیکن میں صرف بٹ بکٹ کا ذکر کرنے میں مدد نہیں کر سکتا۔ دو سال پہلے میں نے ایک پروجیکٹ شروع کیا اور آدھا دن بہترین گٹ ہوسٹنگ کا انتخاب کرنے میں گزارا۔ لہذا، بٹ بکٹ نے ایک اہم مارجن سے جیت لیا۔ ان کا کوڈ ریویو پائپ لائن مقابلے سے بہت آگے ہے (یہ GitHub کے پاس جائزہ لینے والے کے تصور سے بہت پہلے کی بات ہے)۔ تب سے، GitHub نے بھی جائزے حاصل کیے ہیں۔ بدقسمتی سے، مجھے پچھلے سال سے بٹ بکٹ استعمال کرنے کا موقع نہیں ملا ہے - شاید وہ کسی چیز میں آگے بڑھ گئے ہیں۔ لہذا میں تجویز کرتا ہوں کہ وہ لوگ جو گٹ ہوسٹنگ سروس کو منتخب کرنے کے ذمہ دار ہیں وہ بھی بٹ بکٹ پر توجہ دیں۔

نتیجہ

بس! مجھے امید ہے کہ میں آپ کو کم از کم تین چیزیں بتانے کے قابل ہوں جو پہلے آپ کو معلوم نہیں تھیں۔ اور مجھے امید ہے کہ آپ نے میرا مضمون پڑھ کر اچھا وقت گزارا ہے۔