12 คุณสมบัติที่น่าทึ่งของ GitHub

สำหรับชีวิตผม ผมคิดอินโทรอะไรไม่ได้เลย ดังนั้น...

#1 การแก้ไขโค้ดบน GitHub.com

ฉันจะเริ่มต้นด้วยสิ่งที่ฉันคิดว่าทุกคนรู้อยู่แล้ว (แม้ว่าโดยส่วนตัวแล้วฉันจะไม่รู้เรื่องนี้เมื่อสัปดาห์ที่แล้วก็ตาม) เมื่อดูไฟล์ข้อความใดๆ บน GitHub ในพื้นที่เก็บข้อมูลใดๆ คุณจะเห็นดินสอเล็กๆ ที่มุมขวาบน หากคุณคลิกคุณสามารถแก้ไขไฟล์นี้ได้ เมื่อเสร็จแล้ว คลิกเสนอการเปลี่ยนแปลงไฟล์ จากนั้น GitHub จะสร้างทางแยกและคำขอดึง น่าทึ่งใช่มั้ยล่ะ? เขาสร้างทางแยกเอง! ไม่จำเป็นต้องแยกและอัปโหลดโค้ดถึงตัวคุณเอง ทำการเปลี่ยนแปลงในเครื่อง และส่งกลับไปที่ GitHub ด้วย Pull Request สะดวกมากหากคุณต้องการแก้ไขเพียงเล็กน้อย ไม่ใช่คำขอดึงที่แท้จริง

#2 การแทรกรูปภาพ

คำอธิบายปัญหาไม่ได้จำกัดอยู่เพียงข้อความแสดงความคิดเห็นเท่านั้น คุณรู้ไหมว่าคุณสามารถวางภาพได้โดยตรงจากคลิปบอร์ด เมื่อวางแล้ว คุณจะเห็นว่ามันอัปโหลดแล้ว (ไม่ต้องสงสัยเลย) และกลายเป็นมาร์กอัปเพื่อแสดงรูปภาพ สง่างาม!

#3 การจัดรูปแบบโค้ด

หากคุณต้องการเขียนโค้ดจำนวนหนึ่ง ให้เริ่มต้นด้วย backticks สามอัน แล้ว GitHub จะพยายามเดาว่าคุณกำลังเขียนภาษาโปรแกรมอะไร แต่หากคุณโพสต์โค้ดในภาษาการเขียนโปรแกรม เช่น Vue, Typescript หรือ JSX คุณสามารถระบุภาษาอย่างชัดเจนเพื่อให้การเน้นไวยากรณ์ถูกต้อง สังเกต ``` jsx ในบรรทัดแรก: ...รับรองการแสดงข้อมูลโค้ดที่ถูกต้อง: (วิธีนี้ใช้กับ Gist ด้วยเช่นกัน หากคุณระบุส่วนขยาย .jsf สำหรับส่วนสำคัญ ไวยากรณ์ JSF จะถูกเน้น) นี่คือรายการไวยากรณ์ ที่รองรับทั้งหมด

#4 การปิดปัญหาโดยใช้ “คำวิเศษ” ในคำขอดึง

สมมติว่าคุณสร้าง Pull Request ที่แก้ไขปัญหา #234 คุณสามารถแทรกข้อความ "แก้ไขปัญหา #234" ลงในคำอธิบายคำขอของคุณ (หรือที่ใดก็ได้ในความคิดเห็นของคำขอเปลี่ยนแปลง) หลังจากนี้ การรวม Pull Request เข้าด้วยกันจะปิดปัญหา "โดยอัตโนมัติ" เจ๋งใช่มั้ย? นี่คือข้อมูลเพิ่มเติมเกี่ยวกับสิ่งนี้ในเอกสารประกอบ

#5 ลิงก์ไปยังความคิดเห็น

คุณเคยจำเป็นต้องสร้างลิงก์ไปยังความคิดเห็นเฉพาะเจาะจงแต่ไม่รู้ว่าต้องทำอย่างไรหรือไม่? วันเหล่านั้นผ่านไปนานแล้วเพราะฉันจะแจ้งให้คุณทราบ: หากต้องการสร้างลิงก์ไปยังความคิดเห็น คุณเพียงคลิกวันที่/เวลาถัดจากชื่อเรื่อง ดูสิ gaearon มีรูปถ่ายแล้ว!

#6 ลิงค์รหัส

ดังนั้นคุณจึงต้องการสร้างลิงก์ไปยังบรรทัดโค้ดเฉพาะ ในกรณีนี้ ให้ลองทำดังนี้: คลิกที่หมายเลขบรรทัดถัดจากรหัสที่ต้องการในไฟล์ที่เปิดอยู่ ว้าวเห็นไหม? URL มีการเปลี่ยนแปลง หมายเลขบรรทัดปรากฏให้เห็นแล้ว! หากคุณกดปุ่ม SHIFT ค้างไว้แล้วคลิกที่หมายเลขบรรทัดอื่น แสดงว่า voila! – URL จะเปลี่ยนอีกครั้งและช่วงของแถวจะถูกเน้น URL นี้จะชี้ไปที่ไฟล์นี้และช่วงบรรทัดนี้ แต่เดี๋ยวก่อน มันชี้ไปที่เธรดปัจจุบัน จะทำอย่างไรถ้าไฟล์มีการเปลี่ยนแปลง? ในกรณีนี้ คุณอาจจำเป็นต้องมีลิงก์ถาวรไปยังไฟล์ในสถานะปัจจุบัน ฉันขี้เกียจมาก เลยถ่ายรูปหน้าจอของสิ่งที่กล่าวมาทั้งหมดไว้หนึ่งภาพ: โดยวิธีการเกี่ยวกับ URL...

#7 การใช้ GitHub URL เป็นบรรทัดคำสั่ง

การนำทางผ่าน GitHub โดยใช้ UI นั้นได้รับการจัดระเบียบอย่างสะดวกมาก แต่บางครั้ง หากต้องการไปยังสถานที่ใดสถานที่หนึ่ง การพิมพ์ลงใน 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 เฟล็กซ์บ็อกซ์
• [ ] องค์ประกอบที่กำหนดเอง

ไวยากรณ์:ช่องว่าง, ยัติภังค์, ช่องว่าง, วงเล็บเหลี่ยมเปิด, ช่องว่าง (หรือ x), วงเล็บเหลี่ยมปิด, ช่องว่าง และคำบางคำ หลังจากนั้น คุณสามารถเลือก/ยกเลิกการเลือกปุ่มเหล่านี้ได้จริง! ด้วยเหตุผลบางอย่าง มันดูเหมือนเป็นเวทย์มนตร์ทางเทคนิคบางอย่างสำหรับฉัน คุณสามารถทำเครื่องหมายที่ช่อง! และในขณะเดียวกันข้อความต้นฉบับก็เปลี่ยนไป! มันน่ากลัวที่จะคิดว่าพวกเขาจะเกิดอะไรขึ้นต่อไป โอ้ และหากปัญหานี้อยู่ในแผงโครงการ ความคืบหน้าก็จะแสดงที่นั่นเช่นกัน: หากคุณไม่เข้าใจสิ่งที่ฉันหมายถึงโดย "แผงโครงการ" - อ่านด้านล่าง หน้านี้ต่ำกว่าสองสามเซนติเมตร

#9 แผงโครงการใน GitHub

สำหรับโปรเจ็กต์ขนาดใหญ่ ฉันมักจะใช้จิราเสมอ และสำหรับโปรเจ็กต์ส่วนตัวของฉัน ฉันใช้ Trello มาโดยตลอด ฉันชอบเครื่องมือทั้งสองนี้มาก เมื่อฉันได้เรียนรู้เมื่อไม่กี่สัปดาห์ที่ผ่านมาว่า GitHub เสนอตัวเลือกของตัวเองในแท็ บ โครงการของพื้นที่เก็บข้อมูล ฉันคิดว่ามันสมเหตุสมผลที่จะทำซ้ำชุดงานที่ฉันทำงานด้วยอยู่แล้วใน Trello ไม่มีอะไรตลกที่นี่ และตอนนี้สิ่งเดียวกันในโครงการ GitHub: ดวงตาของคุณจะค่อยๆ คุ้นเคยกับภาพที่มีคอนทราสต์ต่ำ เพื่อความรวดเร็ว ฉันได้เพิ่มทั้งหมดข้างต้นเป็นบันทึกย่อ ซึ่งหมายความว่าปัญหาเหล่านั้นไม่ใช่ปัญหา GitHub "ของจริง" แต่พลังของการจัดการปัญหาใน GitHub นั้นอยู่ที่การบูรณาการกับพื้นที่เก็บข้อมูลที่เหลือ ดังนั้นจึงน่าจะดีกว่าถ้าเพิ่มปัญหาที่มีอยู่จากพื้นที่เก็บข้อมูลไปยังแดชบอร์ด คลิกเพิ่มการ์ดที่มุมขวาบนแล้วค้นหาสิ่งที่คุณต้องการเพิ่ม นี่คือจุดที่ไวยากรณ์การค้นหา พิเศษมีประโยชน์ เช่น พิมพ์is:pr is:openและคุณสามารถลาก Pull Request ที่เปิดอยู่ไปไว้บนแผงควบคุม หรือlabel:bugหากคุณต้องการแก้ไขข้อบกพร่องบางอย่าง คุณยังสามารถแปลงบันทึกย่อที่มีอยู่ให้เป็นประเด็นได้ และสุดท้าย จากแบบฟอร์มปัญหาที่มีอยู่ ให้เพิ่มลงในโปรเจ็กต์ในแผงด้านขวา มันจะเข้าไปในรายการ triage ของแผงโปรเจ็กต์นั้น เพื่อให้คุณสามารถเลือกคอลัมน์ที่จะใส่ได้ เมื่อคำอธิบายของ “งาน” อยู่ในที่เก็บข้อมูลเดียวกันกับโค้ดที่ใช้งานงานนี้ จะสะดวก (มาก) มาก ซึ่งหมายความว่าในอีกหลายปีต่อจากนี้ คุณจะสามารถเรียกใช้git ตำหนิบรรทัดของโค้ดและค้นหาปัญหาทั้งหมดที่นำไปสู่บรรทัดนั้น โดยไม่ต้องติดตามมันทั้งหมดใน Jira/Trello/ที่อื่น

ข้อบกพร่อง

ในช่วงสามสัปดาห์ที่ผ่านมา ฉันได้ทดลองทำทุกอย่างใน GitHub แทนที่จะเป็น Jira (ในโปรเจ็กต์ขนาดเล็ก สไตล์ Kanban) และชอบมันมาก แต่ฉันไม่สามารถจินตนาการถึงสิ่งนี้สำหรับโครงการ Scrum ที่ความเร็วการพัฒนาและสิ่งที่คล้ายกันจำเป็นต้องได้รับการประเมินและคำนวณอย่างถูกต้อง ข่าวดีก็คือโครงการ GitHub มี "คุณสมบัติพิเศษ" น้อยมากจนการเปลี่ยนไปใช้ระบบอื่นใช้เวลาไม่นาน ดังนั้นลองดูว่าคุณชอบมันมากแค่ไหน ฉันไม่รู้ว่าสิ่งนี้สำคัญแค่ไหน แต่ฉันได้ยินเกี่ยวกับZenHubและเปิดมันเป็นครั้งแรกเมื่อ 10 นาทีที่แล้ว โดยพื้นฐานแล้วเป็นส่วนขยายของ GitHub ที่คุณสามารถให้คะแนนปัญหาและสร้าง "มหากาพย์" และการพึ่งพาได้ มีกราฟของความเร็วการพัฒนาและความเหนื่อยหน่าย ดูเหมือนว่ามันเป็นเพียงสิ่งมหัศจรรย์ อ่านเพิ่มเติม: เอกสาร GitHub เกี่ยวกับโครงการ

#10 กวิกิ

สำหรับชุดของหน้าที่ไม่มีโครงสร้าง เช่น Wikipedia GitHub Wiki (ซึ่งต่อจากนี้จะเรียกว่า Gwiki) นั้นดีมาก สำหรับชุดเพจที่มีโครงสร้าง เช่น เอกสารของคุณ ยังไม่มากนัก ไม่มีทางที่จะระบุว่า "หน้านี้ลูกของหน้านั้น" ไม่มีสิ่งที่สะดวกเช่นปุ่ม "ส่วนถัดไป" และ "ส่วนก่อนหน้า" ฮันเซลและเกรเทลคงจะหลงทางที่นี่อย่างแน่นอน เพราะที่นี่ไม่มี "เบรดครัมบ์" (ตัวดำเนินการแก้ไขจุดบกพร่องพิเศษ - ประมาณทรานส์) ที่นี่เช่นกัน (หมายเหตุผู้เขียน: คุณเคยอ่านเรื่องนี้ไหม มันไร้มนุษยธรรม สองหนุ่มอันธพาลฆ่าหญิงชราผู้หิวโหยและเผาเธอทั้งเป็นในเตาอบของเธอเองและแน่นอนว่าทิ้งความยุ่งเหยิงไว้อย่างสมบูรณ์โดยไม่มีใครเข้าใจ ฉันคิดว่านั่นคือเหตุผลว่าทำไม คนหนุ่มสาวทุกวันนี้อ่อนไหวมาก – เรื่องราวที่เด็ก ๆ อ่านก่อนนอนยังไม่โหดร้ายพอ!) ก้าวต่อไป – เพื่อทดลองใช้ Gwiki จริง ฉันป้อนสองสามหน้าจาก NodeJS เป็นหน้า wiki จากนั้นจึงสร้างแบบกำหนดเอง แถบด้านข้างเพื่อจำลองโครงสร้างจริงของไซต์ แถบด้านข้างนี้จะอยู่ที่นั่นเสมอ แม้ว่าหน้าปัจจุบันจะไม่ได้ไฮไลต์ก็ตาม ลิงก์จะต้องได้รับการดูแลด้วยตนเอง แต่โดยรวมแล้วทุกอย่างทำงานได้ดี หากคุณต้องการคุณสามารถดู : สิ่งนี้แทบจะไม่สามารถแข่งขันกับบางอย่างเช่น GitBook (ซึ่งใช้ใน เอกสาร Redux ) หรือเว็บไซต์ที่ออกแบบตามความต้องการได้ แต่นี่เป็น 80% ที่ดีอยู่แล้วและทุกอย่างถูกต้องในพื้นที่เก็บข้อมูลของคุณ ฉันแค่เป็นแฟนเรื่องนี้ ฉันขอแนะนำว่าหากคุณขยายขนาดไฟล์ README.md ไฟล์เดียวออกไป และต้องการหน้าต่างๆ มากมายสำหรับคู่มือผู้ใช้หรือเอกสารประกอบที่มีรายละเอียดมากขึ้น ก็ควรใช้ Gwiki ต่อไป หากการขาดโครงสร้าง/การนำทางรบกวนจิตใจคุณ ให้เปลี่ยนไปใช้อย่างอื่น

#11 หน้า GitHub

คุณอาจรู้แล้วว่า GitHub Pages สามารถใช้เพื่อโฮสต์เว็บไซต์แบบคงที่ได้ และถ้าคุณไม่รู้คุณก็รู้ตอนนี้ อย่างไรก็ตาม ส่วนนี้มีไว้สำหรับหัวข้อที่เฉพาะเจาะจงมากขึ้น: การใช้Jekyllเพื่อสร้างเว็บไซต์ ในรูปแบบที่ง่ายที่สุด GitHub Pages + Jekyll สามารถเรนเดอร์ไฟล์ README.md โดยใช้ธีมที่ดูดี ตัวอย่างเช่น ดูหน้า readme ของฉันจากabout-github : หากคุณคลิกที่แท็บการตั้งค่าสำหรับไซต์ GitHub นี้ ให้เปิดใช้งาน GitHub Pages และเลือกธีม Jekyll... จากนั้นเราจะได้เพจสไตล์ธีม Jekyll : จากนั้น คุณสามารถสร้างไซต์แบบคงที่ทั้งหมดโดยใช้ไฟล์มาร์กอัปที่แก้ไขได้ง่ายเป็นหลัก โดยเปลี่ยน GitHub ให้เป็น CMS แม้ว่าฉันจะไม่ได้ใช้สิ่งนี้จริงๆ แต่นี่คือวิธีที่เว็บไซต์ถูกสร้างขึ้นโดยใช้เฟรมเวิร์ก Bootstrap โดยใช้ React ดังนั้นจึงไม่มีอะไรน่ากลัวเกี่ยวกับเรื่องนี้ ฉันทราบว่า Ruby จะต้องทำงานบนเครื่องท้องถิ่น (ผู้ใช้ Windows ที่นี่จะแลกเปลี่ยนความเข้าใจและหันไปทางอื่น ผู้ใช้ macOS จะพูดว่า: “มีปัญหาอะไร คุณจะไปไหน Ruby เป็นแพลตฟอร์มสากล! นอกจากนี้ยังมี GEMS ระบบการจัดการแพ็คเกจ!”) ( เป็นที่น่าสังเกตว่าไม่อนุญาตให้ใช้ "เนื้อหาหรือพฤติกรรมที่ก้าวร้าวหรือคุกคาม" บนหน้า GitHub ดังนั้นคุณจะไม่สามารถโพสต์เรื่องราวของฮันเซลและเกรเทลในเวอร์ชันของคุณที่นั่นได้)

ความคิดเห็นของฉัน

ยิ่งฉันดูชุดค่าผสมของ GitHub Pages + Jekyll (สำหรับบทความนี้) มากเท่าไร ฉันคิดว่าแนวคิดทั้งหมดมีกลิ่นแปลกๆ มากขึ้นเท่านั้น แนวคิดในการ "สร้างเว็บไซต์ของคุณเองโดยใช้ความพยายามเพียงเล็กน้อย" เป็นสิ่งที่ดีมาก แต่ในการทำงานนี้ คุณยังคงต้องใช้เวอร์ชันปัจจุบันในเครื่องท้องถิ่น และสำหรับบางสิ่งที่ "เรียบง่าย" ก็มีคำสั่งบรรทัดคำสั่งมากเกินไป ฉันอ่านเจ็ดหน้าใน ส่วน เริ่มต้นใช้งานและรู้สึกว่าสิ่งเดียวที่เรียบง่ายเกี่ยวกับเรื่องนี้ก็คือฉัน และฉันไม่ได้เข้าใจไวยากรณ์ง่ายๆ สำหรับหน้าหลักหรือพื้นฐานของ “กลไกการสร้างเทมเพลตตามภาษา Liquid” ง่ายๆ ด้วยซ้ำ ฉันอยากจะเขียนเว็บไซต์ด้วยตัวเอง! พูดตามตรง ฉันรู้สึกประหลาดใจเล็กน้อยที่ 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 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สำหรับเบราว์เซอร์ Chrome (ซึ่งสามารถใช้ธีมกับเว็บไซต์ใดก็ได้) และ สไตล์ GitHub Dark สำหรับผู้เริ่มต้น เครื่องมือสำหรับนักพัฒนา GitHub ธีมสีเข้ม (ในตัว คุณเพียงแค่ต้องเปิดใช้งาน) และ ธีม Atom One Darkสำหรับ Chrome

บิทบัคเก็ต

พูดอย่างเคร่งครัด มันไม่เหมาะสมเลยที่นี่ แต่ฉันอดไม่ได้ที่จะพูดถึง Bitbucket สองปีที่แล้ว ฉันเริ่มโปรเจ็กต์และใช้เวลาครึ่งวันในการเลือกโฮสติ้ง git ที่ดีที่สุด ดังนั้น Bitbucket จึงได้รับชัยชนะด้วยส่วนต่างที่สำคัญ ไปป์ไลน์การตรวจสอบโค้ดของพวกเขานำหน้าคู่แข่งมาก (ซึ่งเป็นเวลานานก่อนที่ GitHub จะมีแนวคิดของผู้ตรวจสอบด้วยซ้ำ) ตั้งแต่นั้นมา GitHub ก็ได้รับคำวิจารณ์เช่นกัน น่าเสียดายที่ฉันไม่มีโอกาสใช้ Bitbucket ในปีที่แล้ว - บางทีพวกเขาอาจก้าวไปข้างหน้าในบางสิ่งอีกครั้ง ดังนั้นฉันขอแนะนำให้ผู้ที่รับผิดชอบในการเลือกบริการโฮสติ้ง git ควรให้ความสนใจกับ Bitbucket ด้วย

บทสรุป

นั่นคือทั้งหมด! ฉันหวังว่าฉันจะสามารถบอกคุณอย่างน้อยสามเรื่องที่คุณไม่เคยรู้จักมาก่อน และฉันหวังว่าคุณจะสนุกกับการอ่านบทความของฉัน