मैं git में अगली कमिटमेंट कैसे ढूँढूँ? (बच्चे / रेफरी के बच्चे)


236

ref^पहले कमिट को संदर्भित करता है ref, उसके बाद कमिटमेंट प्राप्त करने के बारे में क्या ref?

उदाहरण के लिए, अगर मैं git checkout 12345अगली प्रतिबद्धता की जाँच कैसे करूँ?

धन्यवाद।

PS हाँ, git का DAG नोड पॉइंटर पॉटर ट्री जो भी हो। इस एक के बाद मैं कैसे पा सकता हूं?


4
डुप्लिकेट: stackoverflow.com/questions/1761825/…
hcs42

2
" git children-of" भी देखें !
VonC

जवाबों:


185

सभी कमिट्स को सूचीबद्ध करने के लिए, वर्तमान एक से शुरू, और फिर उसके बच्चे, और इसी तरह - मूल रूप से मानक गिट लॉग, लेकिन समय में दूसरे तरीके से जाना, कुछ का उपयोग करें

git log --reverse --ancestry-path 894e8b4e93d8f3^..master

जहां 894e8b4e93d8f3 वह पहला कमिट है जिसे आप दिखाना चाहते हैं।


3
मूल प्रश्न में विशिष्ट मामले के लिए, केवल विकल्प के HEAD^लिए 894e8b4e93d8f3^
सोरेन लोर्बोर्ग

2
हो सकता है, ऐड -ऑनलाइन एक बेहतर संक्षिप्त आउटपुट परिणाम हो।
फिरोज

1
मुझे उपयोग करने की आवश्यकता है ..., ^..चुपचाप विफल रहता है
टैंकोरशश

1
हो रही fatal: unrecognized argument: --ancestry-pathमें Git संस्करण 1.7.1
user151841

6
यह केवल तभी काम करेगा masterजब करंट कमिट के पुश्तैनी रास्ते पर हो। एक समाधान के लिए मेरा उत्तर दूसरा कोड स्निपेट देखें जो सभी मामलों में काम करेगा।
टॉम हेल

37

हडसन (अब जेनकिंस) कोहसके कावागुची के लिए निर्माता अभी (नवंबर 2013) प्रकाशित हुआ:
कोह्सके / गिट-बच्चे-ऑफ़ :

एक कमिट को देखते हुए, उस कमेट के तत्काल बच्चों को खोजें।

#!/bin/bash -e
# given a commit, find immediate children of that commit.
for arg in "$@"; do
  for commit in $(git rev-parse $arg^0); do
    for child in $(git log --format='%H %P' --all | grep -F " $commit" | cut -f1 -d' '); do
      git describe $child
    done
  done
done

जैसा कि इस धागे से दर्शाया गया है , DAG (डायरेक्टेड एसाइक्लिक ग्राफ) द्वारा दर्शाए गए इतिहास पर आधारित VCS में , "एक माता-पिता" या "एक बच्चा" नहीं है।

        C1 -> C2 -> C3
      /               \
A -> B                  E -> F
      \               /
        D1 -> D2 ----/

कमिट्स का ऑर्डर " टॉपो -ऑर्डर" या "डेट-ऑर्डर" द्वारा किया जाता है ( GitPro पुस्तक देखें )

लेकिन Git1.6.0 के बाद से , आप कमिट के बच्चों को सूचीबद्ध कर सकते हैं।

git rev-list --children
git log --children

नोट: माता-पिता के लिए , आपके पास एक ही समस्या है, प्रत्यय के साथ ^एक संशोधन पैरामीटर का अर्थ है कि उस प्रतिबद्ध वस्तु का पहला अभिभावक। वें अभिभावक का ^<n>अर्थ है <n>(यानी rev^ के बराबर rev^1)।

यदि आप शाखा पर हैं fooऔर " git merge bar" जारी करते हैं, तो fooपहले अभिभावक होंगे।
Ie: पहला अभिभावक वह शाखा है जिस पर आप विलय के समय थे, और दूसरा उस शाखा पर प्रतिबद्ध है जिसे आपने विलय किया था।


6
git rev-list --childrenयकीन है कि मैं चाहता हूँ की तरह लग रहा है, लेकिन यह DWIM नहीं है। यह सभी माता-पिता और उनके बच्चों को सूचीबद्ध करता प्रतीत होता है। मुझे लगता है कि मैं उन सभी को सूचीबद्ध कर सकता हूं और उनके माध्यम से पार्स कर सकता हूं ... ब्लह, लेकिन इसकी कुछ।
Schwern

@ शार्र्न: सच, git rev-list --childrenसिर्फ बच्चों की सूची बनाने के लिए नहीं है, बल्कि अपने बच्चों के साथ माता-पिता को सूचीबद्ध करने के लिए ... आपको हमेशा पार्स करने की जरूरत है।
वॉन

मैंने दो बच्चों के साथ एक कोड पर उस कोड की कोशिश की: आपको $ git children0of 9dd5932 fatal: No annotated tags can describe '71d7b5dd89d241072a0a078ff2c7dfec05d52e1f'. However, there were unannotated tags: try --tags. क्या आउटपुट मिलता है?
टॉम हेल

@TomHale मैं अभी इसका परीक्षण नहीं कर सकता, लेकिन एक नया प्रश्न पूछें (OS और Git संस्करण के साथ), जिस तरह से हर कोई परीक्षण कर सकता है।
वॉनसी

1
इसके साथ एकमात्र समस्या git-children-ofयह है कि यह git वर्णन का उपयोग करता है जो SHA को मानव-पठनीय के रूप में प्रारूपित करने का प्रयास करता है, जो @ TomHale की त्रुटि के साथ विफल हो सकता है, और v1.0.4-14-g2414721यदि आप SHA की अपेक्षा करते हैं तो इस तरह के परिणाम भ्रमित करते हैं। एक साधारण के साथ इसे बदलने से यह echoएक उत्कृष्ट उपकरण बन जाता है, धन्यवाद!
निकोले

18

जो मैंने पाया है

git rev-list --ancestry-path commit1..commit2

जहां मैं commit1वर्तमान प्रतिबद्ध और commit2वर्तमान प्रमुख के रूप में सेट हूं । यह मुझे उन सभी कमिटों की एक सूची देता है, जो commit1और के बीच का रास्ता बनाते हैं commit2

आउटपुट की अंतिम पंक्ति कमिट 1 का बच्चा है (कमिट के पथ पर)।


3
तो बस | tail -1बच्चे को पाने के लिए जोड़ें ।
जेसी ग्लेक

8

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

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

किसी भी दर पर, मैं इस सवाल पर आया क्योंकि मैं बस एक समय में इतिहास में एक कदम आगे बढ़ना चाहता हूं, परीक्षण कर रहा हूं, और कभी-कभी आपको आगे बढ़ना होगा और पिछड़े नहीं। खैर, कुछ और सोच के साथ मैं इस समाधान के साथ आया:

आप जहां हैं, उसके आगे एक कमिट चुनें। यह शायद एक शाखा प्रमुख हो सकता है। यदि आप शाखा ~ 10 पर हैं, तो "git चेकआउट शाखा ~ 9" तो "git चेकआउट शाखा ~ 8" उसके बाद अगला प्राप्त करने के लिए, फिर "git चेकआउट शाखा ~ 7" और इसी तरह।

यदि आपकी आवश्यकता है, तो संख्या को घटाना वास्तव में एक स्क्रिप्ट में आसान होना चाहिए। जीआईएस रि-लिस्ट पार्स करने से बहुत आसान है।


उपयोगी होते हुए भी, यह अगली प्रतिबद्ध नहीं है। यह वर्तमान प्रतिबद्ध की ओर चलता है।
श्वार्स

1
ठीक है तो मुझे लगता है कि आप कर सकते हैं: " BRANCH=master; git co $BRANCH~$[ $(git rev-list HEAD..$BRANCH | wc -l) - 1 ]" आप एक शाखा की ओर जाने के लिए मिल गए हैं, इसके अलावा कोई रास्ता नहीं है।
vontrapp

8

दो व्यावहारिक उत्तर:

एक बच्चा

@ माइकल के उत्तर के आधार पर , मैंने childअपने में अन्य लोगों को हैक किया .gitconfig

यह डिफ़ॉल्ट मामले में उम्मीद के मुताबिक काम करता है, और बहुमुखी भी है।

# Get the child commit of the current commit.
# Use $1 instead of 'HEAD' if given. Use $2 instead of curent branch if given.
child = "!bash -c 'git log --format=%H --reverse --ancestry-path ${1:-HEAD}..${2:\"$(git rev-parse --abbrev-ref HEAD)\"} | head -1' -"

यह वंशावली के बच्चे को वर्तमान शाखा की नोक की ओर एक कदम पीछे (जब तक एक और कम-ईश दूसरे तर्क के रूप में नहीं दिया जाता है) को HEAD के बच्चे को देने में चूक करता है।

अगर आप शॉर्ट हैश फॉर्म चाहते हैं तो %hइसके बजाय उपयोग करें %H

कई बच्चे

एक अलग हेड (कोई शाखा नहीं है) या शाखाओं की परवाह किए बिना सभी बच्चों को पाने के लिए:

# For the current (or specified) commit-ish, get the all children, print the first child 
children = "!bash -c 'c=${1:-HEAD}; set -- $(git rev-list --all --not \"$c\"^@ --children | grep $(git rev-parse \"$c\") ); shift; echo $1' -"

सभी बच्चों को प्रिंट $1करने के $*लिए बदलें ।

आप --allकेवल उन बच्चों को प्रदर्शित करने के लिए एक कमिट-इश में बदल सकते हैं , जो उस वचन के पूर्वजों हैं- दूसरे शब्दों में, केवल बच्चों को "दिए गए वचन" की दिशा में प्रदर्शित करने के लिए। यह आपको कई बच्चों से सिर्फ एक तक उत्पादन को कम करने में मदद कर सकता है।


7

कोई अद्वितीय "अगला कमिट" नहीं है। क्योंकि Git में इतिहास एक DAG है, और एक पंक्ति नहीं है, कई कमिट्स में एक सामान्य माता-पिता (शाखाएं) हो सकते हैं, और कमिट में एक से अधिक माता-पिता (मर्ज) हो सकते हैं।

यदि आपके पास एक विशेष शाखा है, तो आप इसके लॉग को देख सकते हैं और देख सकते हैं कि वर्तमान में इसके माता-पिता के रूप में कौन सी प्रतिबद्धता सूचीबद्ध है।


37
उस तर्क के द्वारा या तो कोई "पिछली प्रतिबद्धता" नहीं है, लेकिन माता-पिता को प्राप्त करने के लिए बहुत सारे वाक्यविन्यास हैं।
Schwern

7
@ शकरन: कोई "पिछली प्रतिबद्ध" भी नहीं है; <rev>^"पेरेंट कमिट" (मर्ज कमिट के लिए 'पहला पेरेंट' है)
जकुब नारबस्की

6

मैंने कई अलग-अलग समाधानों की कोशिश की है और कोई भी मेरे लिए काम नहीं करता है। खुद के साथ आना पड़ा।

अगला कमिटमेंट खोजें

function n() {
    git log --reverse --pretty=%H master | grep -A 1 $(git rev-parse HEAD) | tail -n1 | xargs git checkout
}

पिछली प्रतिबद्ध खोजें

function p() {
    git checkout HEAD^1
}

6

उस स्थिति में जहां आपके पास कोई विशेष "गंतव्य" नहीं है, लेकिन मन में यह देखना चाहते हैं कि बच्चे किसी भी शाखा में हो सकते हैं, आप इस आदेश का उपयोग कर सकते हैं:

git rev-list --children --all | grep ^${COMMIT}

यदि आप सभी बच्चों और भव्य बच्चों को देखना चाहते हैं , तो आपको rev-list --childrenपुनरावर्ती उपयोग करना होगा , जैसे:

git rev-list --children --all | \
egrep ^\($(git rev-list --children --all | \
           grep ^${COMMIT} | \
           sed 's/ /|/g')\)

(वह संस्करण जो केवल ग्रैंड-चिल्ड्रन देता है, अधिक जटिल sedऔर / या का उपयोग करेगा cut।)

अंत में, आप log --graphपेड़ की संरचना को देखने के लिए एक कमांड में फ़ीड कर सकते हैं, जैसे:

git log --graph --oneline --decorate \
\^${COMMIT}^@ \
$(git rev-list --children --all | \
  egrep ^\($(git rev-list --children --all | \
             grep ^${COMMIT} | \
             sed 's/ /|/g')\))

नोट : उपर्युक्त सभी आदेश यह मान लेते हैं कि आपने ${COMMIT}जिस विषय के बच्चों में रुचि रखते हैं, उसके कुछ संदर्भ (शाखा, टैग, sha1) में शेल चर सेट किया है।


2
यह सवाल का जवाब देता है जो मुझे नहीं पता था कि Google और स्टैकओवरफ़्लो के लिए कैसे तैयार किया जाए, लेकिन यह पूछने की कोशिश कर रहा था। लगातार जरूरत को पहचानने के लिए धन्यवाद
टॉमी नोल्सटन

मेरे लिए ${COMMIT}नहीं है, लेकिन आप $(git rev-parse HEAD) इसके बजाय इस्तेमाल कर सकते हैं
Radon8472

क्षमा करें, के बारे में एक नोट जोड़ा ${COMMIT}
मैट मैकेंरी

5

(यह एक डुप्लिकेट प्रश्न के उत्तर के रूप में शुरू हुआ था। मैंने इसे साफ करने के लिए हल्का संपादन किया है।)

Git के सभी आंतरिक तीर एक तरफ़ा हैं, जो पीछे की ओर इशारा करते हैं। इसलिए आगे बढ़ने के लिए कोई छोटा सुविधाजनक वाक्यविन्यास नहीं है: यह सिर्फ संभव नहीं है।

यह है अगर आप इसे से पहले बाद में नहीं देखा है, और फिर स्पष्ट "तीर के खिलाफ कदम" है, लेकिन जिस तरह से यह आश्चर्य की बात है क्या करने के लिए करने के लिए संभव। मान लें कि हमारे पास है:

A <-B <-C <-D <-E   <-- last
        ^
        |
         \--------- middle

पीछे middle~2से दो बार तीरों का उपयोग करना । तो हम से कैसे ले जाऊं करने के लिए ? जवाब है: हम पर शुरू , नाम का उपयोग कर , और काम पीछे की ओर जब तक हम करने के लिए मिल , अंक हम रास्ते को रिकॉर्ड । फिर हम केवल उसी दिशा में आगे बढ़ते हैं, जिस दिशा में हम चाहते हैं : एक-एक कदम , या दो से ।CACDElastmiddlelastDE

जब हमारे पास शाखाएँ हों तो यह विशेष रूप से महत्वपूर्ण है:

          D--E   <-- feature1
         /
...--B--C   <-- master
         \
          F--G   <-- feature2

एक कदम के बाद कौन सा प्रतिबद्ध है C? जब तक आप सवाल नहीं जोड़ते हैं, तब तक कोई सही उत्तर नहीं है: feature___ (रिक्त स्थान भरें) की दिशा में

स्वयं C(और छोड़कर C) के बीच के कमिट्स की गणना करने के लिए G, हम उपयोग करते हैं:

git rev-list --topo-order --ancestry-path master..feature2

यह --topo-orderसुनिश्चित करता है कि जटिल ब्रांचिंग-एंड-मर्जिंग की उपस्थिति में भी, कम्यूट टोपोलॉजिकली-सॉर्ट किए गए क्रम में निकलते हैं। यह केवल तभी आवश्यक है जब श्रृंखला रैखिक न हो। --ancestry-pathबाधा साधन जब हम से पीछे की ओर काम करते हैं कि feature2, है कि हम केवल सूची प्रतिबद्ध प्रतिबद्ध Cअपने स्वयं के पूर्वजों में से एक के रूप में। यह है, अगर ग्राफ - या प्रासंगिक हिस्सा वैसे भी - वास्तव में इस तरह दिखता है:

A--B--C   <-- master
 \     \
  \     F--G--J   <-- feature2
   \         /
    H-------I   <-- feature3

फार्म की एक साधारण अनुरोध feature2..masterकरता विश्लेषण करता है J, Gऔर I, और Fऔर Hकिसी क्रम में। साथ --ancestry-pathहम बाहर दस्तक Hऔर Iवे के वंशज नहीं हैं Cकेवल की, A। साथ --topo-orderहम चाहते हैं कि वास्तविक गणना आदेश है यह सुनिश्चित कर लें J, तो G, तो F

git rev-listआदेश अपने मानक उत्पादन, प्रति पंक्ति एक पर बाहर इन हैश आईडी फैल। की दिशा में एक कदम आगे बढ़ने के लिए feature2, फिर, हम केवल अंतिम पंक्ति चाहते हैं ।

इसे जोड़ना संभव है (और लुभाना और उपयोगी हो सकता है) --reverseताकि git rev-listउन्हें उत्पन्न करने के बाद उल्टे क्रम में कमेंट प्रिंट किया जा सके। यह काम करता है, लेकिन अगर आप इसे इस तरह से पाइपलाइन में उपयोग करते हैं:

git rev-list --topo-order --ancestry-path --reverse <id1>...<id2> | head -1

बस "id2 की दिशा में अगली प्रतिबद्धता" प्राप्त करने के लिए, और आवागमन की एक बहुत लंबी सूची है, git rev-listकमांड को एक टूटी हुई पाइप मिल सकती है जब वह लिखने की कोशिश करता है headजिससे उसका इनपुट पढ़ना बंद हो जाता है और बाहर निकल जाता है। चूंकि टूटी-पाइप त्रुटियों को आमतौर पर शेल द्वारा अनदेखा किया जाता है, यह ज्यादातर काम करता है। बस सुनिश्चित करें कि वे आपके उपयोग में नजरअंदाज कर रहे हैं ।

यह कमांड के साथ जोड़ने के -n 1लिए भी आकर्षक है । यह मत करो! यह एक कदम पीछे चलने के बाद रुक जाता है , और फिर आने वाले आवागमन की सूची (एक-प्रविष्टि) को उल्टा कर देता है। तो यह सिर्फ हर बार पैदा करता है।git rev-list--reversegit rev-list<id2>

महत्वपूर्ण पक्ष नोट

ध्यान दें कि "डायमंड" या "बेंजीन रिंग" ग्राफ के टुकड़े के साथ:

       I--J
      /    \
...--H      M--...  <-- last
      \    /
       K--L

चलती एक "आगे" से प्रतिबद्ध Hके प्रति lastआप मिल जाएगा या तो I या K । आप इसके बारे में कुछ भी नहीं कर सकते हैं: दोनों कमिट एक कदम आगे हैं! यदि आप फिर परिणामी कमिट से शुरू करते हैं और एक और कदम बढ़ाते हैं, तो आप अब आपके द्वारा शुरू किए गए पथ को पूरा करने के लिए प्रतिबद्ध हैं।

इसका इलाज यह है कि एक समय में एक कदम आगे बढ़ने से बचें और पथ-निर्भर श्रृंखलाओं में बंद हो जाएं। इसके बजाय, यदि आप कुछ और करने से पहले पूरी वंशावली-पथ श्रृंखला पर जाने की योजना बनाते हैं, तो श्रृंखला में सभी कमिट की पूरी सूची बनाएं :

git rev-list --topo-order --reverse --ancestry-path A..B > /tmp/list-of-commits

फिर, इस सूची में प्रत्येक कमिट पर जाएँ, एक बार में, और आपको पूरी श्रृंखला मिल जाएगी। यह --topo-orderसुनिश्चित करेगा कि आप हिट- Iऔर Jउस क्रम में, और- Kऔर- Lउस क्रम में (हालांकि यह अनुमान लगाने का कोई आसान तरीका नहीं है कि आप केएल जोड़ी से पहले या बाद में IJ जोड़ी करेंगे या नहीं)।


" जब तक आप प्रश्न में जोड़ते हैं तब तक कोई सही उत्तर नहीं है: feature___ की दिशा में " यह एक बहुत अच्छा बिंदु है। आपके उत्तर के लिए धन्यवाद।
श्वर्न

4

मेरे पास यह उपनाम है ~/.gitconfig

first-child = "!f() { git log  --reverse --ancestry-path --pretty=%H $1..${2:-HEAD} | head -1; }; f"


क्या है f()? और इसे head -1पहला बच्चा होने की आवश्यकता है , अन्यथा यह केवल हेड को रिपोर्ट करेगा।
ज़ेरुस

@Xerus क्योंकि यह कुछ "जटिल" शेल सिंटैक्स का उपयोग करता है, और गिट इसे लिपटे नहीं होने पर पहचान नहीं करेगा f()। हाँ, head -1एक बहादुर अनुमान है।
कमजोर

अच्छा! मेरा nextref = "!f() { git log --reverse --ancestry-path --pretty=%H $1..HEAD | head -${2:-1} | tail -1; }; f"
मुड़

2

मैं अगले बच्चे को निम्नलिखित तरीके से खोजने में कामयाब रहा:

git log --reverse --children -n1 HEAD (where 'n' is the number of children to show)

1
मेरे लिए यह पहला बच्चा नहीं है, यह वर्तमान प्रतिबद्धता को दर्शाता है
Radon8472

2

यदि बच्चा करता है, तो सभी किसी न किसी शाखा पर हैं, आप उपयोग कर सकते हैं gitk --all commit^.., जहां "प्रतिबद्ध" कुछ ऐसा है जो प्रतिबद्ध की पहचान कर रहा है। उदाहरण के लिए, यदि कमिटेड संक्षिप्त SHA-1 c6661c5 है, तो टाइप करेंgitk --all c6661c5^..

आपको संभवतः पूर्ण SHA-1 को gitk की "SHA1 ID:" सेल में दर्ज करना होगा। आपको पूर्ण SHA-1 की आवश्यकता होगी, जो इस उदाहरण के माध्यम से प्राप्त किया जा सकता हैgit rev-parse c6661c5

वैकल्पिक रूप से, git rev-list --all --children | grep '^c6661c5883bb53d400ce160a5897610ecedbdc9d'इस प्रतिबद्ध के सभी बच्चों वाली एक पंक्ति का उत्पादन करेगा, संभवत: इसमें एक शाखा शामिल है या नहीं।


0

प्रत्येक कमेटी अपने अभिभावक (माता-पिता, मर्ज (मानक) कमिट) के मामले में एक पॉइंटर को स्टोर करती है।

इसलिए, माता-पिता की ओर से एक बच्चे को इंगित करने का कोई तरीका नहीं है (यदि एक है)।


कमिटर्स अपने बच्चों को पॉइंटर्स स्टोर नहीं कर सकते, क्योंकि अतिरिक्त बच्चे कमिट करते हैं (ब्रांचिंग पॉइंट्स) बाद के पॉइंट पर जोड़े जा सकते हैं।
जकुब नारबस्की

@ जैकब मैं वास्तव में अनुसरण नहीं करता। उन्हें बाद में नहीं जोड़ा जा सकता है?
Schwern

1
जैकब: बिल्कुल वही, जो मैंने कहा था। 'प्रत्येक प्रतिबद्ध केवल अपने माता-पिता को संकेत देता है।'
लक्ष्मण प्रसाद

@ शार्र्न: जीट में कमिटमेंट अपरिवर्तनीय है (जिसमें जवाबदेही का अच्छा परिणाम है), इसलिए बच्चों को संकेत दिया जाता है कि "बाद में जोड़ा जाए"। कारणों में से एक यह है कि प्रतिबद्ध पहचानकर्ता (उदाहरण के लिए "मूल" लिंक में प्रयुक्त) कॉमिट की सामग्री पर निर्भर करता है; यह केंद्रीय प्रणाली के बिना वितरित प्रणाली में एकमात्र समाधान है। इसके अलावा "कमिट्स" के बच्चे आपके पास मौजूद शाखाओं पर निर्भर करते हैं, और यह बदले में रिपॉजिटरी से रिपॉजिटरी (और प्रत्येक रिपॉजिटरी में एक ही हैं) से भिन्न हो सकते हैं।
जकुब नारबस्की

4
@ कमिंगगुरु मैंने नीचे मतदान किया। यह सच हो सकता है, लेकिन यह मेरे सवाल का जवाब नहीं देता है। सवाल यह है कि "मैं git में अगला कमिटमेंट कैसे ढूँढूँ?" यह "git कमिट अपने बच्चों के लिए पॉइंटर स्टोर नहीं करता है?"
Schwern

0

यह पोस्ट ( http://www.jayway.com/2015/03/30/use-git-commits-to-drive-a-live-coding-session/#comment-282667 ) यदि ऐसा कर रहा है तो एक साफ-सुथरा रास्ता दिखाता है आप अपनी प्रतिबद्ध स्टैक के अंत में एक अच्छी तरह से परिभाषित टैग बना सकते हैं। अनिवार्य रूप से git config --global alias.next '!git checkout `git rev-list HEAD..demo-end | tail -1`' जहां "डेमो-एंड" अंतिम टैग है।


0

मौजूदा उत्तर मान लेते हैं कि आपके पास एक शाखा है जिसमें आप जिस कमिटमेंट की तलाश कर रहे हैं।

मेरे मामले में, जिस प्रतिबद्धता की मुझे तलाश थी, वह उस समय से नहीं थी git rev-list --allजब तक कि कोई भी शाखा इसमें शामिल नहीं थी ।

मैं gitk --reflogमैन्युअल रूप से देख रहा हूं ।

यदि आप अपनी प्रतिज्ञा में भी अपनी प्रतिबद्धता नहीं पा रहे हैं, तो या तो प्रयास करें:

  • git fsck --full झूलने (यानी किसी भी शाखा में नहीं) को सूचीबद्ध करने के लिए, या
  • git fsck --lost-found अन्य उत्तरों में तकनीकों को लागू करने के लिए झूलने की ओर इशारा करते हुए रेफरी बनाने के लिए।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.