GitRoot

 (gitroot.dev)
2 คะแนน โดย GN⁺ 1 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GitRoot เป็น Git forge ขนาดเล็กที่จัดการรีโพซิทอรีและสิทธิ์การเข้าถึงด้วยไบนารีเดียว และประกอบความสามารถอย่าง issue, board, การรวม branch และเว็บอินเทอร์เฟซผ่านปลั๊กอินแบบแยกอิสระ
  • นอกจากโค้ดแล้ว ยัง เก็บข้อมูลทั้งหมดไว้ใน Git เป็นไฟล์ปกติ ไม่ว่าจะเป็น issue, merge request หรือ board โดยไม่พึ่งฐานข้อมูลแยกหรือ hidden blob
  • ควบคุมการเปลี่ยนแปลงด้วย .gitroot/users.yml และ สิทธิ์เขียนแยกตาม branch โดยมีเพียงผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่ push ไปยัง default branch ซึ่งเป็นสถานะปัจจุบันของรีโพซิทอรีได้
  • ขณะนี้ยังเป็น เวอร์ชันอัลฟา รองรับรีโพซิทอรี ผู้ใช้ ปลั๊กอิน คำสั่ง SSH Git และการดูผ่าน HTTP แต่ยังไม่เหมาะสำหรับใช้งานจริงใน production
  • ก่อนถึง 1.0 มีแผนเพิ่มการอัปเดต การกำหนดสิทธิ์ระดับไฟล์ คำสั่ง Git ผ่าน HTTP กลุ่มและกลุ่มย่อย รวมถึงทำให้ API ของปลั๊กอินเสถียร โดยตอนนี้การมีส่วนร่วมต้องเข้าใจ Git และการทำงานของปลั๊กอิน grafter

Git forge ขนาดเล็กที่ประกอบใช้เฉพาะความสามารถที่ต้องการ

  • GitRoot เป็น Git forge ขนาดเล็ก ที่รันด้วยไบนารีเดียว และจำกัดความสามารถพื้นฐานไว้ที่การสร้างรีโพซิทอรีและการจัดการสิทธิ์เข้าถึงรายรีโพซิทอรี
  • ความสามารถที่เหลือให้ปลั๊กอินซึ่งติดตั้งแยกจากกันได้ทำหน้าที่
    • สร้าง issue, roadmap, sprint และ milestone
    • แสดงรายการในรูปแบบ board
    • การรีวิวและรวม branch ที่ GitRoot เรียกว่า graft
    • ให้ข้อมูลรีโพซิทอรีและความสามารถต่าง ๆ ผ่านเว็บอินเทอร์เฟซ
  • เนื่องจากปลั๊กอินแยกจากกันโดยสมบูรณ์ จึง ใช้เฉพาะ board โดยไม่มีเว็บอินเทอร์เฟซ ก็ได้ และยังสามารถสร้างปลั๊กอินเองตามความต้องการของโปรเจ็กต์ได้

การออกแบบที่ปรับ forge ให้เข้ากับโปรเจ็กต์

  • ออกแบบโดยตั้งอยู่บนสมมติฐานว่าแต่ละโปรเจ็กต์มีวิธีทำงานที่ต้องการไม่เหมือนกัน และแต่ละโปรเจ็กต์ควรมี อิสระในการปรับแก้ forge ของตนเอง
  • สภาพแวดล้อมที่ผู้พัฒนาต้องการมีดังนี้
    • เก็บโค้ด issue, pull/merge request และ board ไว้ในรีโพซิทอรีเดียว
    • มีความสามารถที่จำเป็นต่อการโปรโมตและดำเนินงานของโปรเจ็กต์ เช่น landing page, การแปล, ระบบ ticket และ forum
    • ย้ายไปยัง forge บนเซิร์ฟเวอร์อื่นได้โดยไม่ต้องมี migration script และไม่สูญเสียข้อมูลหรือการแสดงผู้มีส่วนร่วม
  • ในทางกลับกัน ต้องการหลีกเลี่ยงความซับซ้อนต่อไปนี้
    • วิธีการที่ต้องเปิดเบราว์เซอร์เพื่อจัดการ pull/merge request หรือ issue
    • โครงสร้างที่ทำให้คนที่เพิ่งรู้จักโปรเจ็กต์เห็นรายการไฟล์และไดเรกทอรีก่อนอย่างแรก
    • วิธีที่ forge เป็นผู้กำหนดความหมายและ workflow ของ sprint, milestone, epic และ user story
    • โครงสร้างที่ต้องผ่านหลายเมนูเพื่อตั้งค่าสิทธิ์ของผู้ใช้เพียงรายการเดียว

ความเป็นอิสระในการติดตั้งและการดูแลระบบ

  • มุ่งไปที่ การแจกจ่ายที่ไม่มี dependency และฐานข้อมูล เพื่อให้ผู้ดูแลติดตั้งและดูแลรักษาได้ง่าย
  • ผู้ดูแลควรกำหนดได้ว่าผู้ใช้แต่ละคนทำอะไรได้บ้าง และผู้ใช้ควรขอสร้าง/เข้าถึงโปรเจ็กต์และความสามารถต่าง ๆ ได้ด้วยตนเองโดยไม่ต้องพึ่งอีเมลหรือแชต
  • เป้าหมายคือการลดภาระในการอัปเกรด พร้อมทั้งไม่ส่งมอบข้อมูลโปรเจ็กต์และผู้ใช้ให้บุคคลที่สาม และไม่ต้องพึ่งผู้ให้บริการรายใหญ่ที่อาจเปลี่ยนนโยบายการดำเนินงานอย่างฉับพลัน
  • โปรเจ็กต์นี้ยังไม่เสร็จสมบูรณ์และกำลังเปิดรับการมีส่วนร่วมจากภายนอก

สิทธิ์ที่จัดการด้วยไฟล์ปกติและ branch

  • เก็บ ข้อมูลทั้งหมดไว้ในไฟล์ปกติ ข้างโค้ด แทนการใช้ฐานข้อมูลหรือ hidden blob ภายใน Git tree
  • .gitroot/users.yml ของแต่ละรีโพซิทอรีจะระบุตำแหน่งที่ผู้ใช้แต่ละคนเขียนได้ และการควบคุมการเข้าถึงทำงานโดยเน้น ข้อจำกัดระดับ branch
    • ในตอนแรกมีเพียงเจ้าของเท่านั้นที่เข้าถึง default branch ได้
    • หากผู้ใช้ที่ไม่มีสิทธิ์ push ไปยัง default branch, GitRoot จะปฏิเสธการเปลี่ยนแปลง
    • ทุกคนสามารถสร้าง branch ใหม่ได้ และผู้ใช้ที่สร้างจะได้สิทธิ์เขียนใน branch นั้น โดยผู้ใช้อื่นไม่สามารถแก้ไขได้
    • หากแก้ไข .gitroot/users.yml หรือรวม branch ที่ผู้ใช้เพิ่มตัวเองเข้าไป ผู้ใช้นั้นก็จะ push ไปยัง default branch ได้เช่นกัน
  • ทุกคนสามารถอ่านไฟล์และแก้ไขในเครื่องหรือบน branch ใหม่ได้ แต่หากต้องการสะท้อนการเปลี่ยนแปลงไปยัง default branch ซึ่งแสดงสถานะปัจจุบันของรีโพซิทอรี จะต้องมี การรวมโดยเจ้าของ
  • การตั้งค่าของ forge เองก็จัดการใน root repository
    • หากเพิ่มการเปลี่ยนแปลงใน .gitroot/repositories.yml ของ default branch ใน root repository หรือรวมการเปลี่ยนแปลงนั้น รีโพซิทอรีจะถูกสร้างขึ้น
    • ดูรายละเอียดการทำงานได้ในเอกสาร

ความสามารถที่รองรับในเวอร์ชันอัลฟา

  • ปัจจุบันยังเป็น เวอร์ชันอัลฟา จึงสามารถทดลองได้แต่ไม่ควรใช้ใน production
  • ขอบเขตที่รองรับมีดังนี้
    • การสร้างและลบรีโพซิทอรี
    • การประมวลผลคำสั่ง Git ผ่าน SSH
    • การจัดการตำแหน่งที่ผู้ใช้แต่ละคนเขียนได้ในระดับรีโพซิทอรีและ branch
    • การติดตั้งปลั๊กอินและการเปิดใช้งานแยกตามรีโพซิทอรี
    • การรันปลั๊กอินใน working tree ระหว่างการติดตั้ง
    • หลังติดตั้งแล้ว รันปลั๊กอินกับ diff ของทุก commit
    • การดูรีโพซิทอรีผ่าน HTTP

แผนการพัฒนาจนถึง 1.0

  • ก่อนเวอร์ชัน 1.0 มีแผนจะทำความสามารถต่อไปนี้
    • การอัปเดต GitRoot และปลั๊กอิน
    • การจัดการ สิทธิ์ผู้ใช้ระดับไฟล์
    • การประมวลผลคำสั่ง Git ผ่าน HTTP
    • การจัดการรีโพซิทอรีด้วยกลุ่มและกลุ่มย่อย
    • ทำให้ API ของปลั๊กอินเสถียร

การ self-host และขั้นตอนการมีส่วนร่วม

  • เว็บไซต์ GitRoot เป็น อินสแตนซ์ GitRoot ที่โฮสต์โค้ดของ GitRoot เอง และเปิดใช้งานเฉพาะสำหรับโปรเจ็กต์ GitRoot
  • หากต้องการทดลองกับโปรเจ็กต์อื่น ต้องทำตามเอกสารการติดตั้งและการใช้งาน
  • เนื่องจาก GitRoot เองก็เป็นรีโพซิทอรีของ GitRoot จึงสามารถมีส่วนร่วมได้ด้วยวิธีเดียวกัน และดูขั้นตอนได้ที่คู่มือการมีส่วนร่วม
  • อินสแตนซ์ปัจจุบันใช้ปลั๊กอิน grafter สำหรับรวมบางส่วนของโค้ดเข้าสู่ default branch ดังนั้นก่อนมีส่วนร่วมจึงต้องเข้าใจวิธีทำงานของมัน
  • เนื่องจากข้อมูลทั้งหมดรวมถึงโค้ด issue และการแปลถูกเก็บไว้ใน Git การมีส่วนร่วมในตอนนี้จึงต้อง รู้วิธีใช้ Git
  • ในอนาคตมีเป้าหมายให้ทุกคนเข้าร่วมได้ โดยสามารถรัน git commit และ git push ได้โดยตรงจากเบราว์เซอร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 일 전
ความคิดเห็นจาก Lobste.rs
  • GitHub ไม่ได้เป็นเพียงโฮสต์ Git ที่ใหญ่ที่สุดเท่านั้น แต่ยังเป็นโฮสต์ที่มีอิทธิพลมากที่สุดด้วย และร่องรอยนั้นก็ยังสัมผัสได้ในการออกแบบของ Forgejo และ GitLab ด้วย จากการถดถอยของ GitHub จึงดูเหมือนว่าจะมี พื้นที่สำหรับนวัตกรรม มากขึ้น เพราะอาจมีโฮสต์หลากหลายรูปแบบที่หลุดพ้นจากโมเดลเดิมเกิดขึ้น
    • Gitea เคยคัดลอกฟรอนต์เอนด์ของ GitHub แบบเกือบ 1:1 และเมื่อ Forgejo ฟอร์กมาจาก Gitea ก็ได้รับรูปแบบนั้นมาด้วยเช่นกัน
  • ผมเป็นคนที่สร้าง GitRoot ขึ้นมาเอง ถ้ามีอะไรสงสัยก็ถามมาได้ตามสบาย
    • มีอยู่สามเรื่องที่สงสัย อยากทราบว่า ทำไมถึงคอมมิต CSS ในสภาพที่ย่อแล้ว: https://gitroot.dev/worktree/app/…
      สาเหตุที่ความกว้างของแท็ก <pre> ถูกจำกัดไว้ที่ 720px ดูเหมือนจะมาจาก body ที่ใช้ display:grid และถ้าปิดมันก็จะกว้างขึ้นตามคาด อีกทั้งใน URL ก็ไม่มี ข้อมูลจุดเวลา commit ที่เฉพาะเจาะจง จึงทำให้คนส่งลิงก์กับคนรับลิงก์ดูหน้าจอเดียวกันได้ยาก เข้าใจว่าเป็นโปรเจ็กต์ที่ทำไว้ใช้ส่วนตัว แต่อยากฝากไว้เป็นประเด็นที่น่าพิจารณา
  • @manland อยากทราบว่ามีนโยบายหรือแนวทางเกี่ยวกับการอนุญาตหรือห้าม ผลงานที่สร้างด้วย LLM หรือไม่
    • ตอนนี้ยังไม่มีนโยบายแยกต่างหาก เพราะนอกจากผู้มีส่วนร่วมแบบครั้งเดียวสองคนแล้ว โค้ด 99.999% เขียนด้วยตัวเอง
      โดยส่วนตัวไม่ใช้ LLM ในการเขียนโค้ดและก็ไม่เห็นด้วย แต่ถึงจะมีการใช้ LLM ถ้าแพตช์เล็กพอ ก็ยังไม่แน่ใจว่าจะปฏิเสธหรือไม่
      เพราะภาษาอังกฤษไม่ใช่ภาษาแม่ จึงอธิบาย GitRoot ได้ยาก และการสื่อสารภายนอกจึงมีร่องรอยของ LLM อยู่ ก่อนหน้านี้ก็เคยขอความช่วยเหลือที่ https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 และ https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 แต่ก็ไม่มีใครมา
      มันทำให้เจ็บใจที่ต้องใช้ LLM แต่ก็เลือกจะ ใช้ให้น้อยที่สุด แทนการไม่ทำอะไรเลย หากในอนาคตมีชุมชนเกิดขึ้นก็อยากตัดมันออกไปทั้งหมด และก่อนหน้านั้นมันอาจหายไปเองตามธรรมชาติด้วยเหตุผลทางเศรษฐกิจก็ได้ มีเรื่องด้านปรัชญา ความปลอดภัย และอนาคตที่ตั้งใจจะเขียนไว้อยู่หลายชิ้นในรายการสิ่งที่ต้องทำ แต่สุดท้ายก็ลังเลที่จะเขียน เพราะคิดว่า LLM ก็คงจะมาช่วยขัดเกลาประโยค แก้คำผิด และแปลให้อยู่ดี
  • ชอบที่นำ TinyGo มาใช้คอมไพล์ปลั๊กอิน Go เป็น WASM