มีผู้รายงานบน Reddit และ StackExchange หลายรายว่าพบ Ransomeware commit หรือแม้กระทั่งล้างเนื้อหาใน repository (บางรายแจ้งว่าเนื้อหาในประวัติยังคงอยู่) แล้วทิ้งข้อความให้เจ้าของโอนเงินผ่าน Bitcoin 0.1 ฺBTC (ราวๆ $560) ไม่เช่นนั้นจะเผยแพร่เนื้อหา เช่น source code, keys ที่อยู่ใน repository เป็นสาธารณะ

ซึ่งจากรายงานพบว่าผู้ใช้งาน Git ที่พบปัญหาใช้บริการ Git ทั้งบน GitHub, Gitlab และ BitBucket และใช้ SourceTree ซึ่งเป็น Git GUI ของ Atlassian

ยังไม่มีรายละเอียดโดยชัดเจนว่า SourceTree เป็นต้นเหตุหรือไม่ และยังไม่มีข้อชี้แจงจาก Atlassian แต่อย่างใด

เพิ่มเติม: Gitlab รับทราบปัญหาแล้ว อยู่ระหว่างการสืบสวนเพิ่มเติม เบื้องต้นทราบว่าตัวข้อมูลไม่หายหากมี backup ที่อื่นๆ แต่มีความเป็นไปได้ว่าผู้โจมตีจะมีรหัสผ่านของผู้ใช้ฯ และทั้งหมดไม่ได้ใช้การยืนยันตัวตนแบบสองปัจจัย

Apache Software Foundation (ASF) ประกาศย้ายซอร์สโค้ดของมูลนิธิจำนวน 350 โครงการ 200 ล้านบรรทัด จากเดิมที่อยู่บน Git ของมูลนิธิเอง ขึ้นมาอยู่บน GitHub แทนทั้งหมด

เดิมที ASF มีระบบจัดการซอร์สโค้ดสองตัวคือ Subversion และ Git บนเซิร์ฟเวอร์ของตัวเอง แต่ช่วงหลังเมื่อ GitHub ได้รับความนิยมมากขึ้น นักพัฒนาในชุมชนก็อยากเห็นซอร์สโค้ดอยู่บน GitHub แทน ซึ่ง ASF ก็นำซอร์สโค้ดของบางโครงการขึ้น GitHub แบบ read-only มาได้สักระยะหนึ่ง และตัดสินใจย้ายระบบทั้งหมดตั้งแต่ช่วงปลายปี 2018

ที่ผ่านมา ASF ดำเนินการมานาน 20 ปี และมีการ commit โค้ดทั้งหมดเกิน 1,000 ล้านบรรทัด ถ้านับเป็นจำนวนการ commit คือ 3 ล้านครั้ง

Google เปิดตัว Cloud Source Repositories บริการฝากซอร์สโค้ดบน Git ของ Google Cloud โฉมใหม่ โดย Google ออกแบบหน้าตาใหม่ทั้งหมด และมีฟีเจอร์สำคัญคือการค้นหาโค้ดแบบใหม่ที่รวดเร็วและมีประสิทธิภาพ

Google บอกว่าบริการ Cloud Source Repositories ในส่วนของการค้นหาโค้ดนั้น ใช้โครงสร้างพื้นฐานเดียวกับระบบที่วิศวกร Google ใช้ค้นหาโค้ดทุกวัน ซึ่งทำงานได้ดีแม้จะเป็นโค้ดที่ผู้ใช้ mirror มาจาก GitHub หรือ BitBucket เองโดยไม่ได้โฮสต์ไว้บน Cloud Source Repositories ของ Google

Git ออกเวอร์ชันใหม่ 2.17.1 แก้ช่องโหว่ด้านความปลอดภัยที่สำคัญ 2 ตัว (CVE-2018-11233 และ 11235) ผู้ใช้ทุกคนควรอัพเดตกันด่วน

ปกติแล้ว Git จะโคลน repository จากเซิร์ฟเวอร์ โดยไม่ดึงไฟล์คอนฟิกบางอย่าง (เช่น .git/config) มายังเครื่องโลคัลด้วยเหตุผลด้านความปลอดภัย เพราะไม่มีอะไรยืนยันได้ว่าไฟล์คอนฟิกบนเซิร์ฟเวอร์จะฝังคำสั่งประสงค์ร้าย ที่สามารถรันบนเครื่องโลคัลได้อัตโนมัติ

อาการของช่องโหว่ CVE-2018-11235 คือในบางกรณีที่ repository มี submodule เป็นโฟลเดอร์ซ้อนอยู่อีกชั้น (เช่น ไลบรารีจากโครงการอื่นๆ) การโคลน submodule จะไม่เกิดการดึงข้อมูลข้ามเครือข่ายขึ้นจริงๆ (เพราะโคลน parent repository มาก่อนหน้านั้นแล้ว) แต่จะเป็นการดึงข้อมูลจาก parent ที่อยู่บนดิสก์แทน

กูเกิลประกาศโปรโตคอล Git v2 หลังจากโค้ดถูกรวมเข้าโครงการหลักไปแล้วเมื่อสัปดาห์ที่ผ่านมา โดยความสามารถสำคัญคือการเปิดให้เซิร์ฟเวอร์ฟิลเตอร์เฉพาะส่วนที่ไคลเอนต์สนใจได้

ในโครงการขนาดใหญ่มากๆ เช่น Chromium มีจำนวน branch และ tag ถึงห้าแสนรายการ เมื่อไคลเอนต์สั่ง fetch ข้อมูลล่าสุด (git fetch origin master) เซิร์ฟเวอร์จะส่งรายการ brach และ tag ทั้งหมดกลับไปยังไคลเอนต์ ทำให้มีข้อมูลหลายสิบเมกะไบต์ส่งไปมา

การใช้โปรโตคอลใหม่ ตัวไคลเอนต์จะต้องแจ้งว่าต้องการใช้เวอร์ชั่น 2 ล่วงหน้า โดยหากใช้ git+https ก็จะใช้การประกาศผ่าน HTTP Header หากใช้ผ่าน git+ssh ตัว sshd จะต้องรองรับ environment variable ที่ชื่อว่า GIT_PROTOCOL

GitLab ซอฟต์แวร์จัดการโครงการชื่อดัง ประกาศออกเวอร์ชันใหม่ 10.6 ที่สามารถทำงานร่วมกับซอร์สโค้ดที่เก็บบน GitHub ได้แล้ว

GitLab เป็นซอฟต์แวร์ที่พัฒนาขึ้นจาก Git โดยมีหน้าที่สองส่วนคือเก็บซอร์สโค้ด (repository) และการจัดการโครงการ (CI/CD ย่อมาจาก continuous integration and continuous delivery)

ที่ผ่านมา GitLab ต้องการให้ลูกค้าเก็บซอร์สโค้ดไว้บนโฮสต์ของตัวเอง แต่ในความเป็นจริง ผู้ใช้อาจเก็บซอร์สโค้ดไว้กับผู้ให้บริการรายอื่นๆ อยู่แล้ว และไม่อยากเปลี่ยนมาเก็บบน GitLab ทำให้สุดท้าย GitLab ต้องยอมเปิดกว้าง ทำงานร่วมกับผู้ให้บริการรายอื่นมากขึ้น

แนวทางของ GitLab จะเริ่มจากโฮสติ้งยอดนิยมอย่าง GitHub ก่อน แต่เปิดกว้างให้เชื่อมกับรายอื่นๆ (เช่น BitBucket) ผ่าน API ได้เช่นกัน

ปัจจุบัน ไมโครซอฟท์ถือเป็นผู้ใช้ Git รายใหญ่ที่สุดของโลก เพราะย้ายซอร์สโค้ดทั้งหมดของ Windows มาเก็บไว้บน Git โดยไมโครซอฟท์แก้ปัญหาเรื่องประสิทธิภาพของ Git ที่ต้องจัดการไฟล์จำนวนมากๆ ด้วยการสร้าง GVFS (Git Virtual File System) ขึ้นมาช่วย

ล่าสุดไมโครซอฟท์ประกาศในงานสัมมนา Microsoft Connect ว่าได้พันธมิตรรายใหญ่อย่าง GitHub เข้ามาเป็นผู้ใช้ GVFS อีกราย และใช้ GVFS สำหรับให้บริการลูกค้าจำนวนมากของ GitHub ด้วย (Bitbucket ซึ่งเป็นคู่แข่งของ GitHub ก็ทดสอบการใช้งาน GVFS ไปแล้วก่อนหน้านี้)

ไมโครซอฟท์เผยว่าย้ายซอร์สโค้ด Windows ทั้งหมดจากระบบ Source Depot ของตัวเอง มาสู่ Git เรียบร้อยแล้ว ส่งให้ไมโครซอฟท์มี git repository ที่ใหญ่ที่สุดในโลกในทันที

• จำนวนไฟล์ 3.5 ล้านไฟล์
• ขนาดรวม 300GB
• จำนวนทีมงาน 4,000 คน (ปัจจุบันย้ายมาแล้ว 3,500 คน)
• จำนวนกิ่ง 440 branch
• git push เฉลี่ย 8,421 ครั้งต่อวัน
• pull request 2,500 ครั้งต่อวัน
• การนำซอร์สโค้ดออกมาคอมไพล์ นับเป็นจำนวน 1,760 build ต่อวัน

กระบวนการย้ายระบบของไมโครซอฟท์เริ่มในเดือนมีนาคม โดยพนักงานกลุ่มแรก 2,000 คนจากทีม Windows OneCore ใช้งาน Source Depot ในวันศุกร์ เมื่อกลับมาเช้าวันจันทร์ก็เจอกับระบบใหม่ที่เป็น Git แทน

GitHub ประกาศ Atom เวอร์ชั่นใหม่ ที่ทำงานร่วมกับ GitHub ได้เต็มรูปแบบมากขึ้น โดยสามารถเลือก branch, หรือแก้ conflict จาก Atom ได้เลย

นอกจากการปรับปรุง Atom แล้วบริษัทยังเปิดตัว GitHub Desktop Beta พร้อมกัน โดยเป็นแอปพัฒนาด้วย Electron เช่นเดียวกับ Atom เอง โดยพัฒนาใหม่ทั้งหมดแยกจาก GitHub Desktop เดิม เนื่องจากเดิมพัฒนาแบบเนทีฟแล้วพบว่าการการรองรับแพลตฟอร์มใหม่ๆ ทำได้ยากมากทีมงานระบุว่าได้ทดลองเทคโนโลยีอื่นแล้วแต่สุดท้ายก็หันมาใช้ Electron

GitHub Desktop เดิมยังมีต่อไป

ที่มา - GitHub

GitHub เพิ่มฟีเจอร์ให้สามารถเลือกผู้ใช้ใน repo ยกเลิกรีวิว pull request ที่อยู่ใน protect branch ได้

ปีที่แล้ว GitHub ได้อัพเดตฟีเจอร์ใน pull request เช่น จัดการ, ร้องขอและยกเลิกรีวิวโค้ด รวมไปถึงสามารถตั้งค่า protect branch และจำกัดการ merge ได้ เพื่อช่วยให้การทำงานภายทีมได้รับผลตอบรับสม่ำเสมอและช่วยเพิ่มประสิทธิภาพของโค้ดในโปรเจคให้ดีขึ้น ล่าสุดได้เพิ่มการจำกัดผู้ที่สามารถยกเลิกรีวิว pull request ในโปรเจค

ตัวฟีเจอร์สามารถเลือกผู้ใช้ที่อยู่ในทีมเป็นคนสั่งยกเลิกรีวิวของ pull request ใน protect branch ได้ทันที เหมาะสำหรับ repo ที่ทำงานเป็นทีมหรือองค์กรและมีผู้รีวิวโค้ดอยู่ในทีม สามารถใช้งานได้แล้วโดยเปิดใช้การร้องขอรีวิว pull request ก่อน

ที่มา : GitHub

ไมโครซอฟท์เปิดตัวระบบไฟล์เสมือน GVFS (Git Virtual File System) ใช้เก็บข้อมูลในระบบ Git โดยเฉพาะ เพื่อให้ Git มีประสิทธิภาพมากขึ้นสำหรับเก็บซอร์สโค้ดขนาดใหญ่มากๆ

ไมโครซอฟท์อธิบายว่า Git ไม่ได้ถูกออกแบบมาให้เก็บไฟล์จำนวนมาก (ตัวอย่างคือซอร์สโค้ดของ Windows มีขนาด 270GB และจำนวนไฟล์ 3.5 ล้านไฟล์) เวลาทำงานกับไฟล์จำนวนมากๆ บางคำสั่งอย่าง git checkout หรือ git status ที่ต้องทำงานกับไฟล์ทั้งหมด ต้องใช้เวลานานเป็นหลายชั่วโมงกว่าจะเสร็จ

แต่ในทางปฏิบัติแล้ว การมี repo ใหญ่ขนาดนี้ไม่มีใครสั่งคอมไพล์ซอร์สโค้ดทั้งหมดอยู่แล้ว ใน repo ขนาด 3 ล้านไฟล์ อาจมีไฟล์ที่เราต้องใช้งานจริงๆ เพียงแค่ 50,000-100,000 ไฟล์เท่านั้น เราไม่ควรต้องรอนานขนาดนั้น

GitLab (คนละเจ้ากับ GitHub) ผู้ผลิตซอฟต์แวร์จัดการโครงการและผู้โฮสต์บริการ Git รายใหญ่มีปัญหาข้อมูลสูญหายจากความผิดพลาดของผู้ดูแลระบบ ทำให้บริการทั้งหมดต้องปิดตัวลงระหว่างทีมงานกำลังกู้คืนข้อมูล

รายงานความคืบหน้าของการกู้คืนข้อมูลพบว่าระบบสำรองข้อมูลอาจจะไม่ทำงานเพราะ pg_dump ใช้งานผิดเวอร์ชั่น โดยระบบฐานข้อมูลเป็น PostgreSQL 9.6 แต่ pg_dump กลับเป็นเวอร์ชั่น 9.2 และระบบสำรองข้อมูลขึ้น AWS S3 ก็ไม่ทำงานเช่นกัน

โครงการ Git ออกเวอร์ชัน 2.10.0 ของใหม่ที่สำคัญคือแสดงความคืบหน้าเมื่อสั่ง git push ส่งโค้ดไปที่เซิร์ฟเวอร์อย่างละเอียด บอกว่ากำลังทำงานอะไรอยู่ ส่งข้อมูลไปถึงไหนแล้ว สถานะของเซิร์ฟเวอร์เป็นอย่างไร (สำหรับคนที่ชอบความเงียบ สามารถใช้คำสั่ง git push --quiet ได้) ฟีเจอร์แสดงสถานะยังใช้กับคำสั่ง git clone ตอนดึงซอร์สออกมาด้วย

ฟีเจอร์อย่างอื่นคือการคอนฟิกสีสันของ Git terminal โดยสามารถแสดงตัวเอียง (italic) และขีดฆ่ากลาง (strikethrough) ได้แล้ว

ในโอกาสเดียวกัน ฝั่งของไมโครซอฟท์ก็ออก Git for Windows 2.10 มาด้วย

GitLab.com ผู้พัฒนาระบบจัดการโค้ดโอเพนซอร์สและบริการโฮสต์โค้ดประกาศความร่วมมือกับ DigitalOcean ให้บริการเซิร์ฟเวอร์ฟรีสำหรับผู้ที่วางโฮสต์บน GitLab.com โดยใช้ฟีเจอร์ GitLab Runner Autoscale

บริการฟรีจำกัดเฉพาะผูใช้ GitLab.com เท่านั้น ส่วนผู้ที่ดาวน์โหลด GitLab ไปติดตั้งเองสามารถขอรับโปรโมชั่น 10 ดอลลาร์ (ซึ่งเอาเข้าจริงก็ไม่ต่างจากโปรโมชั่นทั่วไปของ DigitalOcean) หรือหากเป็นลูกค้า GitLab Enterprise Edition จะได้อีเมลเสนอโปรโมชั่นเครดิตถึง 250 ดอลลาร์

เมื่อวานนี้ Laël Cellier รายงานช่องโหว่ remote code execution ซึ่งเป็นช่องโหว่บน Git ทุกรุ่นที่เก่ากว่า 2.7.1 ทำให้เกิด buffer overflow ได้เมื่อผู้ push หรือ clone โปรเจกต์ที่มีชื่อไฟล์ยาวหรือมีโครงสร้างไดเรกทอรีซ้อนกันมากๆ

ปัญหาดังกล่าวถูกแก้มาตั้งแต่ 8 กุมภาพันธ์ที่ผ่านมาในรุ่น 2.7.1 แต่ดูเหมือนว่าจะไม่ได้รับความสนใจเท่าใดนัก จนกระทั่งมีการนำช่องโหว่นี้ไปรายงานในเว็บไซต์ seclists ดังกล่าว

Git เป็นระบบจัดการซอร์ส (source code management หรือบางที่ก็เรียกว่า version control system) ตัวหนึ่งที่ได้รับความนิยมจากนักพัฒนาซอฟต์แวร์ในปัจจุบัน เพียงแค่หน้าที่หลักของมันในการติดตามการเปลี่ยนแปลงและเรียกคืนไฟล์ตามช่วงเวลาต่างๆ ก็ทำให้การทำงานโดยใช้ Git บริหารไฟล์มีประสิทธิภาพมากขึ้นหลายเท่าตัว

Atlassian บริษัทเจ้าของเว็บฝากซอร์ส Bitbucket (คู่แข่งรายสำคัญกับ GitHub) ออกฟีเจอร์ดีพลอยขึ้นสู่กลุ่มเมฆของ Amazon, Microsoft และ DigitalOcean ได้ภายในหน้าเว็บเลยทันที

เบื้องหลังความสามารถดังกล่าว สำเร็จได้ผ่านเครื่องมือ Bamboo ที่คอยจัดการงานด้าน CI (continuous integration) ร่วมกับ Bitbucket Connect ซึ่งเป็นส่วนเสริมสำหรับติดต่อกลุ่มเมฆ โดยปัจจุบันมีกลุ่มเมฆที่รองรับส่วนเสริมนี้แล้ว 3 เจ้า ได้แก่ AWS CodeDeploy จาก Amazon, Microsoft Azure และ DigitalOcean ครับ

GitHub ประกาศว่าจะปล่อย 2 ความสามารถใหม่ภายในไม่กี่สัปดาห์หน้า ได้แก่

GitHub ออกแอพ GitHub Desktop สำหรับ Windows และ OS X โดยแอพดังกล่าวจะมาแทนที่แอพ GitHub for Windows / Mac เดิมครับ

เท่าที่ลองเล่นคร่าวๆ ผมพบว่าระบบกิ่งก้านถูกออกแบบให้เข้าใจง่ายขึ้นมากครับ และการสั่งรวมกิ่งก้านที่ก่อให้เกิดข้อขัดแย้ง (merge conflict) ก็ทำงานได้อย่างถูกต้องไม่ต้องเปิดคอมมานด์ไลน์ขึ้นมาแก้ไขแล้ว

นอกจากนี้ หากใครยังใช้ Git ไม่คล่อง เมื่อเปิดโปรแกรมครั้งแรกจะมี tutorial เล็กๆ ช่วยแนะนำ best practice การใช้งานด้วยครับ

ดาวน์โหลดแอพได้จาก desktop.github.com

ที่มา: GitHub Blog

ไฮไลท์รอบนี้อยู่ที่คำสั่งย่อย git worktree สำหรับจัดการกับโค้ดโครงการเดียว แต่มีก๊อบปี้หลายชุดครับ

โดยหลักการของ worktree นั้น เกิดจากการที่บางครั้งเมื่อต้องทำงานกับโครงการที่ซับซ้อน เราอาจต้องการ checkout รุ่นต่างๆ ในโค้ดโครงการออกมาเป็นหลายไดเรกทอรี เช่น ในขณะที่กำลังทำงานอยู่ที่กิ่ง develop และต้องการสลับไปแก้ไขข้อผิดพลาดที่กิ่ง hotfix แต่ไม่ต้องการ checkout มาทับงานที่ทำอยู่ในไดเรกทอรีปัจจุบัน ท่าเดิมที่ใช้อาจจะเป็นการ clone โครงการออกไปยังไดเรกทอรีใหม่แล้วเริ่มทำงานกับกิ่ง hotfix ที่นั่น หากเปลี่ยนมาใช้ worktree คำสั่งจะหดสั้นเหลือเพียง

เราเพิ่งเห็นข่าว Google Code ประกาศปิดโครงการ ไปเมื่อเร็วๆ นี้ โดยคำแนะนำของกูเกิลคือให้ย้ายไปใช้ GitHub หรือ Bitbucket แทน

แต่ล่าสุดกูเกิลกลับเปิดตัวบริการลักษณะเดียวกันอย่างเงียบๆ ในชื่อว่า Google Cloud Source Repositories โดยเป็นสมาชิกหนึ่งของบริการ Google Cloud Platform

Google Cloud Source Repositories คือบริการ Git แบบโฮสต์อยู่บนคลาวด์ของกูเกิล (แบบเดียวกับ GitHub) แต่ก็เพิ่มฟีเจอร์ต่อเนื่องกันอย่าง Source Code Editor ผ่านเว็บเบราว์เซอร์ และ Cloud Debugger สำหรับดีบั๊กโค้ดที่รันอยู่บน Compute Engine หรือ App Engine ได้ด้วย

Git เป็นซอฟต์แวร์ version control ที่ได้รับความนิยมเป็นอย่างมากเพราะช่วยอำนวยความสะดวกในการจัดการซอร์สโค้ดในโครงการขนาดใหญ่ที่มีนักพัฒนาจำนวนมากได้ดี

โครงการโอเพนซอร์สหลายโครงการที่ใช้ Git เป็นหลักนิยมใช้บริการ GitHub ซึ่งเป็น Git hosting ที่มีเครื่องมืออำนวยความสะดวกในการทำงานอย่าง wiki, issue tracker ให้ใช้ได้ฟรีและในบางโครงการที่ต้องการความเป็นส่วนตัวเข้าถึงได้เฉพาะคนภายในก็สามารถตั้งเซิร์ฟเวอร์เองได้เช่นกัน

แม้ว่า Git จะถูกออกแบบให้สามารถทำงานแบบกระจาย (decentralized) แต่ก็ต้องพึ่งพาเซิร์ฟเวอร์สำหรับเก็บไฟล์ index และซอร์สโค้ด นักพัฒนาในโครงการยังจำเป็นต้องเข้าถึงเซิร์ฟเวอร์ผ่าน URL หากเซิร์ฟเวอร์มีปัญหาก็อาจทำให้การพัฒนาหยุดชะงักได้

ความสามารถใหม่รอบนี้คือ push แบบอันหนึ่งอันเดียว (atomic) ครับ เช่น

$ git push --atomic branch1 branch2

การกระทำนี้จะรับรองว่า การ push กิ่งทั้ง branch1 และ branch2 ต้องสำเร็จเท่านั้น ถึงทำการ push กิ่งทั้งสองได้ มิเช่นนั้นแล้วก็จะไม่มีกิ่งไหนที่ถูก push เลย

ในสถานการณ์ทั่วๆ ไปอาจจะไม่ได้ใช้ความสามารถนี้เท่าไหร่ แต่เมื่อต้องทำระบบอัตโนมัติ มันจะช่วยลดความผิดพลาดได้ครับ

ส่วนความสามารถอื่นๆ ที่ถูกปรับปรุงเพิ่มเติมคือ

เมื่อเดือนที่แล้ว Git มีอายุครบ 10 ปีพอดี เว็บ Linux.com ได้สัมภาษณ์ Linus Torvalds ผู้พัฒนาซอฟต์แวร์ตัวนี้ขึ้นมา โดยความเห็นที่น่าสนใจมีดังนี้

การออกแบบที่เป็นจุดแข็งอย่างหนึ่งของระบบจัดการเวอร์ชันซอฟต์แวร์แบบกระจายศูนย์อย่าง Git คือ เครื่องไคลเอนต์ทุกเครื่องต้องเก็บข้อมูลทุกอย่างไว้ติดตัว (เพื่อจะสามารถทำหน้าที่เป็นเซิร์ฟเวอร์สำรองได้ทันทีเมื่อเครื่องเซิร์ฟเวอร์จริงเสียหาย)

แต่จุดแข็งนี้ก็อาจไม่ใช่ข้อดีเสมอไป โดยเฉพาะอย่างยิ่งเมื่อต้องทำงานกับไฟล์ขนาดใหญ่ เช่น ไฟล์เสียง ไฟล์ภาพยนตร์ เพราะเครื่องไคลเอนต์ทุกเครื่องต้องเสียพื้นที่เก็บไฟล์ขนาดใหญ่นี้ติดตัวเสมอ

GitHub จึงออกส่วนเสริม Large File Storage (LFS) โดยเปลี่ยนมาเก็บพอยเตอร์ของไฟล์ขนาดใหญ่เหล่านั้นแทน ส่วนไฟล์จริงจะเก็บไว้บนเซิร์ฟเวอร์ของ GitHub หรือ GitHub Enterprise