अन्य भाषाओं में: English, Español, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano · हिन्दी में सभी गाइड
खुलासा: Carbon Forge को हम 100monkeys.ai पर बनाते हैं, इसलिए इसे बनाने वाले का विवरण मानकर पढ़ें। इस गाइड का मसौदा हमारे एक AI एजेंट ने सार्वजनिक दस्तावेज़ों (अंग्रेज़ी में) से तैयार किया, ख़ासकर Working in lanes के कदम 6 से 8 और Lanes कैटलॉग पन्ने से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। हर कॉल दस्तावेज़ों का अपना उदाहरण है, और उद्धरण अंग्रेज़ी में हैं, अनुवाद साथ में। जहाँ दस्तावेज़ कोई सवाल खुला छोड़ते हैं, आख़िरी हिस्सा यह बताता है।
जानें कि क्या टकराव माना जाता है
lane trunk के ऊपर patch का एक समूह है, और उस पर हर रीड trunk की अभी की स्थिति को उन patch के साथ जोड़ती है। कोई patch टकराव में है "when it no longer applies to the trunk: its old text no longer matches or matches twice" (जब वह trunk पर लागू नहीं होता: उसका पुराना टेक्स्ट अब मेल नहीं खाता या दो बार मेल खाता है), या trunk ने वह ट्री प्रविष्टि या लाइब्रेरी प्रविष्टि बदल दी जिसे patch बदल रहा था। जो patch अब भी लागू होता है वह टकराव नहीं है, भले trunk ने वही हिस्सा बदला हो; रीड उसे खिसके हुए हिस्से के रूप में बताती है, "worth a reviewer's look, not a conflict." (समीक्षक के देखने लायक, टकराव नहीं)। एक ही फ़ाइल के अलग-अलग हिस्से बदलने वाले दो एजेंट, दोनों लैंड होते हैं। और वह नियम जिस पर बाकी गाइड चलती है: "Nothing merges by itself." (कुछ भी अपने आप merge नहीं होता)।
ध्यान दें कि कोई lane टकराव में है
lanes.get landable लौटाता है, जो केवल तब true है जब lane खुली हो, उसमें कम से कम एक जीवित patch हो और कोई टकराव न हो। ऐप में, /<workspace>/lanes/<label> पर lane के पन्ने में एक Conflicts टैब है। बार-बार जाँचे बिना, जब trunk पर कोई लैंडिंग पहली बार lane को टकराव में डालती है, तो lane.conflict webhook इवेंट उस lane और उसकी टकराव वाली पंक्तियों के पथ बताता है।
टकराव पढ़ें
lanes.conflicts { "label": "agent/7/fix-login" }हर पंक्ति में वह है जो merge करने वाले को चाहिए: patch; वह हिस्सा जैसा patch लेते समय था; trunk का वह हिस्सा जैसा अभी है; lane का जोड़ा हुआ दृश्य; और वे changeset जिन्होंने उसे खिसकाया, हर एक अपने intent, कर्ता और उसे लैंड करने वाली lane के साथ। कोड ट्री के लिए पंक्ति हर टकराव वाली फ़ाइल का unified diff जोड़ती है, और व्याकरण वाली भाषा के लिए अलग होने वाली शीर्ष-स्तरीय परिभाषाओं की एक सलाहकारी सूची, जो "decides nothing" (कुछ तय नहीं करती)। यह टूल केवल पढ़ता है और इसे सिर्फ़ viewer भूमिका चाहिए। ऐप में Conflicts टैब trunk का टेक्स्ट और lane का टेक्स्ट दिखाता है, हर एक का जवाब देने की सटीक कॉल के साथ, "ready to copy, while the page itself decides nothing." (कॉपी करने को तैयार, जबकि पन्ना ख़ुद कुछ तय नहीं करता)।
टेक्स्ट टकराव का जवाब दें
lanes.resolve { "patch_id": "…", "note": "kept both sign-in options", "old_string": "…", "new_string": "…" }जवाब एक नया patch है, साथ में 1 से 1,024 अक्षरों का एक नोट जो कारण बताता है। वह "matched against the trunk as it stands now and bound to the hash of that state." (trunk की अभी की स्थिति से मिलाया जाता है और उस स्थिति के hash से बँधा होता है)। पुराना patch इतिहास के रूप में रहता है, superseded चिह्नित। ट्री टकराव का जवाब इसी तरह upserts, removals या patches से दिया जाता है, और लाइब्रेरी प्रविष्टि का sha256 से। क्रम से जवाब दें: उसी entity पर बाद वाला patch तब तक रुकता है जब तक पहले वाला हल न हो जाए।
या patch छोड़ दें
lanes.drop_patch { "patch_id": "…" }जब trunk वह पहले ही कर चुका हो जो patch करना चाहता था, या patch की अब ज़रूरत न हो, तो उसे छोड़ दें। जहाँ वह entity नहीं रही जिस पर patch लिया गया था, वहाँ दस्तावेज़ों की अस्वीकृति कहती है कि patch को हल करने के बजाय छोड़ दें।
स्थानांतरण टकराव का जवाब दें
lanes.resolve { "patch_id": "…", "note": "kept the trunk's rename and moved on from it", "to_path": "guides/sign-in" }किसी पन्ने का नाम बदलने वाली lane तब टकराती है जब trunk ने बाद में वही पन्ना खिसका दिया हो, जब trunk के पास अब नया पथ हो, या जब पन्ना ही न रहा हो। to_path से जवाब दें, और जहाँ शीर्षक बदलना हो वहाँ title से। समाधान उस पथ से बँधा है जो trunk के पास अभी है, इसलिए trunk का बाद का कोई स्थानांतरण भी उसे पुराना कर देता है।
जोड़े गए काम में टकराव का जवाब दें
lanes.merge { "from": "agent/8/tests", "into": "agent/7/fix-login", "intent": "assemble the login fix" }मुख्य एजेंट लैंड करने से पहले कई एजेंटों की lane को एक में इकट्ठा करता है। इस तरह लाया गया patch वहाँ टकराता है जहाँ पाने वाली lane ने वही बदला हो जो वह बदलता है, और lanes.conflicts moved_by के रूप में पाने वाली lane के वे पहले के patch बताता है जिन पर वह अब टिका है। उसका समाधान पाने वाली lane के दृश्य का जवाब देता है, केवल trunk का नहीं।
लैंड करें, पहले एक dry run के साथ
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }लैंडिंग अपने ही transaction के भीतर फिर से जाँची जाती है, और अगर कुछ भी खिसका हो तो पूरी अस्वीकार होती है, हर टकराव के नाम के साथ। कोई समाधान trunk की एक सटीक स्थिति का जवाब देता है; अगर लैंडिंग से पहले trunk वह हिस्सा खिसका दे, तो समाधान पुराना हो जाता है और लैंडिंग इसके साथ अस्वीकार होती है:
resolution <id> was resolved against <hash>; the trunk's section is now <hash>तब lanes.conflicts फिर से पढ़ें और नई स्थिति का जवाब दें। लैंडिंग नियमों वाले सुरक्षित trunk पर याद रखें कि अनुमोदनों के बाद का कोई भी समाधान उन्हें "count for nothing" (बेमानी) कर देता है, इसलिए अनुमोदन आख़िरी जवाब के बाद आता है। लैंडिंग idempotency_key के साथ भेजें, तो टाइमआउट के बाद की दोबारा कोशिश दो बार लैंड करने के बजाय पहली लैंडिंग का नतीजा लौटाती है।
जो lane कोड बदलाव और उसका दस्तावेज़ साथ ले जाती है, उसके लिए हमारी गाइड पढ़ें: कोड बदलाव और उसका दस्तावेज़ एक ही changeset में लैंड करें।
दस्तावेज़ किन सवालों का जवाब नहीं देते
- जब आधार वाला हिस्सा वापस न मिल सके तो क्या करें। टकराव की पंक्ति उसके लिए अधिकतम 200 revisions पीछे जाती है और नहीं तो
unknownबताती है; दस्तावेज़ नहीं बताते कि वहाँ से जवाब कैसे दें। dry_runलैंडिंग क्या लौटाती है। गाइड कॉल दिखाती है पर उसका जवाब नहीं।lane.conflictइवेंट lane और पथों के अलावा और क्या ले जाता है।