2008-10-26 19 views
9

मेरे पास एक स्थानीय गिट भंडार है जो मैं कुछ दिनों से विकसित कर रहा हूं: इसमें अब तक अठारह काम हैं। आज रात, मैंने एक निजी गिथब भंडार बनाया जिसे मैं इसे धक्का देने की उम्मीद कर रहा था; हालांकि, जब मैंने ऐसा किया, तो यह केवल आठ अठारह कामों को गितूब को धक्का दे रहा था। मैंने गीथूब रेपो को हटा दिया और उसी परिणाम के साथ पुनः प्रयास किया।गिथब को मौजूदा गिट भंडार को धक्का देना केवल आधे काम करता है?

यह क्यों हो रहा है पर कोई विचार? मैंने कुछ बार सफलतापूर्वक बिना इस प्रक्रिया को किया है, इसलिए मैं थोड़ी सी स्टंप हूं।

अद्यतन: इस रेपो में केवल मास्टर शाखा ही है, और हमेशा रही है। बस कुछ पोस्ट किए गए उत्तरों को संबोधित करने के लिए ...

उत्तर

17

मैं प्रश्न में भंडार पर एक नज़र लिया और यहाँ है कि क्या हो रहा था:

  • कुछ बिंदु पर, rpj git checkout [commit id] प्रदर्शन किया था। यह एक मान्यता प्राप्त शाखा के बजाय एक ढीले प्रतिबद्धता पर सिर की ओर इशारा किया। मेरा मानना ​​है कि यह "खतरनाक सिर" समस्या है जिसे सीज़रबी का जिक्र है।
  • इस समस्या को महसूस नहीं करते, वह बदलते और उन्हें करने के लिए चला गया, जो हर बार सिर उछला। हालांकि, हेड एक मान्यता प्राप्त शाखा में नहीं, बल्कि काम की एक लटकती श्रृंखला पर इशारा कर रहा था।
  • जब वह अपने परिवर्तनों को धक्का देने के लिए चला गया, तो गिट ने मास्टर के शीर्ष तक सब कुछ धक्का दिया, जो वर्तमान पेड़ के माध्यम से केवल आधा रास्ते था।
  • भ्रम शुरू हो गयी

यह चित्र इसे और अधिक स्पष्ट करना चाहिए:

    -- D -- E -- F 
       /   ^
    A -- B -- C -    | 
^  ^    HEAD 
    |   | 
remote master 

जब वह अपने परिवर्तन, केवल A के माध्यम से C धकेल दिया गया और remoteC तक पहुंच बढ़ाने के लिए कोशिश की। वह DF के माध्यम से धक्का देने के लिए काम नहीं कर सका क्योंकि उन्हें किसी ज्ञात शाखा द्वारा संदर्भित नहीं किया जाता है।

$ git branch 
* (no branch) 
master 

समाधान करता की झूलने श्रृंखला में F अप करने के लिए master स्थानांतरित करने के लिए है:

यहाँ आप क्या देखते हैं जब आप इस राज्य में हो। यहां मैंने यह कैसे किया है।

git checkout -b tmp

  • tmp शाखा अब की ओर इंगित करता है ऊपर
  • फास्ट आगे चित्र में F प्रतिबद्ध:

    • वर्तमान स्थिति के लिए एक वैध शाखा बनाएं master से tmp

      git checkout master

      git merge tmp

      • master अब इशारा कर रही है पर F प्रतिबद्ध।
    • फेंक दूर अपने अस्थायी शाखा

      git branch -d tmp

    • आप खुशी से दूरदराज के भंडार के लिए धक्का कर सकते हैं और यह आपके सभी बदलावों भेजना चाहिए।

  • +0

    यदि आप सतर्क रहना चाहते हैं तो यह दृष्टिकोण ठीक है; यदि आप * जानते हैं कि विलय तेजी से आगे बढ़ने जा रहा है, तो आप शाखा को हटा और फिर से बना सकते हैं। मेरा जवाब देखें –

    +0

    आप सही हैं- यदि यह तेज़ आगे नहीं है तो आप थोड़ा अलग पेड़ के साथ समाप्त हो जाएंगे, लेकिन आपको अभी भी एक ही अंतिम परिणाम मिलना चाहिए। हालांकि, आपका जवाब बहुत आसान है। – farktronix

    +0

    यदि आपके पास फोर्क्स –

    2

    मुझे लगता है कि पहली बात यह है कि मैं आपके स्थानीय भंडार पर git fsck चलाने के लिए यह सुनिश्चित करूँगा कि यह सब ठीक है।

    मैंने पहले कभी इस समस्या को नहीं देखा है, और मैं नहीं सोच सकता कि क्या गलत हो सकता है।

    3

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

    चेक करने का सबसे आसान तरीका gitk --all का उपयोग करना है, जो ग्राफिक रूप से सभी शाखाएं, HEAD और बहुत कुछ दिखाता है।

    1

    तो, यह पता चला है कि दोनों: .git/refs/सिर में हैश प्रतिबद्ध/मास्टर सही में था और .git/लॉग/refs/सिर/मास्टर में जानकारी अधूरी थी; उसमें मेरा मतलब है कि यह केवल गिट/रेफ/हेड/मास्टर में निर्दिष्ट प्रतिबद्ध हैश को शामिल करता है।

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

    यदि कोई सोच रहा है: .git/refs/head/master को ठीक करने के लिए, मैंने बस उस फ़ाइल की सामग्री को नवीनतम प्रतिबद्ध हैश (HEAD) के साथ बदल दिया है, और ठीक करने के लिए .git/logs/refs/head/मास्टर, मैंने बस .git/logs/HEAD की सामग्री को .git/logs/refs/head/master में कॉपी किया है। आसान peasy ... नहीं।

    +0

    आपके पास शायद मेरे उत्तर में उल्लेख किया गया है, एक "अलग सिर"। चेक करें। जीआईटी/हेड; अगर इसमें "रेफरी/हेड्स/मास्टर" (या कोई अन्य रेफरी लाइन नहीं है), तो आपके पास एक अलग सिर है, और आपकी प्रतिबद्धता केवल शाखा में ही नहीं होगी। – CesarB

    +0

    और, वैसे, यदि आपके पास एक अलग सिर है, तो आपने केवल लक्षणों को ठीक किया है, और आपके सभी नए काम केवल सिर पर ही चलेंगे। आईआईआरसी, उस स्थिति से बाहर निकलने का तरीका एक शाखा ("गिट चेकआउट मास्टर") की जांच करना है, जो उस शाखा को इंगित करने के लिए हेड सेट करेगा। – CesarB

    1

    मैं प्रतिष्ठा CesarB के पहले जवाब पर सीधे टिप्पणी करने की जरूरत नहीं है, लेकिन gitk --all इस मामले में काम नहीं करता है, क्योंकि यह केवल ज्ञात शाखाओं बाहर सूचीबद्ध करता है।

    gitk HEAD इस समस्या को दिखाता है, लेकिन यह पूरी तरह से स्पष्ट नहीं है। धूम्रपान बंदूक यह है कि master सबसे हालिया प्रतिबद्धता के बजाए प्रतिबद्ध पेड़ को दिखाता है।

    5

    Git 1.7.3 के बाद से, आप एक साधारण आदेश के साथ ऐसा कर सकते हैं:

    git checkout -B master 
    

    -b स्विच का अर्थ है "इसे बाहर की जाँच से पहले यहां शाखा बनाने" और -B कि की बिना शर्त संस्करण है, " भले ही शाखा पहले से मौजूद है - उस स्थिति में, इसे जांचने से पहले इसे यहां ले जाएं "।


    समस्या इस तरह की फिक्सिंग के लिए एक बहुत ही सरल दृष्टिकोण सिर्फ master शाखा हटा सकते हैं और इसे पुन: करने के लिए है। आखिरकार, गिट में शाखाएं केवल काम करने के लिए नाम हैं और master शाखा कुछ खास नहीं है।

    तो यह सोचते हैं कि वर्तमान के लिए प्रतिबद्ध एक आप master होना चाहते है, तो आप बस,

    git branch -D master 
    

    मौजूदा master शाखा नष्ट करने के लिए करते हैं तो

    git checkout -b master 
    
    एक को

    करना) बनाने के एक master नामक नई शाखा जो वर्तमान प्रतिबद्धता को इंगित करती है और बी) master शाखा को इंगित करने के लिए HEAD अद्यतन करें। उसके बाद, HEADmaster से जुड़ा होगा और इसलिए जब भी आप प्रतिबद्ध हों तो master आगे बढ़ेगा।

    +0

    है तो यह आपकी सहायता नहीं करता है मेरी पसंदीदा विधि में हटाना शामिल नहीं है, बस पुन: असाइनमेंट करें। 'गिट शाखा-एफ मास्टर' मौजूदा 'मास्टर' शाखा को आपके वर्तमान 'हेड' को इंगित करने के लिए मजबूर करती है, और फिर 'गिट चेकआउट मास्टर' आपको "लटकती" स्थिति से बाहर ले जाती है। – Quuxplusone

    +1

    @Quuxplusone: हालिया गिट्स के साथ, यहां तक ​​कि यह आवश्यक से भी अधिक जटिल है: बस 'चेकआउट-बी' का उपयोग करें। मैंने अपना जवाब अपडेट कर लिया है। –

    0

    मुझे यह समस्या दो बार मिली है, और आखिरकार यह पता चला कि मैं क्या कर रहा था जो इसे पैदा कर रहा था। git rebase -i के साथ एक पुरानी प्रतिबद्धता को संपादित करने की प्रक्रिया में, git commit --amend पर कॉल करने के बजाय, मैं आदत के बल से git commit -a पर कॉल कर रहा था, इसके बाद तुरंत git rebase --continue के बाद। कोई और दृश्यों के पीछे क्या हो रहा है, यह समझाने में सक्षम हो सकता है, लेकिन ऐसा लगता है कि परिणाम अलग सिर समस्या है।