GitHub جون 12 حيرت انگيز خاصيتون

منهنجي زندگيءَ لاءِ، مان ڪنهن تعارف جو سوچي به نٿو سگهان، تنهنڪري...

#1 ايڊٽنگ ڪوڊ GitHub.com تي

مان ان سان شروع ڪندس جيڪو مان سمجهان ٿو ته هرڪو اڳ ۾ ئي ڄاڻي ٿو (جيتوڻيڪ مون کي ذاتي طور تي هڪ هفتو اڳ ان بابت ڪا ڄاڻ نه هئي). جڏهن GitHub تي ڪا به ٽيڪسٽ فائل ڏسي رهيا آهيو، ڪنهن به مخزن ۾، توهان ڏسي سگهو ٿا هڪ ننڍڙو پنسل مٿي ساڄي پاسي. جيڪڏھن توھان ان تي ڪلڪ ڪريو، توھان ھن فائل کي تبديل ڪري سگھو ٿا. هڪ دفعو مڪمل ٿيو، ڪلڪ ڪريو پروپوز فائل تبديلي ۽ GitHub هڪ ڪانٽو ٺاهيندو ۽ درخواست کي ڇڪيو. حيرت انگيز، آهي نه؟ هو پاڻ ٺاهي ٿو ڪانٽو! ڪا ضرورت نه آهي ڪانٽو ۽ ڪوڊ اپلوڊ ڪرڻ لاءِ پاڻ ڏانهن، مقامي طور تي تبديليون ڪريو ۽ ان کي واپس موڪليو GitHub ڏانهن پل جي درخواست سان. تمام آسان جيڪڏھن توھان کي گھٽ ۾ گھٽ تبديليون ڪرڻ جي ضرورت آھي. بلڪل حقيقي پل جي درخواست ناهي

#2 تصويرون داخل ڪرڻ

مسئلن جي وضاحت صرف متن جي تبصرن تائين محدود ناهي. ڇا توهان کي خبر آهي ته توهان تصويرون سڌو سنئون ڪلپ بورڊ تان پيسٽ ڪري سگهو ٿا؟ جڏهن پيسٽ ڪيو ويو، توهان ڏسندا ته ان کي اپلوڊ ڪيو ويو (ڪڪر تي، ڪو شڪ ناهي) ۽ تصوير کي ڊسپلي ڪرڻ لاء مارڪ اپ ۾ تبديل ٿي ويو. مهرباني!

#3 ڪوڊ فارميٽ

جيڪڏهن توهان کي ڪوڊ جو هڪ بلاڪ لکڻ جي ضرورت آهي، ٽن پٺتي پيلن سان شروع ڪريو ۽ GitHub اهو اندازو لڳائڻ جي ڪوشش ڪندو ته توهان ڪهڙي پروگرامنگ ٻولي ۾ لکي رهيا آهيو. پر جيڪڏهن توهان ڪوڊ جو هڪ ٽڪرو پوسٽ ڪري رهيا آهيو پروگرامنگ ٻولي جهڙوڪ Vue، Typescript، يا JSX، ته توهان واضح طور تي ٻولي بيان ڪري سگهو ٿا ته جيئن نحو نمايان ڪرڻ صحيح هجي. نوٽ ڪريو ``jsx پهرين لڪير تي: ...ڪوڊ اسنيپٽ جي صحيح ڊسپلي کي يقيني بڻائڻ: (اهو به Gist تي لاڳو ٿئي ٿو، رستي ۾. جيڪڏهن توهان وضاحت ڪريو .jsf ايڪسٽينشن گسٽ لاءِ، JSF نحو کي نمايان ڪيو ويندو). ھتي آھي ھڪڙي فهرست سڀني سپورٽ ٿيل نحو جي .

#4 پل جي درخواستن ۾ "جادو لفظ" استعمال ڪندي مسئلا بند ڪرڻ

اچو ته چئو ته توهان هڪ پل جي درخواست ٺاهي جيڪا مسئلي # 234 کي حل ڪري ٿي. توھان داخل ڪري سگھو ٿا "مسئلو حل ڪري ٿو #234" پنھنجي درخواست جي وضاحت ۾ (يا ڪٿي به تبديلي جي درخواست جي تبصري ۾). ان کان پوء، پل جي درخواست کي ضم ڪرڻ "خودڪار" مسئلو بند ڪندو. ٿڌو، اهو ناهي؟ هتي دستاويز ۾ هن بابت وڌيڪ معلومات آهي .

#5 تبصرن لاءِ لنڪ

ڇا توھان کي ڪڏھن ڪنھن مخصوص تبصري لاءِ ڪڙي ٺاھڻ جي ضرورت آھي ۽ خبر ناھي ڪيئن؟ اهي ڏينهن گذري ويا آهن ڇاڪاڻ ته مان توهان کي هڪ راز ۾ ڏيندس: تبصري جي لنڪ ٺاهڻ لاءِ، توهان صرف عنوان جي اڳيان تاريخ/وقت تي ڪلڪ ڪريو. ڏس، گيرون هاڻي هڪ فوٽو آهي!

#6 ڪوڊ لنڪ

تنهن ڪري توهان ڪوڊ جي مخصوص لائن ڏانهن هڪ لنڪ ٺاهڻ چاهيو ٿا. ھن حالت ۾، ھي ڪوشش ڪريو: کليل فائل ۾ مطلوب ڪوڊ جي اڳيان لائن نمبر تي ڪلڪ ڪريو. واهه، ڏسو؟ URL تبديل ٿي چڪو آهي، لائن نمبر هاڻي ان ۾ نظر اچي رهيو آهي! جيڪڏهن توهان SHIFT چيڪ کي دٻايو ۽ ٻئي لائن نمبر تي ڪلڪ ڪريو، پوء وائيلا! - URL ٻيهر تبديل ٿيندو ۽ قطار جي حد کي نمايان ڪيو ويندو. ھي URL ھاڻي ھن فائل ڏانھن اشارو ڪندو ۽ ھن حد تائين لائنن جي. پر انتظار ڪريو، اهو موجوده موضوع ڏانهن اشارو ڪري ٿو. ڇا جيڪڏهن فائل تبديل ٿي وڃي؟ توھان کي شايد ضرورت آھي، ھن صورت ۾، ھڪڙي مستقل لنڪ فائل کي ان جي موجوده حالت ۾. مان تمام سست آهيان، تنهنڪري مون مٿين سڀني جو هڪ اسڪرين شاٽ ورتو: رستي ۾، URLs بابت ...

#7 GitHub URL استعمال ڪندي ڪمانڊ لائن طور

UI استعمال ڪندي GitHub ذريعي نيويگيٽ ڪرڻ بلڪل آساني سان منظم ڪيو ويو آهي. پر ڪڏهن ڪڏهن، ڪنهن مخصوص هنڌ تي وڃڻ لاءِ، اهو تيزيءَ سان صرف ان کي URL ۾ ٽائپ ڪرڻ آهي. مثال طور، جيڪڏهن مان هڪ برانچ ڏانهن وڃڻ چاهيان ٿو جنهن تي آئون ڪم ڪري رهيو آهيان ۽ ڏسو ته اهو ماسٽر سان ڪيئن مقابلو ڪري ٿو، مان صرف ٽائيپ ڪري سگهان ٿو /compare/branchname repository name کان پوءِ. اهو مون کي ان شاخ لاءِ مختلف صفحي تي وٺي ويندو: پر اهي ماسٽر برانچ کان اختلاف آهن، پر جيڪڏهن مون انٽيگريشن برانچ سان اڳ ۾ ڪم ڪيو آهي، ته مان داخل ڪري سگهان ٿو /compare/integration-branch...my-branch URL ۾ هاٽڪي جي شوقينن لاءِ: CTRL+L يا CMD+L ڪرسر کي URL بار ڏانهن منتقل ڪري ٿو (گهٽ ۾ گهٽ ڪروم ۽ فائر فاڪس برائوزرن ۾). اهو، برائوزر جي خودڪار مڪمل ٿيڻ سان گڏ، شاخن جي وچ ۾ نيويگيٽ ڪرڻ تمام آسان بڻائي ٿو. پرو ٽپ: ڪروم جي خودڪار مڪمل تجويزن ذريعي نيويگيٽ ڪرڻ لاءِ تير جو استعمال ڪريو، ۽ تاريخ مان شيون هٽائڻ لاءِ SHIFT+DELETE کي دٻايو (مثال طور، برانچ کي ضم ڪرڻ کان پوءِ). (مون کي خبر ناهي ته انهن شارٽ ڪٽ ڪيز کي پڙهڻ آسان ٿيندو ته جيڪڏهن آئون انهن ۾ هڪ جاءِ رکان، جهڙوڪ SHIFT + DELETE. پر ٽيڪنيڪل طور تي ”+“ انهن جو حصو ناهي، تنهنڪري مون کي هي اختيار پسند ناهي. اهڙين شين جي ڪري مون کي رات جو ننڊ نه ايندي آهي، رونڊا.)

#8 مسئلن لاءِ لسٽون ٺاھيو

ڇا توھان چاھيو ٿا چيڪ بڪس پنھنجي مسئلي جي وضاحت ۾؟ ۽ ڇا توھان چاھيو ٿا ھڪڙو نفٽي ​​بار جھڙوڪ ”5 مان 2“ ظاهر ٿئي جڏھن توھان لسٽ مان ڪو مسئلو ڏسندا؟ ڪو مسئلو ناهي! توھان ھيٺ ڏنل نحو استعمال ڪندي انٽرويو چيڪ بڪس ٺاھي سگھو ٿا:

• اسڪرين جي ويڪر (انٽيجر)
• [x] سروس ورڪر سپورٽ
• [x] مدد حاصل ڪريو
• [ ] CSS flexbox سپورٽ
• [] حسب ضرورت عناصر

نحو: اسپيس، هائيفن، اسپيس، اوپننگ اسڪوائر بریکٹ، اسپيس (يا x)، بند اسڪوائر بريڪٽ، اسپيس ۽ ڪجھ لفظ. ان کان پوء، توهان اصل ۾ چيڪ ڪري سگهو ٿا / چيڪ ڪريو انهن بٽڻن کي چيڪ ڪريو! ڪجهه سببن لاء، اهو لڳي ٿو ته مون لاء ڪجهه قسم جي ٽيڪنيڪل جادو. توهان باڪس کي نشان لڳائي سگهو ٿا! ۽ ساڳئي وقت اصل متن بدلجي ٿو! اهو سوچڻ خوفناڪ آهي ته اهي اڳتي ڇا ڪندا. ها، ۽ جيڪڏهن اهو مسئلو آهي پروجيڪٽ پينل ۾، ته پوءِ ترقي اتي به ڏيکاري ويندي: جيڪڏهن توهان نٿا سمجهو ته منهنجو مطلب ڇا آهي "پروجيڪٽ پينل" - هيٺ پڙهو. هن صفحي تي صرف ڪجهه سينٽي ميٽر هيٺ.

GitHub ۾ #9 پروجيڪٽ پينل

وڏن منصوبن لاءِ مون هميشه استعمال ڪيو آهي جيرا. ۽ منهنجي ذاتي منصوبن لاءِ، مون هميشه استعمال ڪيو آهي Trello. مون کي واقعي اهي ٻئي اوزار پسند آهن. جڏهن مون ڪجهه هفتا اڳ سکيو ته گيٽ هب پنهنجو اختيار پيش ڪيو، صحيح مخزن جي پروجيڪٽس ٽيب ۾ ، مون سوچيو ته اهو ڪمن جي سيٽ کي نقل ڪرڻ جو احساس ٿيندو جيڪو آئون اڳ ۾ ئي Trello ۾ ڪم ڪري رهيو آهيان. هتي ڪجھ به مذاق نه آهي. ۽ ھاڻي ساڳي شيء GitHub منصوبي ۾: تدريجي طور تي توهان جون اکيون گهٽ-برعڪس تصوير جي عادت پوندي رفتار جي خاطر، مون مٿين سڀني کي شامل ڪيو آهي نوٽس، مطلب ته اهي نه آهن "حقيقي" GitHub مسئلا. پر GitHub ۾ مسئلي جي انتظام جي طاقت باقي مخزن سان ان جي انضمام ۾ آهي - تنهنڪري اهو بهتر آهي ته موجوده مسئلن کي مخزن کان ڊيش بورڊ ۾ شامل ڪيو وڃي. ڪلڪ ڪريو ڪارڊ شامل ڪريو مٿي ساڄي ڪنڊ ۾ ۽ ڳولھيو جيڪو توھان شامل ڪرڻ چاھيو ٿا. هي اهو آهي جتي خاص ڳولها نحو ڪم ۾ اچي ٿو : مثال طور، ٽائيپ is:pr is:open ۽ توهان ڪنهن به کليل پل درخواست کي پينل تي ڇڪي سگهو ٿا، يا label:bug جيڪڏهن توهان کي ڪجهه بگ درست ڪرڻ جي ضرورت آهي. توهان پڻ موجوده نوٽس کي مسئلن ۾ تبديل ڪري سگهو ٿا. ۽ آخرڪار، موجوده مسئلي جي فارم مان، ساڄي پينل ۾ پروجيڪٽ ۾ شامل ڪريو. اهو انهي پروجيڪٽ پينل جي ٽريج لسٽ ۾ ويندو، تنهنڪري توهان اهو چونڊي سگهو ٿا ته ڪهڙو ڪالم ان ۾ رکڻو آهي جڏهن هڪ "ٽاسڪ" جو بيان ساڳيو مخزن ۾ آهي جيئن ڪوڊ هن ڪم کي لاڳو ڪري ٿو، اهو تمام (تمام) آسان آهي. هن جو مطلب اهو آهي ته هاڻي کان ڪيترن ئي سالن کان، توهان کي هلائڻ جي قابل ٿي ويندا گيٽ بليم ڪوڊ جي هڪ لائن تي ۽ انهي مسئلي جي مڪمل طور تي معلوم ڪرڻ جي قابل ٿي ويندي جيڪا انهي لائن جي ڪري ٿي، ان کي ٽريڪ ڪرڻ جي بغير جيرا / ٽريلو / ٻي جاء تي.

فال

گذريل ٽن هفتن کان مان تجربا ڪري رهيو آهيان GitHub ۾ سڀ ڪجهه ڪرڻ جي بدران جيرا (هڪ ننڍڙي منصوبي تي، ڪنبن جي طرز تي) ۽ ان سان پيار ڪرڻ. پر مان اهو تصور نه ٿو ڪري سگهان هڪ اسڪرم پروجيڪٽ لاءِ جتي ترقي جي رفتار ۽ ان وانگر جو اندازو لڳايو وڃي ۽ صحيح حساب ڪيو وڃي. سٺي خبر اها آهي ته GitHub منصوبن ۾ تمام ٿورڙا "خاص خاصيتون" آهن جيڪي ٻئي سسٽم ڏانهن سوئچنگ گهڻو وقت نه وٺندا. پوء ان کي ڪوشش ڏيو ۽ ڏسو ته توهان کي ڪيترو پسند آهي. مون کي خبر ناهي ته اهو ڪيترو اهم آهي، پر مون ZenHub بابت ٻڌو ۽ 10 منٽ اڳ پهريون ڀيرو ان کي کوليو. اهو بنيادي طور تي GitHub جو هڪ واڌارو آهي جتي توهان مسئلن جي شرح ڪري سگهو ٿا ۽ "ايڪس" ۽ انحصار ٺاهي سگهو ٿا. ترقي جي رفتار ۽ برن آئوٽ جا گراف آهن. اهو لڳي ٿو ته اهو صرف هڪ عجيب شيء آهي. وڌيڪ پڙهڻ: GitHub منصوبن تي دستاويز.

#10 گويڪي

صفحن جي غير ترتيب ڏنل سيٽ لاءِ- جھڙوڪ وڪيپيڊيا- گيٽ ھب وڪي (جنھن کي ھاڻي مان صرف Gwiki سڏيندس) وڏو آھي. صفحن جي هڪ منظم سيٽ لاءِ - مثال طور، توهان جي دستاويز وانگر - ايترو گهڻو نه. اهو ظاهر ڪرڻ جو ڪو به طريقو ناهي ته ”هي صفحو ان جو هڪ ٻار آهي“؛ اتي ڪا به اهڙيون سهولتون شيون نه آهن جيئن ”اڳيون سيڪشن“ ۽ ”اڳيون سيڪشن“ بٽڻ. Hansel ۽ Gretel ضرور ھتي گم ٿي ويندا، ڇو ته ھتي ڪو به ”بريڊ ڪرمبس“ (خاص ڊيبگنگ آپريٽر - تقريباً ٽرانس.) نه آھن. (ليکڪ جو نوٽ: ڇا توهان هي ڪهاڻي پڙهي آهي ؟ اهو صرف غير انساني آهي. ٻه نوجوان ٺڳ هڪ غريب بکايل پوڙهي عورت کي قتل ڪري، ان کي پنهنجي ئي تنور ۾ جيئرو ساڙي ڇڏيندا آهن. ۽ يقينا، ڪنهن کي سمجهڻ لاء مڪمل گندگي ڇڏيندي آهي. منهنجو خيال آهي ته اهو ڇو آهي. نوجوان ماڻهو اڄڪلهه جهنم وانگر حساس آهن - اهي ڪهاڻيون جيڪي ٻارن کي سمهڻ وقت پڙهيا آهن اهي اڄڪلهه ڪافي ظالم ناهن!) اڳتي وڌو - حقيقي طور تي گويڪي کي آزمائڻ لاءِ، مون NodeJS کان ڪجھ صفحا wiki صفحن جي طور تي داخل ڪيا، پوءِ هڪ ڪسٽم ٺاهيو سائڊبار سائيٽ جي حقيقي ساخت کي نقل ڪرڻ لاء. هي سائڊبار هميشه موجود آهي، جيتوڻيڪ موجوده صفحي کي نمايان نه ڪيو ويو آهي. لنڪس کي دستي طور تي برقرار رکڻو پوندو، پر مجموعي طور تي هر شي ٺيڪ ڪم ڪري ٿي. جيڪڏهن توهان چاهيو ٿا، توهان هڪ نظر وٺي سگهو ٿا : اهو مشڪل سان مقابلو ڪري سگهي ٿو ڪنهن شيءِ سان GitBook (جيڪو استعمال ٿئي ٿو Redux دستاويزن ۾ ) يا هڪ خاص ويب سائيٽ. پر اھو اڳ ۾ ئي ھڪڙو سٺو 80٪ آھي ۽ توھان جي مخزن ۾ سڀ ڪجھ صحيح آھي. مان صرف هن جو مداح آهيان. مان صلاح ڏيان ٿو ته جيڪڏھن توھان ھڪڙي README.md فائل کي ختم ڪري ڇڏيو آھي ۽ توھان کي صارف مينوئل يا وڌيڪ تفصيلي دستاويزن لاءِ ڪيترن ئي مختلف صفحن جي ضرورت آھي، اھو سمجھ ۾ اچي ٿو ته Gwiki سان گڏ رھو. جيڪڏهن ساخت / نيويگيشن جي کوٽ توهان کي پريشان ڪري، ڪنهن ٻئي ڏانهن وڃو.

#11 GitHub صفحا

توهان شايد اڳ ۾ ئي ڄاڻو ٿا ته GitHub صفحا استعمال ڪري سگھجن ٿيون جامد ويب سائيٽ کي ميزباني ڪرڻ لاء. ۽ جيڪڏھن توھان نه ڄاڻو، پوء توھان ڄاڻو ٿا. بهرحال، هي سيڪشن هڪ وڌيڪ مخصوص موضوع لاءِ وقف ڪيو ويو آهي: ويب سائيٽ ٺاهڻ لاءِ Jekyll استعمال ڪندي. ان جي آسان ترين شڪل ۾، GitHub Pages + Jekyll هڪ سٺي ڏسڻ واري موضوع کي استعمال ڪندي README.md فائل کي پيش ڪري سگھي ٿو. مثال طور، منهنجي readme صفحي تي هڪ نظر وٺو about-github : جيڪڏهن توهان هن GitHub سائيٽ لاء سيٽنگون ٽيب تي ڪلڪ ڪريو، GitHub صفحن کي فعال ڪريو، ۽ Jekyll موضوع کي چونڊيو ... پوء اسان کي Jekyll موضوع جي انداز ۾ هڪ صفحو حاصل ڪندو : توهان وري ٺاهي سگهو ٿا هڪ مڪمل جامد سائيٽ بنيادي طور تي آساني سان قابل تدوين مارڪ اپ فائلن جي بنياد تي، بنيادي طور تي GitHub کي CMS ۾ تبديل ڪندي. جيتوڻيڪ مون اصل ۾ اهو استعمال نه ڪيو آهي، هي آهي ڪيئن ويب سائيٽون بوٽ اسٽراپ فريم ورڪ استعمال ڪندي React استعمال ڪندي ٺاهيون ويون آهن، تنهنڪري ان بابت ڪجهه به خوفناڪ ناهي. مان نوٽ ڪريان ٿو ته روبي کي مقامي مشين تي هلڻ گهرجي (هتي ونڊوز استعمال ڪندڙ سمجهه ۾ نظر ڦيرائيندا ۽ ٻئي طرف ويندا، macOS استعمال ڪندڙ چوندا: ”ڇا مسئلو آهي، توهان ڪيڏانهن وڃي رهيا آهيو؟ روبي هڪ آفاقي پليٽ فارم آهي! هتي هڪ GEMS پڻ آهي. پيڪيج مئنيجمينٽ سسٽم!") (اهو پڻ نوٽ ڪرڻ جي قابل آهي ته "جارحانه يا خطرو ڪندڙ مواد يا رويي" جي GitHub صفحن تي اجازت ناهي، تنهنڪري توهان هانسل ۽ گريٽيل ڪهاڻي جو پنهنجو نسخو اتي پوسٽ ڪرڻ جي قابل نه هوندا).

منهنجي خيال ۾

وڌيڪ مون ڏٺو GitHub Pages + Jekyll combination (هن آرٽيڪل لاءِ)، وڌيڪ مون سوچيو ته سڄو خيال عجيب لڳندو هو. "گهٽ ۾ گهٽ ڪوشش سان پنهنجي ويب سائيٽ ٺاهڻ" جو خيال وڏو آهي. پر ان تي ڪم ڪرڻ لاءِ توھان کي اڃا تائين مقامي مشين تي موجوده ورزن جي ضرورت آھي. ۽ ڪجھ لاءِ ”سادو“ تمام گھڻا ڪمانڊ لائن ڪمانڊ آھن. مون شروع ڪرڻ واري سيڪشن ۾ ستن صفحن جي ذريعي اسڪيم ڪيو ۽ محسوس ڪيو ته ان جي باري ۾ صرف هڪ سادي شيء آهي . ۽ مون بنيادي صفحي لاءِ سادي نحو يا هڪ سادي ”ٽمپليٽنگ ميڪنزم جي بنياد تي Liquid ٻولي“ جي بنيادي ڳالهين کي به نه سمجهيو آهي. مان بلڪه هڪ ويب سائيٽ پاڻ لکندس! ايماندار ٿيڻ لاءِ، مان ٿورڙي حيران آهيان ته فيسبوڪ اهو استعمال ڪري رهيو آهي 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)}} />
      );
    }
}

(مان 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 ڊولپر ٽولز ڊارڪ تھیم (بلٽ ان، توهان کي صرف ان کي فعال ڪرڻ جي ضرورت آهي) ۽ ڪروم لاءِ ايٽم ون ڊارڪ ٿيم .

بٽ بڪ

سختي سان ڳالهائڻ، اهو هتي مڪمل طور تي مناسب ناهي، پر مان صرف مدد نه ٿو ڪري سگهان پر Bitbucket جو ذڪر ڪري سگهان ٿو. ٻه سال اڳ مون هڪ منصوبو شروع ڪيو ۽ اڌ ڏينهن گذاريو بهترين گٽ هوسٽنگ چونڊڻ. تنهن ڪري، Bitbucket هڪ اهم فرق سان کٽيو. انهن جي ڪوڊ جو جائزو وٺڻ واري پائپ لائن مقابلي کان تمام گهڻو اڳتي آهي (اهو ڊگهو هو GitHub کان اڳ به هڪ نظرثاني ڪندڙ جو تصور هو). ان کان پوء، GitHub پڻ جائزو ورتو آهي. بدقسمتي سان، مون کي گذريل سال تائين Bitbucket استعمال ڪرڻ جو موقعو نه مليو آهي - شايد اهي اڳتي وڌي ويا آهن ڪجهه ٻيهر. تنهن ڪري مان سفارش ڪريان ٿو ته جيڪي ذميوار آهن گٽ هوسٽنگ سروس چونڊڻ جا پڻ ڌيان ڏين Bitbucket.

نتيجو

اهو ئي سڀ ڪجهه آهي! مون کي اميد آهي ته مان توهان کي گهٽ ۾ گهٽ ٽي شيون ٻڌائڻ جي قابل ٿي چڪو آهيان جيڪي اڳ ۾ توهان کي اڻڄاتل هئا. ۽ مان پڻ اميد ڪريان ٿو ته توهان منهنجو مضمون پڙهڻ سٺو وقت گذاريو.