डेटाबेस बैकएंड के रूप में गिट भंडार का उपयोग करना

मैं एक प्रोजेक्ट कर रहा हूं जो संरचित दस्तावेज़ डेटाबेस से संबंधित है। मेरे पास श्रेणियों का एक पेड़ है (~ 1000 श्रेणियां, प्रत्येक स्तर पर ~ 50 श्रेणियों तक), प्रत्येक श्रेणी में संरचित दस्तावेज़ों के कई हजार (ऊपर, कहने, ~ 10000) शामिल हैं। प्रत्येक दस्तावेज़ कुछ संरचित रूप में डेटा के कई किलोबाइट्स है (मैं वाईएएमएल पसंद करूंगा, लेकिन यह जेएसओएन या एक्सएमएल भी हो सकता है)।

इस प्रणाली के उपयोगकर्ता कई प्रकार के संचालन करते हैं:

  • आईडी द्वारा इन दस्तावेज़ों को पुनर्प्राप्त करना
  • उनके अंदर कुछ संरचित विशेषताओं द्वारा दस्तावेज़ों की खोज
  • दस्तावेज़ों को संपादित करना (यानी जोड़ना/हटाना/नामकरण/विलय करना); प्रत्येक संपादन ऑपरेशन को कुछ टिप्पणी के साथ एक लेनदेन के रूप में दर्ज किया जाना चाहिए
  • विशेष दस्तावेज़ के लिए दर्ज किए गए परिवर्तनों का इतिहास देखना (जिसमें यह देखना शामिल है कि दस्तावेज़ किसने, कब और क्यों बदला, पहले संस्करण प्राप्त करना - और संभवतः अनुरोध किए जाने पर इसे वापस लेना)

बेशक, पारंपरिक समाधान इस समस्या के लिए किसी प्रकार के दस्तावेज़ डेटाबेस (जैसे कि कॉच डीबी या मोंगो) का उपयोग करेगा - हालांकि, इस संस्करण नियंत्रण (इतिहास) चीज ने मुझे जंगली विचार के लिए प्रेरित किया - मुझे गिट इस एप्लिकेशन के लिए डेटाबेस बैकएंड के रूप में भंडार?

पहली नज़र में, इसे हल किया जा सकता है:

  • category = directory, document = file
  • getting document by ID => changing directories + reading a file in a working copy
  • editing documents with edit comments => making commits by various users + storing commit messages
  • history => normal git log and retrieval of older transactions
  • search => that's a slightly trickier part, I guess it would require periodic export of a category into relational database with indexing of columns that we'll allow to search by

Are there any other common pitfalls in this solution? Have anyone tried to implement such backend already (i.e. for any popular frameworks - RoR, node.js, Django, CakePHP)? Does this solution have any possible implications on performance or reliability - i.e. is it proven that git would be much slower than traditional database solutions or there would be any scalability/reliability pitfalls? I presume that a cluster of such servers that push/pull each other's repository should be fairly robust & reliable.

असल में, मुझे बताएं अगर यह समाधान काम करेगा और क्यों यह करेगा या नहीं करेगा?

94
जोड़ा संपादित
विचारों: 1
@ शेरबैंग - वाह, आपने मुझे इस पूरे विषय पर एक छोटा निबंध बनाया है - इसे एक उत्तर के रूप में पोस्ट किया है। किसी भी प्रश्न पर चर्चा/पूछने के लिए स्वतंत्र महसूस करें।
जोड़ा लेखक GreyCat, स्रोत
अगर आप इस मार्ग पर गए और यह कैसे काम करता है तो मैं उत्सुक हूं?
जोड़ा लेखक sherbang, स्रोत
मैं उस तरह के कुछ समाधान के बारे में सोच रहा हूं जैसे दस्तावेज़ प्रणाली के लिए जो मैं बनाने जा रहा हूं। इसमें बहुत अधिक आवश्यकताएं हैं और यह अभी भी योजना चरण में है। मैं सोच रहा हूं कि यह आपके लिए कैसे चला गया, यदि ऐसा है। अपना अनुभव हमारे साथ साझा करें।
जोड़ा लेखक Omar Alves, स्रोत

5 उत्तर

मेरे अपने प्रश्न का उत्तर देना सबसे अच्छा काम नहीं है, लेकिन, जैसा कि मैंने अंततः विचार को छोड़ दिया, मैं अपने मामले में काम करने वाले तर्क पर साझा करना चाहता हूं। मैं इस बात पर जोर देना चाहता हूं कि यह तर्क सभी मामलों पर लागू नहीं हो सकता है, इसलिए यह निर्णय लेने के लिए वास्तुकार पर निर्भर है।

आम तौर पर, मेरे मुख्य प्रश्न का पहला मुख्य बिंदु यह है कि मैं बहु-उपयोगकर्ता प्रणाली से निपट रहा हूं जो समानांतर, समवर्ती रूप से, मेरे सर्वर का उपयोग पतली क्लाइंट (यानी केवल एक वेब ब्राउज़र) के साथ कर रहा है। इस तरह, मुझे उन सभी के लिए state बनाए रखना होगा। इस के लिए कई दृष्टिकोण हैं, लेकिन उनमें से सभी या तो संसाधनों पर बहुत कठिन हैं या लागू करने के लिए बहुत जटिल हैं (और इस प्रकार पहली जगह में गठबंधन करने के लिए सभी कठिन कार्यान्वयन सामग्री को ऑफ़लोड करने के मूल उद्देश्य को मारना):

  • "Blunt" approach: 1 user = 1 state = 1 full working copy of a repository that server maintains for user. Even if we're talking about fairly small document database (for example, 100s MiBs) with ~100K of users, maintaining full repository clone for all of them makes disc usage run through the roof (i.e. 100K of users times 100MiB ~ 10 TiB). What's even worse, cloning 100 MiB repository each time takes several seconds of time, even if done in fairly effective maneer (i.e. not using by git and unpacking-repacking stuff), which is non acceptable, IMO. And even worse — every edit that we apply to a main tree should be pulled to every user's repository, which is (1) resource hog, (2) might lead to unresolved edit conflicts in general case.

    Basically, it might be as bad as O(number of edits × data × number of users) in terms of disc usage, and such disc usage automatically means pretty high CPU usage.

  • "Only active users" approach: maintain working copy only for active users. This way, you generally store not a full-repo-clone-per-user, but:

    • As user logs in, you clone the repository. It takes several seconds and ~100 MiB of disc space per active user.
    • As user continues to work on the site, he works with the given working copy.
    • As user logs out, his repository clone is copied back to main repository as a branch, thus storing only his "unapplied changes", if there are any, which is fairly space-efficient.

    Thus, disc usage in this case peaks at O(number of edits × data × number of active users), which is usually ~100..1000 times less than number of total users, but it makes logging in/out more complicated and slower, as it involves cloning of a per-user branch on every login and pulling these changes back on logout or session expiration (which should be done transactionally => adds another layer of complexity). In absolute numbers, it drops 10 TiBs of disc usage down to 10..100 GiBs in my case, that might be acceptable, but, yet again, we're now talking about fairly small database of 100 MiBs.

  • "Sparse checkout" approach: making "sparse checkout" instead of full-blown repo clone per active user doesn't help a lot. It might save ~10x of disc space usage, but at expense of much higher CPU/disc load on history-involving operations, which kind of kills the purpose.

  • "Workers pool" approach: instead of doing full-blown clones every time for active person, we might keep a pool of "worker" clones, ready to be used. This way, every time a users logs in, he occupies one "worker", pulling there his branch from main repo, and, as he logs out, he frees the "worker", which does clever git hard reset to become yet again just a main repo clone, ready to be used by another user logging in. Does not help much with disc usage (it's still pretty high — only full clone per active user), but at least it makes logging in/out faster, as expense of even more complexity.

उस ने कहा, ध्यान दें कि मैंने जानबूझकर काफी छोटे डेटाबेस और उपयोगकर्ता आधार की गणना की है: 100 के उपयोगकर्ता, 1 के सक्रिय उपयोगकर्ता, 100 एमआईबी कुल डेटाबेस + संपादन का इतिहास, कामकाजी प्रति 10 एमआईबी। यदि आप अधिक प्रमुख भीड़-सोर्सिंग परियोजनाओं को देखेंगे, तो वहां बहुत अधिक संख्याएं हैं:

│              │ Users │ Active users │ DB+edits │ DB only │
├──────────────┼───────┼──────────────┼──────────┼─────────┤
│ MusicBrainz  │  1.2M │     1K/week  │   30 GiB │  20 GiB │
│ en.wikipedia │ 21.5M │   133K/month │    3 TiB │  44 GiB │
│ OSM          │  1.7M │    21K/month │  726 GiB │ 480 GiB │

जाहिर है, डेटा/गतिविधि की मात्रा के लिए, यह दृष्टिकोण पूरी तरह से अस्वीकार्य होगा।

आम तौर पर, यह काम करता, अगर कोई "मोटी" क्लाइंट के रूप में वेब ब्राउज़र का उपयोग कर सकता है, यानी गिट ऑपरेशंस जारी करना और सर्वर के पक्ष में नहीं, क्लाइंट की तरफ से पूर्ण चेकआउट को बहुत अधिक संग्रहित करना।

ऐसे अन्य अंक भी हैं जिन्हें मैंने याद किया है, लेकिन वे पहले की तुलना में खराब नहीं हैं:

  • "मोटी" उपयोगकर्ता के संपादन राज्य होने का बहुत ही पैटर्न सामान्य ओआरएम, जैसे ActiveRecord, Hibernate, DataMapper, Tower, आदि के संदर्भ में विवादास्पद है।
  • जितना मैंने खोजा है, लोकप्रिय ढांचे से गिट के लिए उस दृष्टिकोण को करने के लिए शून्य मौजूदा मुफ्त कोडबेस है।
  • कम से कम एक सेवा है जो किसी भी तरह से कुशलता से ऐसा करने का प्रबंधन करती है - यह स्पष्ट रूप से github है - लेकिन, हां, उनका कोडबेस बंद स्रोत है और मुझे दृढ़ता से संदेह है कि वे सामान्य गिट सर्वर/रेपो स्टोरेज तकनीकों का उपयोग नहीं करते हैं, यानी वे मूल रूप से वैकल्पिक "बड़े डेटा" गिट को लागू करते हैं।

तो, नीचे पंक्ति : यह है संभव है, लेकिन अधिकांश वर्तमान उपयोग के लिए यह इष्टतम समाधान के पास कहीं भी नहीं होगा। अपने स्वयं के दस्तावेज़-संपादन-इतिहास-से-एसक्यूएल कार्यान्वयन को रोल करना या किसी मौजूदा दस्तावेज़ डेटाबेस का उपयोग करने का प्रयास करना शायद एक बेहतर विकल्प होगा।

41
जोड़ा
शायद पार्टी के लिए थोड़ा देर हो चुकी है, लेकिन मुझे इसकी इसी तरह की आवश्यकता थी और वास्तव में गिट-रूट नीचे चला गया। कुछ गिट आंतरिक के साथ खुदाई करने के बाद, मुझे इसे काम करने का एक तरीका मिला। विचार एक नंगे भंडार के साथ काम करना है। कुछ कमियां हैं, लेकिन मुझे यह काम करने योग्य लगता है। मैंने एक पोस्ट में सब कुछ लिखा है जिसे आप देखना चाहते हैं (अगर कुछ भी, ब्याज के लिए): kenneth-truyers.net/2016/10/13/git-nosql-डेटा
जोड़ा लेखक Kenneth, स्रोत
मेरे लिए ऐसा करने का एक अन्य कारण क्वेरी क्षमताओं नहीं है। दस्तावेज़ स्टोर अक्सर इंडेक्स दस्तावेज बनाते हैं, जिससे उन्हें खोजना आसान हो जाता है। यह गिट के साथ सीधे आगे नहीं होगा।
जोड़ा लेखक FrankyHollywood, स्रोत
वाह, विस्तृत प्रतिक्रिया के लिए धन्यवाद। मैं गिट का उपयोग करने के विचार पर पहुंचा क्योंकि यह प्रभावी रूप से एक संस्करण डेटाबेस है। Concurrency मेरे लिए एक मुद्दा से कम है, लेकिन मेरे पास अलग-अलग मुद्दे हैं क्योंकि मेरे एंडपॉइंट्स का डेटा ठीक से मेल नहीं खाएगा।
जोड़ा लेखक sherbang, स्रोत
@ केनेथ, आपकी पोस्ट जो आपने यहां लिंक की है वह बहुत विस्तृत और व्यावसायिक रूप से तैयार की गई है। मैं डेटाबेस के रूप में गिट का उपयोग करने के बारे में सोचने वाले सभी को इसकी सलाह देता हूं
जोड़ा लेखक Andrzej Martyna, स्रोत

वास्तव में एक दिलचस्प दृष्टिकोण। मैं कहूंगा कि यदि आपको डेटा स्टोर करने की आवश्यकता है, तो डेटाबेस का उपयोग करें, स्रोत कोड रिपॉजिटरी नहीं, जिसे एक बहुत ही विशिष्ट कार्य के लिए डिज़ाइन किया गया है। यदि आप गिट आउट ऑफ़ द बॉक्स का उपयोग कर सकते हैं, तो यह ठीक है, लेकिन आपको शायद उस पर एक दस्तावेज़ रिपोजिटरी परत बनाने की आवश्यकता है। तो आप इसे पारंपरिक डेटाबेस पर भी बना सकते हैं, है ना? और यदि यह अंतर्निहित संस्करण नियंत्रण है जिसमें आप रुचि रखते हैं, तो क्यों न केवल ओपन सोर्स दस्तावेज़ भंडार उपकरण ? से चुनने के लिए बहुत सारे हैं।

खैर, अगर आप गिट बैकएंड के लिए जाने का फैसला करते हैं, तो मूल रूप से यह आपकी आवश्यकताओं के लिए काम करेगा यदि आपने इसे वर्णित किया है। परंतु:

1) आपने "सर्वरों के क्लस्टर का उल्लेख किया जो एक-दूसरे को धक्का/खींचते हैं" - मैंने थोड़ी देर के लिए इसके बारे में सोचा है और फिर भी मुझे यकीन नहीं है। आप एक परमाणु ऑपरेशन के रूप में कई repos धक्का/खींच नहीं सकते हैं। मुझे आश्चर्य है कि समवर्ती काम के दौरान कुछ विलय गड़बड़ी की संभावना हो सकती है।

2) शायद आपको इसकी आवश्यकता नहीं है, लेकिन आपके द्वारा सूचीबद्ध दस्तावेज़ रिपोजिटरी की स्पष्ट कार्यक्षमता एक्सेस नियंत्रण नहीं है। आप संभवतः सबोडोड्यूल के माध्यम से कुछ पथ (= श्रेणियों) तक पहुंच प्रतिबंधित कर सकते हैं, लेकिन शायद आप दस्तावेज़ स्तर पर आसानी से पहुंच प्रदान नहीं कर पाएंगे।

12
जोड़ा
अभिगम नियंत्रण पर अच्छी अंतर्दृष्टि।
जोड़ा लेखक engineerC, स्रोत

मेरे 2 पेन्स लायक थोड़ी देर लग रही है लेकिन ...... मेरी ऊष्मायन परियोजनाओं में से एक में मुझे भी इसी तरह की आवश्यकता थी। आपके समान, मेरी मुख्य आवश्यकताएं जहां दस्तावेज़ डेटाबेस के साथ एक दस्तावेज़ डेटाबेस (मेरे मामले में xml)। यह एक बहु-उपयोगकर्ता प्रणाली के लिए बहुत सहयोगी उपयोग मामलों के साथ था। मेरी वरीयता उपलब्ध ओपनसोर्स समाधानों का उपयोग करना था जो अधिकांश प्रमुख आवश्यकताओं का समर्थन करते थे।

पीछा करने के लिए कटौती करने के लिए, मुझे कोई भी उत्पाद नहीं मिला जो दोनों को प्रदान किया गया था, जिस तरह से स्केलेबल पर्याप्त था (उपयोगकर्ताओं की संख्या, उपयोग मात्रा, भंडारण और गणना संसाधन)। मैं सभी आशाजनक क्षमताओं के लिए गिट की ओर पक्षपातपूर्ण था, और (संभावित) समाधान एक से बाहर निकल सकता है। जैसे ही मैंने गिट विकल्प के साथ खिलवाड़ किया, एक उपयोगकर्ता परिप्रेक्ष्य से एक बहु (मिली) उपयोगकर्ता परिप्रेक्ष्य में जाने से एक स्पष्ट चुनौती बन गई। दुर्भाग्यवश, मुझे आपके द्वारा किए गए पर्याप्त प्रदर्शन विश्लेषण नहीं मिला। (.. आलसी/जल्दी छोड़ दो .... संस्करण 2, मंत्र के लिए) आप को शक्ति! वैसे भी, मेरे पक्षपातपूर्ण विचार ने बाद में (अभी भी पक्षपातपूर्ण) विकल्प को बदल दिया है: उपकरण के जाल-अप जो उनके अलग-अलग क्षेत्रों, डेटाबेस और संस्करण नियंत्रण में सबसे अच्छे हैं।

अभी भी प्रगति पर काम करते हैं (... और थोड़ा उपेक्षित) morphed संस्करण बस यह है।

  • फ्रंटएंड पर: (userfacing) पहले स्तर के लिए डेटाबेस का उपयोग करें भंडारण (उपयोगकर्ता अनुप्रयोगों के साथ इंटरफेसिंग)
  • बैकएंड पर, प्रदर्शन करने के लिए एक संस्करण नियंत्रण प्रणाली (वीसीएस) (जैसे गिट) का उपयोग करें डेटाबेस में डेटा ऑब्जेक्ट्स का वर्जनिंग

संक्षेप में यह डेटाबेस में एक संस्करण नियंत्रण प्लगइन जोड़ने की राशि होगी, कुछ एकीकरण गोंद के साथ, जिसे आपको विकसित करना पड़ सकता है, लेकिन यह बहुत आसान हो सकता है।

यह कैसे (माना जाता है) काम है कि प्राथमिक बहु-उपयोगकर्ता इंटरफ़ेस डेटा एक्सचेंज डेटाबेस के माध्यम से होते हैं। डीबीएमएस मल्टी-यूजर, कॉन्सुरेंसी ई, परमाणु संचालन इत्यादि जैसे सभी मजेदार और जटिल मुद्दों को संभालेगा। बैकएंड पर वीसीएस डेटा ऑब्जेक्ट्स के एक सेट (संस्करण, या बहु-उपयोगकर्ता मुद्दों) पर संस्करण नियंत्रण करेगा। डेटाबेस पर प्रत्येक प्रभावी लेनदेन के लिए, संस्करण नियंत्रण केवल उन डेटा रिकॉर्ड पर किया जाता है जो प्रभावी ढंग से बदल जाते हैं।

इंटरफेसिंग गोंद के लिए, यह डेटाबेस और वीसीएस के बीच एक साधारण इंटरवर्किंग फ़ंक्शन के रूप में होगा। डिज़ाइन के संदर्भ में, सरल दृष्टिकोण एक ईवेंट संचालित इंटरफ़ेस होगा, डेटाबेस नियंत्रण डेटा प्रक्रियाओं को ट्रिगर करने वाले डेटाबेस से डेटा अपडेट (संकेत: मानते हुए Mysql, ट्रिगर और sys_exec() blah blah का उपयोग ...)। कार्यान्वयन जटिलता के मामले में, यह से होगा जटिल और अद्भुत (कुछ प्रोग्राम किए गए कनेक्टर इंटरफेस) के लिए सरल और प्रभावी (उदाहरण के लिए स्क्रिप्टिंग)। यह इस बात पर निर्भर करता है कि आप इसके साथ कितना पागल होना चाहते हैं, और आप कितना पसीना पूंजी खर्च करना चाहते हैं। मुझे लगता है कि सरल पटकथा जादू करना चाहिए। और अंतिम परिणाम तक पहुंचने के लिए, विभिन्न डेटा संस्करण, एक साधारण विकल्प डेटाबेस के क्लोन (डेटाबेस संरचना का एक क्लोन) को पॉपस करना है, जिसमें वीसीएस में संस्करण टैग/आईडी/हैश द्वारा संदर्भित डेटा है। फिर यह बिट एक इंटरफेस का एक साधारण प्रश्न/अनुवाद/नक्शा नौकरी होगा।

अभी भी कुछ चुनौतियों और अज्ञातों का निपटारा किया जा रहा है, लेकिन मुझे लगता है कि इनमें से अधिकांश का प्रभाव, और प्रासंगिकता काफी हद तक आपकी आवेदन आवश्यकताओं पर निर्भर करती है और मामलों का उपयोग करती है। कुछ सिर्फ गैर मुद्दों के कारण खत्म हो सकता है। कुछ मुद्दों में उच्च आवृत्ति डेटा अपडेट गतिविधि वाले अनुप्रयोगों के लिए 2 कुंजी मॉड्यूल, डेटाबेस और वीसीएस के बीच प्रदर्शन मिलान शामिल है, डेटा के रूप में गिट पक्ष पर समय के साथ संसाधनों (संग्रहण और प्रसंस्करण शक्ति) का स्केलिंग बढ़ोतरी: स्थिर, घातीय या अंततः पठार का

उपरोक्त कॉकटेल में, यह वही है जो मैं वर्तमान में बना रहा हूं

  • वीसीएस के लिए गिट का उपयोग करना (प्रारंभ में केवल पुराने संस्करणों के उपयोग के कारण अच्छे पुराने सीवीएस माना जाता है) या 2 संस्करण के बीच डेल्टा)
  • MySQL का उपयोग (मेरे डेटा की अत्यधिक संरचित प्रकृति के कारण, सख्त xml स्कीमा के साथ xml)
  • MongoDB के साथ घूमना (NoSQl डेटाबेस को आज़माने के लिए, जो गिट में उपयोग की जाने वाली देशी डेटाबेस संरचना से निकटता से मेल खाता है)

कुछ मजेदार तथ्य - गिट वास्तव में भंडारण को अनुकूलित करने के लिए स्पष्ट चीजें करता है, जैसे संपीड़न, और वस्तुओं के संशोधन के बीच केवल डेल्टा का भंडारण - हाँ, गिट डेटा ऑब्जेक्ट्स के संशोधन के बीच केवल बदलाव या डेल्टा स्टोर करता है, जहां यह लागू है (यह कब और कैसे जानता है)। संदर्भ: गिट आंतरिकों की गड़बड़ी में गहराई से पैकफाइल - गिट के ऑब्जेक्ट स्टोरेज (कंटेंट-एड्रेसेबल फाइल सिस्टम) की समीक्षा, नोएसक्यूएल डेटाबेस जैसे एमओएसओडीबी के साथ समानताएं (अवधारणा परिप्रेक्ष्य से) को दिखाती है। फिर, पसीने की राजधानी के खर्च पर, यह 2, और प्रदर्शन tweaking एकीकृत करने के लिए और अधिक दिलचस्प संभावनाएं प्रदान कर सकता है

यदि आपको यह अभी तक मिल गया है, तो मुझे उपरोक्त आपके मामले पर लागू हो सकता है, और यह मानते हुए कि यह आपके पिछले व्यापक प्रदर्शन विश्लेषण में कुछ पहलू तक कैसे पहुंच जाएगा

12
जोड़ा

जैसा कि आपने बताया है, बहु-उपयोगकर्ता केस संभालने के लिए थोड़ा सा ट्रिकियर है। एक संभावित समाधान उपयोगकर्ता-विशिष्ट गिट इंडेक्स फ़ाइलों का उपयोग करना होगा जिसके परिणामस्वरूप

  • अलग-अलग काम करने वाली प्रतियों की आवश्यकता नहीं है (डिस्क उपयोग बदली गई फ़ाइलों तक सीमित है)
  • समय लेने वाली प्रारंभिक कार्य (प्रति उपयोगकर्ता सत्र) की आवश्यकता नहीं है

चाल गिट के GIT_INDEX_FILE गिट बनाने के लिए उपकरण के साथ पर्यावरण परिवर्तक मैन्युअल रूप से काम करता है:

एक समाधान रूपरेखा निम्नानुसार है (वास्तविक SHA1 हैश आदेश से छोड़े गए हैं):

# Initialize the index
# N.B. Use the commit hash since refs might changed during the session.
$ GIT_INDEX_FILE=user_index_file git reset --hard 

#
# Change data and save it to `changed_file`
#

# Save changed data to the Git object database. Returns a SHA1 hash to the blob.
$ cat changed_file | git hash-object -t blob -w --stdin
da39a3ee5e6b4b0d3255bfef95601890afd80709

# Add the changed file (using the object hash) to the user-specific index
# N.B. When adding new files, --add is required
$ GIT_INDEX_FILE=user_index_file git update-index --cacheinfo 100644  path/to/the/changed_file

# Write the index to the object db. Returns a SHA1 hash to the tree object
$ GIT_INDEX_FILE=user_index_file git write-tree
8ea32f8432d9d4fa9f9b2b602ec7ee6c90aa2d53

# Create a commit from the tree. Returns a SHA1 hash to the commit object
# N.B. Parent commit should the same commit as in the first phase.
$ echo "User X updated their data" | git commit-tree  -p 
3f8c225835e64314f5da40e6a568ff894886b952

# Create a ref to the new commit
git update-ref refs/heads/users/user_x_change_y 

आपके डेटा के आधार पर आप मास्टर पर नए रेफर्स को मर्ज करने के लिए क्रॉन जॉब का उपयोग कर सकते हैं लेकिन संघर्ष समाधान तर्कसंगत रूप से सबसे कठिन हिस्सा है।

इसे आसान बनाने के विचार स्वागत हैं।

2
जोड़ा
यह आम तौर पर एक दृष्टिकोण है जो कहीं भी नहीं जाता है, जब तक आप मैन्युअल संघर्ष समाधान के लिए लेनदेन और यूआई की पूरी तरह से उभरती अवधारणा नहीं लेना चाहते हैं। विवादों के लिए सामान्य विचार उपयोगकर्ता को इसे प्रतिबद्ध करने के लिए सही तरीके से हल करना है (यानी "क्षमा करें, किसी और ने उस दस्तावेज़ को संपादित किया है जिसे आप संपादित कर रहे थे -> कृपया उसके संपादन और अपने संपादन देखें और उन्हें मर्ज करें")। जब आप दो उपयोगकर्ताओं को सफलतापूर्वक प्रतिबद्ध करने की अनुमति देते हैं और फिर एसिंक क्रोनबॉज में पता लगाते हैं कि चीजें दक्षिण में जाती हैं, तो आम तौर पर सामान को हल करने के लिए कोई भी उपलब्ध नहीं
जोड़ा लेखक GreyCat, स्रोत

मैंने libgit2 के शीर्ष पर एक रूबी लाइब्रेरी लागू किया जो इसे बहुत आसान बनाता है लागू करें और एक्सप्लोर करें। कुछ स्पष्ट सीमाएं हैं, लेकिन यह एक बहुत ही मुक्त प्रणाली है क्योंकि आपको पूर्ण गिट टूलचेन मिलता है।

दस्तावेज़ीकरण में प्रदर्शन, ट्रेडऑफ इत्यादि के बारे में कुछ विचार शामिल हैं।

1
जोड़ा