यह देखते हुए कि Git प्रतिबद्ध किस शाखा से आया है

Question

क्या यह पता लगाने का एक तरीका है कि एसएचए -1 हैश मूल्य दिए जाने से कौन सी शाखा प्रतिबद्ध है ?

बोनस अंक यदि आप मुझे बता सकते हैं कि रूबी ग्रिट का उपयोग करके इसे कैसे पूरा किया जाए।

Comments

नीचे दिए गए विभिन्न तरीके व्यावहारिक, उपयोगी हैं, एक संभावित उत्तर का अनुमान लगाने के लिए काम करने के तरीके , लेकिन ध्यान दें कि प्रश्न में ही यह गलतफहमी है कि, शाखाएं नहीं आती हैं। शाखाएँ आती हैं और जाती हैं, वे चलती हैं, केवल वास्तविक रेपो इतिहास का प्रतिनिधित्व करती हैं। तो फिर, यह नीचे समाधान बुरा कहने का एक तरीका नहीं है। बस पता है कि उनमें से कोई भी पूरी तरह से विश्वसनीय जवाब नहीं देता है, जो जीआईटी में डिजाइन द्वारा अप्राप्य है। (एक साधारण मामला हटाई गई शाखाएं हैं: मैं शाखा, मैं दो बार प्रतिबद्ध हूं, मैं दूसरी शाखा में विलीन हो जाता हूं, मैं पहली शाखा हटाता हूं। प्रतिबद्ध "से" कहां आता है?

— रोमेनवैलरी

मेरे पास एक मामला है जहां मैं स्पष्ट रूप से एक टैग से 1 उथले क्लोन को गहराई से खींचता हूं। यह सस्ता और आसान और कुशल है ... और अब तक मैंने वह सब कुछ किया जो मैं खूबसूरती से चाहता था। अब मैं यह जानना चाहूंगा कि टैग किस शाखा पर था, मैं कम से कम उस विवरण के लिए hosed हूं। आप हमेशा घर नहीं जा सकते, योग्य

— पॉल होजेस

Answer 1

जबकि Dav सही है कि जानकारी सीधे संग्रहीत नहीं है, इसका मतलब यह नहीं है कि आप कभी भी पता नहीं लगा सकते हैं। यहाँ कुछ चीजें हैं जो आप कर सकते हैं।

उन शाखाओं का पता लगाएं, जिन पर प्रतिबद्ध है

git branch -a --contains <commit>

यह आपको उन सभी शाखाओं के बारे में बताएगा जो उनके इतिहास में दिए गए वचन हैं। स्पष्ट रूप से यह कम उपयोगी है अगर कमिट का पहले से विलय हो गया हो।

Reflogs खोजें

यदि आप उस रिपॉजिटरी में काम कर रहे हैं जिसमें कमिट किया गया था, तो आप उस कमिट के लिए लाइन के रिफ्लॉग्स खोज सकते हैं। 90 दिनों से अधिक पुराने रिफ्लैक्स को git-gc द्वारा छेड़ा जाता है, इसलिए यदि कमिट बहुत पुरानी है, तो आपको यह नहीं मिलेगा। उस ने कहा, आप यह कर सकते हैं:

git reflog show --all | grep a871742

a871742 का पता लगाने के लिए। ध्यान दें कि आप कमिट के 7 पहले अंक का उपयोग करें। आउटपुट कुछ इस तरह होना चाहिए:

a871742 refs/heads/completion@{0}: commit (amend): mpc-completion: total rewrite

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

git reflog show वास्तव में सिर्फ एक उपनाम है git log -g --abbrev-commit --pretty=oneline , इसलिए यदि आप अलग-अलग चीजों के लिए तैयार करने के लिए आउटपुट फॉर्मेट के साथ फील करना चाहते हैं, तो यह आपका शुरुआती बिंदु है!

यदि आप उस रिपॉजिटरी में काम नहीं कर रहे हैं जहाँ कमेट बनाया गया था, तो आप इस मामले में सबसे अच्छा कर सकते हैं कि रिफ्लैक्स की जाँच करें और पाएं कि यह कमेटी पहली बार आपकी रिपॉजिटरी में कब आई थी; किसी भी भाग्य के साथ, आपने उस शाखा को प्राप्त किया जिसके लिए वह प्रतिबद्ध था। यह थोड़ा और अधिक जटिल है, क्योंकि आप दोनों प्रतिबद्ध पेड़ नहीं चल सकते हैं और एक साथ रिफ्लॉग कर सकते हैं। आप रिफ्लेक्स आउटपुट को पार्स करना चाहते हैं, प्रत्येक हैश की जांच करके देखें कि इसमें वांछित कमिटमेंट है या नहीं।

एक बाद मर्ज कमिट खोजें

यह वर्कफ़्लो-निर्भर है, लेकिन अच्छे वर्कफ़्लोज़ के साथ, विकास शाखाओं पर कमिट किए जाते हैं, जो तब विलय हो जाते हैं। आप ऐसा कर सकते हैं:

git log --merges <commit>..

मर्ज को देखने के लिए जो पूर्वज के रूप में दिए गए वचन हैं। (यदि प्रतिबद्ध केवल एक बार मर्ज किया गया था, तो पहले वाला मर्ज आपके बाद होना चाहिए; अन्यथा आपको कुछ जांच करनी होगी, मुझे लगता है।) मर्ज किए गए संदेश में वह शाखा नाम होना चाहिए जो मर्ज किया गया था।

यदि आप ऐसा करने में सक्षम होना चाहते हैं, तो आप फास्ट-फॉरवर्ड मामले में भी मर्ज कमिटेशन क्रिएशन को मजबूर --no-ffकरने के विकल्प का उपयोग कर सकते हैं git merge। (हालांकि, बहुत उत्सुक न हों, जो कि अधिक इस्तेमाल होने पर आपत्तिजनक हो सकता है।) संबंधित विषय में VonC का उत्तर इस विषय पर सहायक रूप से विस्तृत है।

Comments

+1। उस विशेष मुद्दे के लिए जानकारी की अनुपस्थिति आपको आश्चर्यचकित करती है कि क्या यह वास्तव में एक समस्या है? शाखाएँ कभी भी बदली जा सकती हैं, उनका नाम बदला जा सकता है या हटाया जा सकता है। हो सकता है git describeकि पर्याप्त हो, (एनोटेट) टैग को शाखाओं की तुलना में अधिक महत्वपूर्ण के रूप में देखा जा सकता है।

— VonC

मैं निश्चित रूप से सहमत हूं - शाखाएं हल्के और लचीली होने के लिए हैं। यदि आप कोई ऐसा वर्कफ़्लो अपनाते हैं जिसमें वह जानकारी महत्वपूर्ण हो जाती है, तो आप --no-ffयह सुनिश्चित करने के लिए विकल्प का उपयोग कर सकते हैं कि हमेशा एक मर्ज कमिट है, इसलिए आप हमेशा दिए गए कमिट का पथ ट्रेस कर सकते हैं क्योंकि यह मास्टर की ओर मर्ज हो जाता है।

— कास्केबेल

FYI करें, यदि आप कमिट करना चाहते हैं जो केवल रिमोट पर मौजूद है, -aतो पहले कमांड में ध्वज जोड़ें जैसेgit branch -a --contains <commit>

— जोनाथन डे

@JonathanDay: नहीं, जो किसी भी शाखा में कमिट करेगा। यदि आप रिमोट पर केवल चाहते हैं, का उपयोग करें -r।

— कैस्केबेल

@SimonTewsi जैसा मैंने कहा, अगर यह वास्तव में एक मुद्दा है, merge --no-ffतो मर्ज होने पर शाखा के नाम को मज़बूती से रिकॉर्ड करने के लिए उपयोग करें। लेकिन अन्यथा, शाखा नामों को अस्थायी संक्षिप्त लेबल के रूप में सोचें, और स्थायी रूप में विवरण दें। "विकास के दौरान हमने इसका क्या संक्षिप्त नाम बताया?" वास्तव में उतना महत्वपूर्ण प्रश्न नहीं होना चाहिए जितना कि "यह क्या करता है?"

— कास्कैबेल

Answer 2

यह सरल कमांड एक आकर्षण की तरह काम करता है:

git name-rev <SHA>

उदाहरण के लिए (जहां परीक्षण-शाखा का शाखा नाम है):

git name-rev 651ad3a
251ad3a remotes/origin/test-branch

यहां तक ​​कि यह जटिल परिदृश्यों के लिए काम कर रहा है, जैसे:

origin/branchA/
              /branchB
                      /commit<SHA1>
                                   /commit<SHA2>

यहाँ शाखा शाखाgit name-rev commit<SHA2> देता है ।

Comments

आपने मेरा दिन बचाया। यह अचूक उपाय है।

— टैको

और इस सही समाधान के लिए केवल 8 साल लगे। धन्यवाद!

— S1J0

मुझे git name-rev --name-only <SHA>केवल शाखा नाम प्राप्त करने के लिए अधिक उपयोगी पाया गया। मेरा प्रश्न ... क्या यह किसी भी परिस्थिति में एक से अधिक शाखाएँ लौटा सकता है?

— डीन केटन

यह सबसे अच्छा जवाब होना चाहिए।

— जोलियर

अपनी तरह के शब्दों के लिए @JCollier धन्यवाद।

— खिचड़ी.निल

Answer 3

अद्यतन दिसंबर 2013:

sschuberth टिप्पणियाँ

git-what-branch(पर्ल स्क्रिप्ट, नीचे देखें) अब बनाए नहीं लगती है। git-when-mergedपायथन में लिखा गया एक विकल्प है जो मेरे लिए बहुत अच्छा काम कर रहा है।

यह " मर्ज मर्ज खोजें जिसमें एक विशिष्ट कमिट शामिल है " पर आधारित है ।

git when-merged [OPTIONS] COMMIT [BRANCH...]

खोजें जब एक कमिट एक या एक से अधिक शाखाओं में विलय हो गई थी।
लाए गए मर्ज कमिटमेंट का पता लगाएंCOMMIT जो निर्दिष्ट ब्रांच (तों) में गया है।

विशेष रूप से, पहले-माता-पिता के इतिहास पर सबसे पुरानी प्रतिबद्धताओं को देखें, BRANCHजिसमें COMMITपूर्वज शामिल हैं।

---

मूल उत्तर सितंबर 2010:

सेबस्टियन डौश ने सिर्फ ट्विन (इस एसओ उत्तर से 16 मिनट पहले):

git-what-Branch : डिस्कवर करें कि कौन सी शाखा कमिट है, या इसे एक नामित शाखा कैसे मिली

यह सेठ रॉबर्टसन से एक पर्ल स्क्रिप्ट है जो बहुत दिलचस्प लगती है:

SYNOPSIS

git-what-branch [--allref] [--all] [--topo-order | --date-order ]
[--quiet] [--reference-branch=branchname] [--reference=reference]
<commit-hash/tag>...

अवलोकन

हमें बताएं (डिफ़ॉल्ट रूप से) कमिटेड पथ का प्रारंभिक कारण और मर्ज एक अनुरोधित शाखा को मिला। यदि एक नामित शाखा पर सीधे प्रतिबद्ध किया गया था, तो यह स्पष्ट रूप से सबसे प्रारंभिक पथ है।

शुरुआती कार्य पथ से हमारा तात्पर्य उस पथ से है जो एक नामित शाखा में जल्द से जल्द विलय हो जाता है, प्रतिबद्ध समय तक (जब तक --topo-orderकि निर्दिष्ट नहीं है)।

प्रदर्शन

यदि कई शाखाओं (जैसे सैकड़ों) में कमिटमेंट होता है, तो सिस्टम को एक लंबा समय लग सकता है (लिनक्स ट्री में किसी विशेष कमिट के लिए, एक ब्रांच का पता लगाने में 8 सेकंड का समय लगता है, लेकिन पथ को ट्रैक करने के लिए 200 से अधिक उम्मीदवार शाखाएं थीं) प्रत्येक करने के लिए। जांच करने के लिए
किसी विशेष का चयन --reference-branch --reference tagतेजी से सैकड़ों गुना होगा (यदि आपके पास सैकड़ों उम्मीदवार शाखाएं हैं)।

उदाहरण

 # git-what-branch --all 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto master using the following minimal temporal path:
   v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May  5 08:59:37 2005)
   v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Tue May  3 18:27:24 2005)
   v2.6.12-rc3-461-g84e48b6 is on master
   v2.6.12-rc3-461-g84e48b6 is on v2.6.12-n
   [...]

यह कार्यक्रम केवल ब्याज को कम करने के लिए चेरी के प्रभाव को ध्यान में नहीं रखता है, केवल संचालन को मर्ज करता है।

Comments

git-what-branchअब इसका रखरखाव नहीं किया जा रहा है। git-When-merged Python में लिखा गया एक विकल्प है जो मेरे लिए बहुत अच्छा काम कर रहा है।

— sschuberth

@sschuberth इस अपडेट के लिए धन्यवाद। अधिक दृश्यता के उत्तर में मैंने आपकी टिप्पणी शामिल की है।

— वॉनसी

Answer 4

उदाहरण के लिए, यह पता लगाने के लिए कि c0118faकमेट कहां से आया redesign_interactions:

* ccfd449 (HEAD -> develop) Require to return undef if no digits found
*   93dd5ff Merge pull request #4 from KES777/clean_api
|\
| * 39d82d1 Fix tc0118faests for debugging debugger internals
| * ed67179 Move &push_frame out of core
| * 2fd84b5 Do not lose info about call point
| * 3ab09a2 Improve debugger output: Show info about emitted events
| *   a435005 Merge branch 'redesign_interactions' into clean_api
| |\
| | * a06cc29 Code comments
| | * d5d6266 Remove copy/paste code
| | * c0118fa Allow command to choose how continue interaction
| | * 19cb534 Emit &interact event

आपको दौड़ना चाहिए:

git log c0118fa..HEAD --ancestry-path --merges

और अंतिम मर्ज कमिटमेंट खोजने के लिए नीचे स्क्रॉल करें । जो है:

commit a435005445a6752dfe788b8d994e155b3cd9778f
Merge: 0953cac a06cc29
Author: Eugen Konkov
Date:   Sat Oct 1 00:54:18 2016 +0300

    Merge branch 'redesign_interactions' into clean_api

अपडेट करें

या सिर्फ एक आदेश:

git log c0118fa..HEAD --ancestry-path --merges --oneline --color | tail -n 1

Comments

यह एकमात्र समाधान था जिसने मुझे वांछित परिणाम दिया। मैंने बाकी कोशिश की।

— crafter

ध्यान दें कि यह केवल तभी काम करता है जब मर्ज कम समरी में मर्ज में उपयोग की जाने वाली शाखा के नाम होते हैं, जो डिफ़ॉल्ट रूप से वे आमतौर पर करते हैं। हालांकि git merge -m"Any String Here"स्रोत और लक्ष्य शाखा की जानकारी को अस्पष्ट करेगा।

— 22

@qneill: नहीं, मर्ज में हमेशा मर्ज की गई शाखाओं के बारे में जानकारी होती है Merge: f6b70fa d58bdcb:। आप अपने मर्ज कमिटमेंट को अपने नाम कर सकते हैं। मुझे कोई फर्क नहीं पड़ेगा

— Eugen Konkov

@EugenKonkov ने एक बार शाखाओं के मर्ज का पता लगा लिया है, जिस इतिहास के बारे में वे ग्राफ में आए थे, उसे रिफ्लग में छोड़ दिया गया था, लेकिन गिट ऑब्जेक्ट डेटाबेस में नहीं। मैंने एक उत्तर देने की कोशिश की कि मैं क्या कह रहा हूँ

— 21

यूपीडी संस्करण मेरे लिए काम करता है, साधारण कमांड जो मूल प्रतिबद्ध पाता है

— vpalmu

Answer 5

git branch --contains <ref>ऐसा करने के लिए सबसे स्पष्ट "चीनी मिट्टी के बरतन" आदेश है। यदि आप केवल "प्लंबिंग" कमांड के साथ कुछ ऐसा ही करना चाहते हैं:

COMMIT=$(git rev-parse <ref>) # expands hash if needed
for BRANCH in $(git for-each-ref --format "%(refname)" refs/heads); do
  if $(git rev-list $BRANCH | fgrep -q $COMMIT); then
    echo $BRANCH
  fi
done

( इस SO उत्तर से क्रॉसपोस्ट )

Answer 6

khichar.anil ने अपने जवाब में इस बात को कवर किया ।

मैं केवल उस ध्वज को जोड़ रहा हूं जो संशोधन नाम सूची से टैग हटा देगा। यह हमें देता है:

git name-rev --name-only --exclude=tags/* $SHA

Comments

दूसरे वाक्य में कुछ याद आ रहा है।

— पीटर मोर्टेंसन

मैंने विवरण अपडेट किया। प्रतिक्रिया के लिए Thx।

— phyatt

Answer 7

एक गरीब आदमी का विकल्प का उपयोग करने के लिए है उपकरण tig¹ पर HEAD, प्रतिबद्ध के लिए खोज, और फिर नेत्रहीन लाइन है कि से वापस ऊपर जब तक किसी मर्ज प्रतिबद्ध देखा जाता है प्रतिबद्ध का पालन करें। डिफ़ॉल्ट मर्ज संदेश में यह निर्दिष्ट होना चाहिए कि किस शाखा को कहाँ विलय किया जा रहा है :)

¹ टिगिट Git के लिए एक ncurses- आधारित टेक्स्ट-मोड इंटरफ़ेस है। यह मुख्य रूप से Git रिपॉजिटरी ब्राउज़र के रूप में कार्य करता है, लेकिन यह चंक स्तर पर प्रतिबद्धताओं में परिवर्तन करने में मदद कर सकता है और विभिन्न Git कमांड से आउटपुट के लिए पेजर के रूप में कार्य कर सकता है।

Answer 8

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

आप इसे यहां देख सकते हैं: https://github.com/pajp/branch-info-commits

Comments

लेकिन अगर आप मेटाडेटा जोड़ना चाहते हैं, तो कमिट के हेडर के साथ खिलवाड़ करने के बजाय, गिट नोट्स का उपयोग क्यों नहीं करते? देखें stackoverflow.com/questions/5212957/... , stackoverflow.com/questions/7298749/... या stackoverflow.com/questions/7101158/...

— VonC

ईमानदार होने के लिए, मुझे नहीं पता था कि जब मैंने लिखा था कि git नोट्स मौजूद थे। हाँ, समान चीज़ों को प्राप्त करने के लिए git नोट्स का उपयोग करना शायद एक बेहतर विचार है।

— पजप

Answer 9

मैं उसी समस्या ( जेनकिन्स) से निपटता हूं मल्टीब्रांच पाइपलाइन) से - केवल जानकारी रखने और एक शाखा का नाम खोजने की कोशिश कर जहां यह प्रतिबद्ध मूल रूप से आया था। यह दूरस्थ शाखाओं के लिए काम करना चाहिए, स्थानीय प्रतियां उपलब्ध नहीं हैं।

इसके साथ मैं काम करता हूं:

git rev-parse HEAD | xargs git name-rev

वैकल्पिक रूप से आप आउटपुट स्ट्रिप कर सकते हैं:

git rev-parse HEAD | xargs git name-rev | cut -d' ' -f2 | sed 's/remotes\/origin\///g'

Answer 10

मुझे लगता है कि किसी को उसी समस्या का सामना करना चाहिए जो शाखा का पता नहीं लगा सकता है, हालांकि यह वास्तव में एक शाखा में मौजूद है।

आप बेहतर तरीके से सभी को पहले खींच लेंगे:

git pull --all

फिर शाखा खोज करें:

git name-rev <SHA>

या:

git branch --contains <SHA>

Answer 11

यदि ओपी उस इतिहास को निर्धारित करने की कोशिश कर रहा है जो एक विशेष प्रतिबद्ध बनाया गया था, तो एक शाखा द्वारा ट्रेस किया गया था ("पता करें कि एक शाखा क्या दिया गया है जो उसके SHA-1 हैश मान से आता है"), तो रिफ्लेक्ट के बिना कोई भी नहीं है गिट ऑब्जेक्ट डेटाबेस में रिकॉर्ड जो दिखाता है कि नामित शाखा क्या इतिहास के लिए बाध्य थी।

(मैंने इसे एक टिप्पणी के जवाब में उत्तर के रूप में पोस्ट किया है।)

उम्मीद है कि यह स्क्रिप्ट मेरी बात को स्पष्ट करती है:

rm -rf /tmp/r1 /tmp/r2; mkdir /tmp/r1; cd /tmp/r1
git init; git config user.name n; git config user.email [e-mail]
git commit -m"empty" --allow-empty; git branch -m b1; git branch b2
git checkout b1; touch f1; git add f1; git commit -m"Add f1"
git checkout b2; touch f2; git add f2; git commit -m"Add f2"
git merge -m"merge branches" b1; git checkout b1; git merge b2
git clone /tmp/r1 /tmp/r2; cd /tmp/r2; git fetch origin b2:b2
set -x;
cd /tmp/r1; git log --oneline --graph --decorate; git reflog b1; git reflog b2;
cd /tmp/r2; git log --oneline --graph --decorate; git reflog b1; git reflog b2;

आउटपुट यह जानने के लिए किसी भी तरह की कमी को दर्शाता है कि क्या 'Add f1' के साथ कमिटमेंट रिमोट क्लोन / tmp / r2 से शाखा b1 या b2 से आया है।

(यहां आउटपुट की अंतिम लाइनें)

+ cd /tmp/r1
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: merge b2: Fast-forward
086c9ce b1@{1}: commit: Add f1
18feb84 b1@{2}: Branch: renamed refs/heads/master to refs/heads/b1
18feb84 b1@{3}: commit (initial): empty
+ git reflog b2
f0c707d b2@{0}: merge b1: Merge made by the 'recursive' strategy.
80c10e5 b2@{1}: commit: Add f2
18feb84 b2@{2}: branch: Created from b1
+ cd /tmp/r2
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, origin/b2, origin/b1, origin/HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: clone: from /tmp/r1
+ git reflog b2
f0c707d b2@{0}: fetch origin b2:b2: storing head

Comments

और दोनों मामलों के लिए आउटपुट git log 80c10e5..HEAD --ancestry-path --merges --oneline --color | tail -n 1और git log 086c9ce..HEAD --ancestry-path --merges --oneline --color | tail -n 1कमांड क्या है ?

— यूजेन कोनकोव

किसी भी समय कमांड के चलने पर SHA बदल जाते हैं, आपके आदेशों का सम्मान करने के लिए मैंने ताज़े रन पर HEAD ^ 1 और HEAD ^ 2 का उपयोग किया। कमांड और आउटपुट हैं: $ git log HEAD^1..HEAD --ancestry-path --merges --oneline --color | tail -n 1जो पैदावार 376142d merge branchesऔर $ git log HEAD^2..HEAD --ancestry-path --merges --oneline --color | tail -n 1जो उपज देता है 376142d merge branches - जो मर्ज कम सारांश दिखाता है, जो (जैसा कि मैं जोर दे रहा था) को मर्ज किए जाने पर ओवरराइट किया जा सकता है, संभवतः मर्ज के शाखा इतिहास को बाधित करता है।

— क़ैनिल

Answer 12

टी एल; डॉ:

यदि आप शेल निकास स्थितियों के बारे में परवाह करते हैं तो नीचे का उपयोग करें:

• branch-current - वर्तमान शाखा का नाम
• branch-names - स्वच्छ शाखा नाम (प्रति पंक्ति एक)
• branch-name - सुनिश्चित करें कि केवल एक शाखा से लौटा है branch-names

दोनों branch-nameऔर branch-namesस्वीकार एक तर्क के रूप में प्रतिबद्ध है, और करने के लिए डिफ़ॉल्ट HEADअगर कोई भी दिया जाता है।

---

स्क्रिप्टिंग में उपयोगी

branch-current = "symbolic-ref --short HEAD"  # https://stackoverflow.com/a/19585361/5353461
branch-names = !"[ -z \"$1\" ] && git branch-current 2>/dev/null || git branch --format='%(refname:short)' --contains \"${1:-HEAD}\" #"  # https://stackoverflow.com/a/19585361/5353461
branch-name = !"br=$(git branch-names \"$1\") && case \"$br\" in *$'\\n'*) printf \"Multiple branches:\\n%s\" \"$br\">&2; exit 1;; esac; echo \"$br\" #"

---

केवल एक ही शाखा से पहुंच योग्य कमिट करें

% git branch-name eae13ea
master
% echo $?
0

• आउटपुट STDOUT को है
• निकास मान है 0।

---

कई शाखाओं से पहुंच योग्य है

% git branch-name 4bc6188
Multiple branches:
attempt-extract
master%
% echo $?
1

• आउटपुट STDERR को है
• बाहर निकलने का मूल्य है 1।

---

बाहर निकलने की स्थिति के कारण, इन्हें सुरक्षित रूप से बनाया जा सकता है। उदाहरण के लिए, लाने के लिए रिमोट का उपयोग करना:

remote-fetch = !"branch=$(git branch-name \"$1\") && git config branch.\"$branch\".remote || echo origin #"

Answer 13

स्थानीय शाखा खोजने के लिए:

grep -lR YOUR_COMMIT .git/refs/heads | sed 's/.git\/refs\/heads\///g'

दूरस्थ शाखा खोजने के लिए:

grep -lR $commit .git/refs/remotes | sed 's/.git\/refs\/remotes\///g'

Comments

आपके उदाहरणों के कुछ स्पष्टीकरण महान होंगे

— यूजेन कोनकोव

Answer 14

जब तक आप एक मेलिंग हैश नहीं पाते, तब तक पेड़ के सभी खोज के अलावा।

Comments

मैं वास्तव में इसे कम नहीं करना चाहता, क्योंकि सख्ती से यह कहना सही है कि git उस जानकारी को स्थायी रूप से संग्रहीत नहीं करता है, लेकिन फिर भी यह पता लगाना बहुत संभव है। मेरा जवाब देखिए।

— Cascabel