- लक्ष्य सबसे सरल git सहयोग टूल बनाना है
- बाहरी सहयोगियों के समय और ऊर्जा की बलि दिए बिना, self-hosted git server चलाना SSH server चलाने जितना आसान बनाना
- mailing list और pull request workflow को जोड़ता है
- patch बनाने जितना सरल लेकिन pull request जैसी उपयोग-सुविधा वाला सहयोग टूल बनाना चाहता है
- एक और code repository बनाना लक्ष्य नहीं है, बल्कि बाहरी contributors के साथ सहयोग के लिए बेहद सरल self-hosted git solution बनाना है
क्या चाहिए
- code owner को git server चलाने के लिए जो चाहिए:
- बाहरी contributor को जो चाहिए:
मौजूदा समस्याएं
- email, git repository में बदलावों (patch set) को भेजने और प्राप्त करने के लिए distributed system के रूप में शानदार है, लेकिन नए users को mailing list पर onboard करना, email client को सही तरह से configure करना, और फिर code contribution submit करना — यह सब मिलकर कई developers को बीच में ही छोड़ देने पर मजबूर कर देता है
- email protocol का उपयोग करके सहयोग करने से feature set सीमित हो जाता है। उदाहरण के लिए email edit नहीं किया जा सकता, हर कोई अलग client इस्तेमाल करता है, और इन clients की plain text email तथा patch download से जुड़ी अलग-अलग सीमाएं होती हैं
- Github pull request का उपयोग, संपादन और प्रबंधन आसान है, लेकिन इसकी कमी यह है कि code review करने के लिए user को Github website के भीतर रहना पड़ता है
- तेज बदलावों के लिए यह अच्छा है, लेकिन जब आप web browser के भीतर code पढ़ना शुरू करते हैं तो इसकी काफी कमियां सामने आती हैं। एक बिंदु पर local development environment या IDE में code review करना अधिक उचित लगता है
- IDE के भीतर PR review करने के लिए tools और plugins मौजूद हैं, लेकिन उन्हें उपयोग योग्य बनाने में बहुत अधिक मेहनत लगती है
- साथ ही, pull request की नकल करने वाले self-hosted solutions को इसे manage करने के लिए काफी infrastructure चाहिए। database, git से जुड़ी website, admin management, services आदि
- एक और बड़ा friction point यह है कि बाहरी users को code changes submit करने से पहले account बनाना और login करना पड़ता है। इससे न केवल बाहरी contributors के लिए बल्कि infrastructure provision करने वाले code owners के लिए भी काफी friction बढ़ जाता है
- PR submit करने से पहले अक्सर code repository के अंदर repository को fork करना पड़ता है। फिर दोबारा कभी योगदान नहीं करते, लेकिन forked repository हमेशा के लिए बनी रहती है। यह बेवकूफी लगती है
Patch Request (PR) का परिचय
- लक्ष्य एक self-hosted git "server" बनाना है, जिसमें email setup की झंझट या email protocol द्वारा थोपी गई सीमाओं के बिना patches भेजे और प्राप्त किए जा सकें
- साथ ही, यह भी चाहत है कि मुख्य workflow local development environment के इर्द-गिर्द हो। Github workflow को support करने के लिए browser में IDE ला रहा है, लेकिन हम इस विचार को उलटते हुए local development environment के भीतर code review को first-class citizen बनाना चाहते हैं
- इसे Github के pull request workflow और email के जरिए patch भेजने-लेने के बीच का रास्ता माना गया है
- मूल विचार यह है कि contributor और project owner के बीच होने वाली ज्यादातर interactions को SSH app के जरिए संभाला जाए। terminal के भीतर ही सब कुछ ergonomic और fully functional तरीके से किया जा सकता है
- notifications RSS से होंगी और हर state change static web assets के generation की ओर ले जाएगा, ताकि सब कुछ एक साधारण file web server से host किया जा सके
format-patch workflow
- यहां बुनियादी सहयोग टूल
format-patch है
- चाहे code changes submit करने हों या उनका review करना हो, सब कुछ code में ही होता है
- contributor और owner दोनों नए commits बनाते हैं और एक-दूसरे के ऊपर patches तैयार करते हैं
- इससे reviewer के लिए ऐसा web viewer रखने की जरूरत नहीं रहती जहां वह code block की किसी एक line पर "comment" कर सके। इसकी जरूरत नहीं है। contributor का patch apply करें, comment या code changes लिखें, नया patch बनाएं, और patch को "review" के रूप में git server पर भेज दें
- यह flow तब भी बिल्कुल वही रहता है जब दो users किसी changes की series पर सहयोग कर रहे हों
- यह एक ही code change के लिए multiple patch sets भेजे जाने की समस्या भी हल करता है। एक single central Patch Request होता है, जहां सारे changes और collaboration होते हैं
- git note का उपयोग करके review/comment संभालने का कोई तरीका खोजा जा सकता है, लेकिन सच कहें तो वह समाधान कठिन लगता है और ज्यादातर git users के सहज उपयोग-स्तर से बाहर है
- बस code के जरिए review भेजें और जिस programming language का उपयोग हो रहा है उसी में code पर comments लिखें
- इन comments को "process" करना और बाद के patch में हटाना contributor की जिम्मेदारी है
- सभी comments को संबोधित करने के लिए एक enforced feature: अगर code में unresolved comments हैं, तो patch merge नहीं होगा। उन्हें नजरअंदाज नहीं किया जा सकता, वरना वे गलत तरीके से upstream हो जाएंगे
Patch Request कैसे काम करता है
- Patch Request (PR), git repository में changes submit, review और accept करने का सबसे सरल तरीका है। यह इस तरह काम करता है:
- बाहरी contributor repository clone करता है (
git-clone)
- बाहरी contributor code changes करता है (
git-add & git-commit)
- बाहरी contributor patch बनाता है (
git-format-patch)
- बाहरी contributor SSH server पर PR submit करता है
- owner को नए PR के लिए RSS notification मिलती है
- owner SSH server से patch को local में apply करता है (
git-am)
- owner code में सुझाव लिखता है (
git-add & git-commit)
- owner patch को SSH server पर pipe करके review submit करता है (
git-format-patch)
- बाहरी contributor को PR review के लिए RSS notification मिलती है
- बाहरी contributor patch फिर से apply करता है (
git-am)
- बाहरी contributor code के comments की समीक्षा करता है और उन्हें हटाता है
- बाहरी contributor एक और patch submit करता है (
git-format-patch)
- owner patch को local में apply करता है (
git-am)
- owner PR को approved के रूप में mark करता है और code को main पर push करता है (
git-push)
1 टिप्पणियां
Pico.sh - SSH का इस्तेमाल करके हर चीज़ को वेब सर्विस के रूप में मैनेज करने वाले open source टूल्स का संग्रह में यह नई जोड़ लगती है.
पहले से इसमें निम्न चीज़ें शामिल हैं.