पुश पुश एरर '[रिमोट रिजेक्टेड] मास्टर -> मास्टर (ब्रांच की वर्तमान में जाँच हो चुकी है)'

961

कल, मैंने एक प्रश्न पोस्ट किया कि कैसे अपनी एक मशीन से दूसरे में Git रिपॉजिटरी को क्लोन किया जाए , मैं दूसरी मशीन से 'git क्लोन' कैसे कर सकता हूं? ।

अब मैं अपने स्रोत (192.168.1.2) से अपने गंतव्य (192.168.1.1) तक एक गिट रिपॉजिटरी को सफलतापूर्वक क्लोन करने में सक्षम हूं।

लेकिन जब मैंने एक फ़ाइल, एक git commit -a -m "test"और एक के लिए एक संपादन किया git push, तो मुझे अपने गंतव्य पर यह त्रुटि मिलती है (192.168.1.1):

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

मैं गिट के दो अलग-अलग संस्करणों (रिमोट पर 1.7 और स्थानीय मशीन पर 1.5) का उपयोग कर रहा हूं। क्या यह एक संभावित कारण है?

git git-push

— hap497
स्रोत

5

क्या कोई भी पुराने-टाइमर स्वीकार किए गए उत्तर को stackoverflow.com/a/9283833/397872 में बदल सकते हैं और थ्रेड को संग्रह या कुछ और करने के लिए स्थानांतरित कर सकते हैं? या स्वामित्व बदलें या जो भी हो

— ऋष्टि

9

वास्तव में अब आपके पास Git 2.3.0 (फरवरी 2015) और git config receive.denyCurrentBranch=updateInstead: stackoverflow.com/a/28262104/6309

— VonC

यह उस पुस्तक की नई कड़ी है जिसका @stigi ने उल्लेख किया है: git-scm.com/book/en/v1/Git-on-the-Server

— अब्देलिलाह एल आइसाऊई

दूरस्थ रिपॉजिटरी में परिवर्तनों को धकेलने पर यह Git चेतावनी संदेश क्या

— ट्रेवर बोयड स्मिथ

लेकिन मुझे समझ में नहीं आया कि यह क्यों और कैसे काम करता है? यह काम कर रहा है, हाँ, लेकिन यह सब है।

— तिलक मैडी

1149

आप बस अपने रिमोट रिपॉजिटरी को नंगे रिपॉजिटरी में बदल सकते हैं (नंगे रिपॉजिटरी में कोई वर्किंग कॉपी नहीं है - फ़ोल्डर में केवल वास्तविक रिपॉजिटरी डेटा है)।

अपने दूरस्थ रिपॉजिटरी फ़ोल्डर में निम्न कमांड निष्पादित करें:

git config --bool core.bare true

फिर .gitउस फोल्डर को छोड़कर सभी फाइलों को डिलीट कर दें । और फिर आप git pushकिसी भी त्रुटि के बिना दूरस्थ रिपॉजिटरी में प्रदर्शन करने में सक्षम होंगे ।

— जॉन
स्रोत

4

धन्यवाद। मुझे भी इसकी जरूरत थी। मैं गिट कम्युनिटी बुक से सबमॉड्यूल्स ट्यूटोरियल का अनुसरण कर रहा था और इस सड़क पर मारा।

— शिकी

6

मुझे यकीन नहीं था कि क्या आप सर्वर, या क्लाइंट पर फ़ाइलों को हटाने के लिए थे ... इसलिए मैंने कुछ भी नहीं हटाया, और समस्या बस करने के बाद दूर हो जाती है git config --bool core.bare true। क्या कोई विशेष कारण है कि कुछ फ़ाइलों को हटाने की आवश्यकता है? यदि हां, तो क्या आप हटाने के बारे में अधिक सटीक हो सकते हैं?

— ब्रायन वंडेनबर्ग

24

यह सबसे अच्छा संभव जवाब है और किसी और ने इसे छेद में नहीं दिया है। मुझे लगता है कि हम सभी ने एक ही त्रुटि संदेश देखा और हम सभी इसे पढ़कर बहुत खुश हुए।

— सेबेस्टियन ग्रिग्नोली

40

हालाँकि इसे बहुत सारे वोट मिले, लेकिन मुझे नहीं लगता कि यह उस विशिष्ट प्रश्न का वास्तव में पर्याप्त उत्तर है। उपयोगकर्ता को निर्देश देना कि नंगे रेपो को साफ-सुथरा बनाने का तरीका कितना बुरा होगा, लेकिन क्या होगा अगर फाइलों को चेक आउट रहने की आवश्यकता है, उदाहरण के लिए जब उपयोगकर्ता दो कंप्यूटरों के साथ काम कर रहा है?

— कहीं नहीं आदमी

9

स्रोत रेपो को नंगे में बदलना ओवरकिल है। आपको केवल स्रोत रेपो में एक नई शाखा को पुश करने की आवश्यकता है, जैसा कि @Robert बताते हैं: stackoverflow.com/a/2933656/402949 ।

— डैन सोलोवे

707

जब मैंने Git सीखना शुरू किया तो मुझे बस वही त्रुटि थी । अन्य जवाबों में से कुछ स्पष्ट रूप से किसी नए व्यक्ति के लिए नहीं हैं!

(मैं विचार प्राप्त करने के लिए गैर तकनीकी शब्दों का उपयोग करने जा रहा हूं।) वैसे भी, क्या हो रहा है कि आपके पास दो रिपॉजिटरी हैं, एक वह मूल है जिसे आपने पहली बार बनाया था, और दूसरा वह जो आपने अभी बनाया था।

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

आशा है कि ये आपकी मदद करेगा।

— रॉबर्ट गोल्ड
स्रोत

76

+1 अधिक उपयोगी है, धन्यवाद रॉबर्ट। मुझे अपने मामले में नंगे रेपो में बदलने का कोई मतलब नहीं था। बस उस शाखा को 'निष्क्रिय' करना होगा जिसे आप पुश करने का प्रयास कर रहे हैं। समझ में आता है।

— एरिक मुएसर

32

@ FMaz008: बस एक डमी ब्रांच बनाएं (git checkout -b dummy)

— Dror कोहेन

14

आदमी यह सबसे ज्यादा वोट किए गए जवाब से बेहतर है :) धन्यवाद। हालाँकि अन्य उत्तर भी अच्छी बात करता है :)

— इवान इवानिक

102

बस इस स्पष्ट करने के लिए, रेपो में जो पुश का लक्ष्य है git checkout -b tmp:। फिर स्रोत रेपो में git push:। फिर वापस लक्ष्य (वैकल्पिक) में:git checkout master; git branch -d tmp

— हरि करम सिंह

18

हरि की टिप्पणी सबसे सरल नुस्खा है। मेरा सिर्फ इतना कहना है कि जबकि gn कई मायनों में महान हो सकता है, svn या शायद किसी अन्य rv से आ रहा है, यह पूरी बात आश्चर्यजनक रूप से गैर-सहज है।

— बिना सोचे-

128

त्रुटि संदेश बताता है कि क्या हुआ है। Git के अधिक आधुनिक संस्करणों ने एक शाखा को एक धक्का के माध्यम से अद्यतन करने से इंकार कर दिया अगर उस शाखा की जाँच की जाती है।

दो गैर-नंगे भंडार के बीच काम करने का सबसे आसान तरीका या तो है

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

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

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

— सीबी बेली
स्रोत

1

धन्यवाद। तो मैं अपनी समस्या को कैसे ठीक कर सकता हूं? मेरे 192 बॉक्स में, मैंने '$ cd (प्रोजेक्ट-डायरेक्टरी) $ git init $ (कुछ फाइलें जोड़ें)' git add 'किया। और फिर मेरे 191 बॉक्स में, मैंने 'git क्लोन' किया और कुछ फाइलों को संपादित किया और 'git push' करने की कोशिश की।

— hap497

16

खैर, मैंने अपने उत्तर में संभावनाओं का वर्णन किया। या तो आप 192 बॉक्स में जा सकते हैं और 191 बॉक्स से प्राप्त कर सकते हैं (आप 191 बॉक्स को नामित रिमोट के रूप में जोड़ना चाह सकते हैं - देखें git remote add box191 <191url>), या आप 191 बॉक्स से वैकल्पिक रूप से नामित शाखा (जैसे git push origin master:refs/heads/upload) में धक्का दे सकते हैं , फिर 192 बॉक्स और मर्ज करने के लिए (जैसे git merge upload)।

— सीबी बेली

3

वास्तव में अब आपके पास Git 2.3.0 (फरवरी 2015) और git config receive.denyCurrentBranch=updateInstead: stackoverflow.com/a/28262104/6309 : के साथ एक गैर-नंगे रेपो पर धकेलने का एक सुरक्षित तरीका है : आपको अब विकल्प 2 की आवश्यकता नहीं है।

— वॉन

122

सारांश

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

चूंकि नंगे रिपोजिटरी की कभी कोई शाखा नहीं है, इसलिए आप हमेशा नंगे रिपॉजिटरी की किसी भी शाखा में जा सकते हैं।

आपकी आवश्यकताओं के आधार पर, कई समाधान हैं।

समाधान 1: एक नंगे repostiory का उपयोग करें

जैसा कि सुझाव दिया गया है, यदि एक मशीन पर, आपको कार्यशील निर्देशिका की आवश्यकता नहीं है, तो आप एक नंगे भंडार में जा सकते हैं। भंडार के साथ खिलवाड़ से बचने के लिए, आप इसे क्लोन कर सकते हैं:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

अब आप पहले की तरह सभी को एक ही पते पर धकेल सकते हैं।

समाधान 2: एक गैर-चेक-आउट शाखा के लिए धक्का

लेकिन अगर आपको अपने रिमोट पर कोड की जांच करने की आवश्यकता है <remote>, तो आप पुश करने के लिए एक विशेष शाखा का उपयोग कर सकते हैं। मान लीजिए कि आपके स्थानीय भंडार में आपने अपना रिमोट बुलाया है originऔर आप शाखा मास्टर हैं। तब आप कर सकते थे

machine2$ git push origin master:master+machine2

जब आप originदूरस्थ रेपो में हों, तब आपको इसे मर्ज करने की आवश्यकता होती है :

machine1$ git merge master+machine2

समस्या की शव परीक्षा

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

इसलिए

A ← B
    ↑
[HEAD,branch1]

हो जाता है

A ← B ← C
        ↑
    [HEAD,branch1]

लेकिन अगर कोई उस शाखा में घुस सकता है, तो उपयोगकर्ता खुद को इस बात से अवगत कराएगा कि हेड मोड अलग क्या है:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

अब उपयोगकर्ता शाखा 1 में नहीं है, बिना स्पष्ट रूप से किसी अन्य शाखा की जांच करने के लिए कहा गया है। इससे भी बदतर, उपयोगकर्ता अब किसी भी शाखा के बाहर है , और कोई भी नई प्रतिबद्धता बस झूलती रहेगी :

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

हाइपोथेटिक रूप से, यदि इस बिंदु पर, उपयोगकर्ता एक और शाखा की जांच करता है, तो यह झूलती हुई प्रतिबद्धता गिट के कचरा कलेक्टर के लिए उचित खेल बन जाता है ।

— यह आदमी कहीं का नहीं रहा
स्रोत

3

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

— torek

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

2

वास्तव में, मुझे कई परिस्थितियां मिलीं जब मुझे गैर-नंगे भंडार में धकेलने की जरूरत थी, और मैं समाधान 2 का उपयोग काफी करता हूं। इसके अलावा, जिस शाखा में मैं गैर-नंगे भंडार पर धावा बोलता हूं वह किसी भी तरह से अस्थायी शाखा नहीं है, यह दूरस्थ ट्रैकिंग शाखा के समान उद्देश्य को पूरा करती है।

— कहीं आदमी

मैंने अपने सर्वर में एक जीआईटी फ़ोल्डर बनाया है जो SourceTree का उपयोग करके कई उपयोगकर्ताओं द्वारा बनाए गए सभी रिपॉजिटरी की मेजबानी करेगा। मैंने masterअपने स्थानीय पीसी में रिपॉजिटरी बनाई । मैंने remotesसर्वर फ़ोल्डर में जोड़ा और अपने रिपॉजिटरी को सर्वर में धकेलने की कोशिश कर रहा था ताकि कोई अन्य उपयोगकर्ता इसे काम करने के लिए खींच / ला सके। मुझे निम्नलिखित त्रुटि मिलती है: ! [remote rejected] master -> master (branch is currently checked out)मैं इसे कैसे जांच सकता हूं?

— SearchForKnowledge

1

@SearchForKnowledge, क्या आपको लगता है कि आप बिल्कुल वही सवाल पूछ रहे हैं जिसका मैं जवाब दे रहा हूं ?!

— कहीं नहीं आदमी

65

.git/configगंतव्य सर्वर पर संपादन करके आप इस "सीमा" के आसपास पहुँच सकते हैं। यदि यह "चेक आउट" है, तो भी git रिपॉजिटरी को धकेलने की अनुमति देने के लिए निम्नलिखित जोड़ें:

[receive]
denyCurrentBranch = warn

या

[receive]
denyCurrentBranch = false

पहले शाखा को गड़बड़ाने की संभावना की चेतावनी देते हुए पुश की अनुमति देगा, जबकि दूसरा बस चुपचाप इसकी अनुमति देगा।

यह एक सर्वर पर "तैनात" कोड के लिए इस्तेमाल किया जा सकता है जो संपादन के लिए नहीं है। यह सबसे अच्छा दृष्टिकोण नहीं है, लेकिन कोड को तैनात करने के लिए एक त्वरित है।

— क्रिस
स्रोत

7

सर्वर पर "परिनियोजित" कोड का उपयोग करने से काम नहीं चलेगा। यहां तक कि अगर आप चेतावनी को निष्क्रिय कर देते हैं, तो आप चेक आउट शाखा को धक्का दे सकते हैं, काम की प्रतिलिपि एक पुश पर अद्यतन नहीं है।

— तीरंदाज़ी

10

मैं cd .. && git reset --hardपोस्ट-हुक प्राप्त करने के लिए उपर्युक्त विधि का उपयोग कर रहा हूं । Hackish, लेकिन काम करता है।

— झोलस्टर

9

बाद का कमांड लाइन संस्करण होगाgit config receive.denyCurrentBranch warn

— आंद्रे होल्ज़नर

4

यह स्वीकृत उत्तर होना चाहिए। हम में से कुछ जानते हैं कि हम क्या कर रहे हैं और Git शुरुआती नहीं हैं। यह उन लोगों के लिए जवाब है।

— Qix - मोनासा

2

हा, लेकिन सवाल उन लोगों से नहीं पूछा गया था ।

— कहीं नहीं आदमी

46

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

सर्वर रिपॉजिटरी पर इसका उपयोग करें, और यह कार्यशील पेड़ को भी अद्यतन करता है यदि कोई अनियोजित ओवरराइट नहीं होगा।

यह में जोड़ा गया Git 2.3 के रूप में VonC ने उल्लेख टिप्पणी में।

मैंने Git 2.3 को संकलित किया है और इसे आजमाया है। नमूना उपयोग:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

आउटपुट:

a
b

हाँ, bधक्का दिया गया!

— सिरो सेंटिल्ली 冠状病毒冠状冠状冠状冠状
स्रोत

@VonC धन्यवाद! यह काम पर कम से कम उदाहरणों के साथ मेरा जुनून है :-)

— Ciro Santilli 病毒

क्या यह परिवर्तन करने में कोई समस्या है जो सर्वर के साथ अद्यतित नहीं है?

— एकोजी

@akozi मुझे यकीन नहीं है कि आपका क्या मतलब है, यदि आप खींचने से पहले स्थानीय रूप से प्रतिबद्ध हैं, तो यह बिल्कुल एक पारंपरिक --bareक्लोन के रूप में व्यवहार करेगा जो मुझे लगता है: --forceधक्का देने के लिए आवश्यक है, और यह आपको रिमोट पर "खो" देता है।

— Ciro Santilli 冠状病毒 iro i 法轮功 '24

1

@CiroSantilli 新疆改造 ill 事件法轮功 ries अब कोई चिंता नहीं है। मैंने विकल्पों के अर्थ को देखा। मुझे लगा कि updateInstead बल का पर्याय था।

— एकोजी

updateInstead अब get.denyCurrentBranch के लिए वैध मान नहीं है

— Xalorous

41

मुझे रिमोट बॉक्स पर अभी भी उपयोग करने योग्य भंडार होने का विचार पसंद है, लेकिन एक डमी शाखा के बजाय, मुझे उपयोग करना पसंद है:

git checkout --detach

यह Git की एक बहुत नई विशेषता प्रतीत होती है - मैं git संस्करण 1.7.7.4 का उपयोग कर रहा हूं।

— stackdump
स्रोत

8

और फिर अपने परिवर्तनों को आगे बढ़ाने के बाद, आप उपयोग कर सकते हैं: git checkout masterमास्टर शाखा में वापस जाने के लिए। यह तभी है जब आपके परिवर्तन लागू किए जा रहे हैं।

— MAZDAK

30

मेरी भी यही समस्या थी। मेरे लिए, मैं अपने सर्वर पर कोड ले जाने के लिए Git पुश का उपयोग करता हूं। मैं सर्वर साइड पर कोड को कभी नहीं बदलता, इसलिए यह सुरक्षित है।

रिपॉजिटरी में, आप टाइप करने के लिए जोर दे रहे हैं:

git config receive.denyCurrentBranch ignore

यह आपको काम की प्रतिलिपि बनाते समय रिपॉजिटरी को बदलने की अनुमति देगा।

Git पुश चलाने के बाद, दूरस्थ मशीन पर जाएँ और इसे टाइप करें:

git checkout -f

यह आपके द्वारा पुश किए गए परिवर्तनों को दूरस्थ मशीन की कार्यशील प्रति में प्रतिबिंबित करेगा।

कृपया ध्यान दें, यह हमेशा सुरक्षित नहीं होता है यदि आप उस कार्य प्रति में परिवर्तन करते हैं जिसे आप धक्का दे रहे हैं।

— Orbital_sFear
स्रोत

धन्यवाद एक लॉग, मैं तुम्हें सुझाव विलय denyCurrentBranchऔर डाल git checkout -fअंदर hooksकी तरह @ जैक Senechal तैनात फ़ोल्डर यहाँ

— Éderson टी Szlachta

क्या रिमोट रिपॉजिटरी पर फाइल को बिना जाने और इस कमांड को करने का कोई तरीका है? स्थानीय से एक आदेश द्वारा नामांकित?

— रॉय

24

आप अपने सर्वर रिपॉजिटरी को फिर से बना सकते हैं और अपने स्थानीय शाखा मास्टर से सर्वर मास्टर तक धक्का दे सकते हैं।

अपने दूरस्थ सर्वर पर:

mkdir myrepo.git
cd myrepo.git
git init --bare

ठीक है, अपनी स्थानीय शाखा से:

git push origin master:master

— नव
स्रोत

3

धन्यवाद यह मेरे लिए समाधान था क्योंकि मैंने रिमोट सर्वर पर '--bare' छोड़ा था। ऐसा लगता है कि इस सवाल का जवाब इस बात पर निर्भर करता है कि आप रिमोट सर्वर रेपो का इस्तेमाल वर्किंग डायरेक्टरी के रूप में कर रहे हैं या नहीं और बाद के केस के लिए यह सही जवाब है।

— Cas

2

मुझे समझ में नहीं आता: SI ने एक नंगे रेपो को बनाने और क्लोन करने की कोशिश की, लेकिन क्लोन ने कुछ भी नहीं डाउनलोड किया और कुछ भी अपलोड नहीं किया, इसलिए यह काम नहीं कर रहा है ... :-) मैंने नंगे रेपो के बारे में ट्यूटोरियल पढ़ा, लेकिन उन्होंने कहा कि नंगे रेपो कोई फ़ाइल नहीं है ... यह निश्चित रूप से वह नहीं है

— जिसकी

22

आपने शायद इसका कारण क्या किया है:

इस तरह की बात तब होती है जब आप एक छोटे से कार्यक्रम में धमाका करने जाते हैं। आप उस चीज़ को बदलने वाले हैं जो पहले से ही काम कर रही थी, इसलिए आपने अपने स्तर -3 को हमेशा के लिए खराब कर दिया है:

machine1:~/proj1> git init

और आप जोड़ना / प्रतिबद्ध करना शुरू करते हैं। लेकिन फिर , परियोजना अधिक शामिल होने लगती है और आप उस पर दूसरे कंप्यूटर (जैसे आपके घर पीसी या लैपटॉप) से काम करना चाहते हैं, इसलिए ऐसा कुछ करें

machine2:~> git clone ssh://machine1/~/proj1

और यह क्लोन और सब कुछ अच्छा लग रहा है, और इसलिए आप मशीन 2 से अपने कोड पर काम करते हैं।

तब ... आप मशीन 2 से अपने कमिट्स को पुश करने की कोशिश करते हैं, और आपको शीर्षक में चेतावनी संदेश मिलता है।

इस संदेश का कारण यह है क्योंकि आपके द्वारा खींचा गया git repo थोड़े मशीन 1 पर उस फ़ोल्डर के लिए उपयोग किए जाने का इरादा था। आप इसे ठीक से क्लोन कर सकते हैं, लेकिन पुश करने से समस्याएं हो सकती हैं। दो अलग-अलग स्थानों में कोड को प्रबंधित करने का "उचित" तरीका "नंगे" रेपो के साथ है, जैसे सुझाव दिया गया है। एक नंगे रेपो को किसी भी कार्य के लिए डिज़ाइन नहीं किया गया है, इसका मतलब कई स्रोतों से आवागमन को समन्वित करना है। यही कारण है कि टॉप-रेटेड उत्तर आपके बाद .गित फ़ोल्डर के अलावा सभी फ़ाइलों / फ़ोल्डरों को हटाने का सुझाव देता है git config --bool core.bare true।

टॉप-रेटेड उत्तर को स्पष्ट करना: उस उत्तर के लिए कई टिप्पणियां कुछ इस तरह कहती हैं, "मैंने मशीन 1 से नॉन-टोजिट फाइल को डिलीट नहीं किया था और मैं अभी भी मशीन 2 से कमिट कर पा रहा था"। ये सही है। हालाँकि, वे अन्य फाइलें अभी पूरी तरह से git repo से "तलाकशुदा" हैं। git statusवहाँ जाने की कोशिश करें और आपको "घातक: यह ऑपरेशन एक काम के पेड़ में चलना चाहिए" जैसे कुछ देखना चाहिए। इसलिए, फ़ाइलों को हटाने का सुझाव ऐसा नहीं है कि मशीन 2 से कमिट काम करेगा ; ऐसा नहीं है कि आप भ्रमित न हों और यह सोचें कि गिट अभी भी उन फाइलों को ट्रैक कर रहा है। लेकिन, यदि आप अभी भी मशीन 1 पर फाइलों पर काम करना चाहते हैं, तो फाइलों को हटाना एक समस्या है, है न?

तो, आपको वास्तव में क्या करना चाहिए?

इस बात पर निर्भर करता है कि आप मशीन 1 और मशीन 2 पर अभी भी कितना काम करते हैं ...

यदि आप मशीन 1 से विकास कर रहे हैं और आपने अपने सभी विकास को मशीन 2 में स्थानांतरित कर दिया है ... बस वही करें जो टॉप-रेटेड उत्तर का सुझाव देता है: git config --bool core.bare trueऔर फिर, वैकल्पिक रूप से, उस फ़ोल्डर से .it के अलावा सभी फ़ाइलों / फ़ोल्डरों को हटा दें, क्योंकि वे। 'अनियंत्रित और भ्रम पैदा होने की संभावना है।

यदि मशीन 2 पर आपका काम सिर्फ एक बार की बात थी, और आपको वहां विकास जारी रखने की आवश्यकता नहीं है ... तो नंगे रेपो बनाने से परेशान न हों; बस ftp / rsync / scp / etc। मशीन * 2 * पर मशीन के ऊपर से आपकी फाइलें * 1 *, मशीन से कमिट / पुश * 1 *, और फिर मशीन * 2 * से फाइल को हटा दें। दूसरों ने एक शाखा बनाने का सुझाव दिया है, लेकिन मुझे लगता है कि यह थोड़ा गड़बड़ है अगर आप बस कुछ विकास को मर्ज करना चाहते हैं जो आपने एक मशीन से एक बार के आधार पर किया था।

यदि आपको मशीन 1 और मशीन 2 दोनों पर विकास जारी रखने की आवश्यकता है ... तो आपको चीजों को ठीक से स्थापित करने की आवश्यकता है। आपको अपने रेपो को नंगे में बदलने की जरूरत है, फिर आपको मशीन 1 पर उस का एक क्लोन बनाने की जरूरत है ताकि आप इसमें काम कर सकें । संभवतः ऐसा करने का सबसे तेज़ तरीका है।

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

बहुत महत्वपूर्ण: क्योंकि आपने प्रोजो के स्थान को प्रोज 1 से प्रोज1.गित में स्थानांतरित कर दिया है, आपको इसे मशीन 2 पर .git / config फाइल में अपडेट करना होगा । उसके बाद, आप मशीन 2 से अपने बदलाव कर सकते हैं। अंत में, मैं अपने काम के पेड़ों (यानी 'proj1.git' को 'proj1' के रूप में एक ही मूल फ़ोल्डर में नहीं डालता) से दूर, अपने नंगे भंडार को एक केंद्रीय स्थान पर रखने की कोशिश करता हूं। मैं आपको वैसे ही करने की सलाह देता हूं, लेकिन मैं ऊपर दिए गए चरणों को यथासंभव सरल रखना चाहता था।

— Jemenake
स्रोत

बहुत विस्तृत और सहायक। मेरा मामला अंतिम था, और आपके निर्देशों ने एक आकर्षण की तरह काम किया।

— 16

मैं केस 3 में हूं और मैंने कुछ अलग किया है: एमके गिट-सर्वर; mv .it git-server / proj। मैं एक नंगे मास्टर कॉपी रखूंगा जो जीएच या अन्य HTTP सर्वर पर सामान्य रूप से होगा और मैं दोनों मशीनों पर पुश / पुल का उपयोग करता रहूंगा।

— जक्कम

18

कुछ सेटअप चरणों के साथ आप आसानी से अपनी वेबसाइट में बदलाव कर सकते हैं जैसे वन-लाइनर का उपयोग करके

git push production

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

पहले आपको अपने सर्वर पर अपने वेबरूट के बाहर एक नंगे भंडार स्थापित करने की आवश्यकता है।

mkdir mywebsite.git
cd mywebsite.git
git init --bare

फिर फ़ाइल बनाएँ hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

और फ़ाइल को निष्पादन योग्य बनाएं:

chmod +x hooks/post-receive

अपने स्थानीय मशीन पर,

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

सब तैयार! अब भविष्य में आप git push productionअपने परिवर्तनों को लागू करने के लिए उपयोग कर सकते हैं !

इस समाधान का श्रेय http://sebduggan.com/blog/deploy-your-website-changes-use-git/ पर जाता है । क्या हो रहा है, इसके बारे में अधिक विस्तृत विवरण के लिए देखें।

— जैक सींचल
स्रोत

आपके सुझाव मुझे एक बहुत मदद की है, लेकिन मैं का उपयोग नहीं किया bareहै, मैं पालन इस के साथ और मर्ज hooks(है कि आप का सुझाव दिया) और पूरी तरह से काम किया।

— Éderson टी Szlachta

11

आपको केवल एक नंगे भंडार पर धकेलना चाहिए। एक नंगे रिपॉजिटरी एक रिपॉजिटरी है जिसकी कोई शाखाएं नहीं हैं। यदि आप एक नंगे रिपॉजिटरी निर्देशिका में सीडी करने के लिए थे, तो आप केवल एक .गित निर्देशिका की सामग्री देखेंगे।

— RibaldEddie
स्रोत

9

गैर-नंगे भंडार में गैर-चेक आउट शाखा को धकेलने में कुछ भी गलत नहीं है। यह काम करने का बिलकुल वैध तरीका है।

— सीबी बेली

काफी उचित, यह काम करेगा। लेकिन यह वह नहीं है जो उपयोगकर्ता कर रहा है।

— रिबेल्डैडी

13

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

— सीबी बेली

10

आपके पास 3 विकल्प हैं

खींचो और फिर से धक्का दो:
```
git pull; git push
```
विभिन्न शाखा में धकेलें:
```
git push origin master:foo
```
और इसे रिमोट पर मर्ज करें (या तो gitया पुल-रिक्वेस्ट द्वारा )
```
git merge foo
```
इसे लागू करें (अनुशंसित नहीं जब तक कि आप जानबूझकर नहीं बदल जाते हैं rebase)
```
git push origin master -f
```
यदि फिर भी मना किया जाता है, तो दूरस्थ रिपॉजिटरी denyCurrentBranch पर अक्षम करें :
```
git config receive.denyCurrentBranch ignore
```

— kenorb
स्रोत

विकल्प 2 मेरे लिए काम करते हैं। रिमोट गिट इनिट लोकल गिट पुश ओरिजिन मास्टर: ब्रांच रिमोट गिट मर्ज हो गया

— जैकी चोंग

7

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

— sebthemonster
स्रोत

7

.git/configगंतव्य प्रोजेक्ट में अपनी जाँच करें :

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

यदि core. bareयह गलत है, तो आप इसे सही पर सेट कर सकते हैं:

$ git config core.bare true

और फिर रिमोट के लिए अपने स्थानीय धक्का में:

git push remote_repo   // suppose the destination repo is remote_repo

यह सफल होगा, रिमोट_रेपो में आप गिट संस्करण की जांच कर सकते हैं।

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

और अब आप अपने "कार्यक्षेत्र" में git का उपयोग नहीं कर सकते हैं:

$ git status
fatal: This operation must be run in a work tree

आपको bare.bareझूठे पर वापस सेट करना चाहिए ।

$ git config core.bare false

— हवाई जहाज
स्रोत

5

मुझे अपने एंड्रॉइड फोन और लैपटॉप पर रिपॉजिटरी को सिंक्रनाइज़ करने के लिए गिट का उपयोग करने में एक ही समस्या थी। मेरे लिए समाधान एक धक्का के बजाय एक पुल करना था, जैसा कि @CharlesBailey ने सुझाव दिया था।

git push origin master एंड्रॉइड रिपॉजिटरी पर मेरे लिए उसी त्रुटि संदेशों के साथ विफल रहता है जो @ hap497 को रिपॉजिटरी + वर्किंग-कॉपी के नॉनबेयर चेकआउट के लिए एक धक्का के कारण मिला।

git pull droid masterलैपटॉप रिपॉजिटरी और वर्क-कॉपी मेरे लिए काम करता है। बेशक, आपको पहले की तरह कुछ चलाने की आवश्यकता है git remote add droid /media/KINGSTON4GB/notes_repo/।

— हॉब्स
स्रोत

4

Git के पुराने संस्करणों ने गैर-नंगे भंडार की वर्तमान में जाँच की गई शाखा को धक्का देने की अनुमति दी।

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

यदि पहला रिपॉजिटरी केवल एक सर्वर के रूप में कार्य कर रहा है, तो इसे एक नंगे रिपॉजिटरी में परिवर्तित करें क्योंकि अन्य उत्तर सुझाते हैं और इसके साथ किया जाता है।

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

Repo1 - सर्वर के रूप में कार्य करेगा और विकास के लिए भी उपयोग किया जाएगा

रेपो 2 - केवल विकास के लिए होगा

निम्नानुसार सेटअप रेपो 1

काम साझा करने के लिए एक शाखा बनाएँ।

git branch shared_branch

सुरक्षित होने के लिए, आपको एक $ (REPO) .git / हुक / अपडेट भी बनाना चाहिए जो साझा_ब्रांच के अलावा किसी भी अन्य परिवर्तन को अस्वीकार करता है, क्योंकि आप नहीं चाहते कि लोग आपकी निजी शाखाओं के साथ मिलें।

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

अब repo1 में एक स्थानीय शाखा बनाएं जहां आप अपना वास्तविक काम करेंगे।

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

( काम git config --global push.default upstreamकरने के लिए ऑर्डर करने की आवश्यकता हो सकती है git push)

अब आप के साथ repo2 बना सकते हैं

git clone path/to/repo1 repo2 
git checkout shared_branch

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

— एंड्रयू सी
स्रोत

3

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

उदाहरण के लिए, किसी दूरस्थ सर्वर पर:

git branch dev
git checkout dev

स्थानीय सेटअप पर:

git push

दूरस्थ सर्वर पर:

git merge dev

— श्री कोडर
स्रोत

2

यहां एक परीक्षण है कि आप यह देख सकते हैं कि bareसर्वर सामान कैसे काम करता है:

कल्पना कीजिए कि आपके पास एक कार्य केंद्र और उस पर होस्ट की गई लाइव साइट वाला एक सर्वर है, और आप इस साइट को समय-समय पर अपडेट करना चाहते हैं (यह एक स्थिति पर भी लागू होता है जहां दो डेवलपर्स अपने काम को आगे और पीछे एक नंगे बिचौलिए के माध्यम से भेज रहे हैं)।

प्रारंभ

अपने स्थानीय कंप्यूटर और cdउस पर कुछ निर्देशिका बनाएं , फिर इन आदेशों को निष्पादित करें:

# initialization
git init --bare server/.git
git clone server content
git clone server local

सबसे पहले आप एक नंगे serverनिर्देशिका बनाते हैं (अंत में .गित देखें)। यह निर्देशिका केवल आपकी रिपॉजिटरी फ़ाइलों के लिए एक कंटेनर के रूप में काम करेगी।
फिर अपने सर्वर रिपॉजिटरी को एक नई बनाई गई contentनिर्देशिका में क्लोन करें । यह आपकी लाइव / प्रोडक्शन डायरेक्टरी है जिसे आपके सर्वर सॉफ्टवेयर द्वारा परोसा जाएगा।
पहली दो निर्देशिकाएं आपके सर्वर पर रहती हैं, तीसरी आपके कार्य केंद्र पर एक स्थानीय निर्देशिका है।

कार्यप्रवाह

अब यहाँ मूल वर्कफ़्लो है:

localनिर्देशिका दर्ज करें , कुछ फाइलें बनाएं और उन्हें प्रतिबद्ध करें। अंत में उन्हें सर्वर पर धकेलें:
```
# create crazy stuff
git commit -av
git push origin master
```
अब contentनिर्देशिका दर्ज करें और सर्वर की सामग्री को अपडेट करें:
```
git pull
```
1-2 दोहराएं। यहां contentएक और डेवलपर हो सकता है जो सर्वर को भी धक्का localदे सकता है , और जैसा कि आप उससे खींच सकते हैं।

— simo
स्रोत

2

रिमोट अपस्ट्रीम शाखा में इसे पुश करने के लिए उपयोग करने से मेरे लिए यह समस्या हल हो गई:

git push <remote> master:origin/master

रिमोट की अपस्ट्रीम रेपो तक कोई पहुँच नहीं थी इसलिए यह उस रिमोट में नवीनतम बदलाव लाने का एक अच्छा तरीका था

— jontro
स्रोत

1

अधिक सामान्यतः (जैसा कि यह कमांड का शुद्ध प्रभाव है), का उपयोग करते हुए git push <remote> master:newbranch। विचार यह है कि आप एक नई शाखा को रिमोट पर धकेलते हैं, जिसे बाद में मर्ज किया जा सकता है। इस तरह से आप त्रुटि संदेश में उल्लिखित असंगति के किसी भी मुद्दे से बच जाते हैं।

— क्ले

1

मुझे git --initएक मौजूदा नंगे रिपॉजिटरी में फिर से चलना पड़ा, और इसने .gitनंगे रिपॉजिटरी ट्री के अंदर एक डायरेक्टरी बनाई - मुझे एहसास हुआ कि git statusवहां टाइप करने के बाद । मैंने उसे हटा दिया और सब कुछ फिर से ठीक हो गया :)

(ये सभी उत्तर महान हैं, लेकिन मेरे मामले में यह पूरी तरह से अलग था (जहाँ तक मैं देख सकता हूँ), जैसा कि वर्णित है।)

— जनवरी
स्रोत

1

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

वर्णित त्रुटि का सामना करते समय मेरे पास एक ग्रहण + ईजीट वेब परियोजना सेटअप था। क्या मुझे बस GitHub ऐप का उपयोग करने में मदद मिली, जो समस्या को जादुई रूप से हल करने के लिए लग रहा था। जबकि ईजीत हमेशा पुश को मना करेगा, GitHub डेस्कटॉप ऐप बस अपने कंधों को सिकोड़ लेगा और मेरे बदलावों को आगे बढ़ाएगा। हो सकता है कि यह बहु-लॉगिन-स्थिति को अधिक सुंदर ढंग से संभालता है।

— Pille
स्रोत

1

एक लेख जो मैंने पाया कि 5 मिनट में दूसरों के लिए उपयोगी हो सकता है ।

मेरे पास Git संस्करण नियंत्रण में एक Xcode प्रोजेक्ट था जिसे मैं एक DC में वर्चुअल डिस्ट्रीब्यूटेड ईथरनेट (VDE) में पुश करना चाहता था । VDE Centos 5 चलाता है ।

मैंने जितने भी लेख पढ़े उनमें से कोई भी Git के बारे में बात नहीं की। यह सब इतना आसान लग रहा था जब तक मैंने कोशिश नहीं की कि मुझे लगा कि एसवीएन पृष्ठभूमि से आना आसान होना चाहिए ।

दूरस्थ रिपॉजिटरी को नंगे काम करने के लिए यहां दिए गए सुझाव। मेरी आवश्यकताओं के लिए इससे भी बेहतर था कि Xcode प्रोजेक्ट को क्लोन किया जाए projectname.git, रिमोट सर्वर को कॉपी किया जाए; फिर जादुई तरीके से काम करता है। अगला कदम कमोड के बारे में त्रुटियों के बिना पुश करने के लिए Xcode हो रहा होगा, लेकिन अभी मैं इसे टर्मिनल से ठीक कर रहा हूं।

इसलिए:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

Xcode में आपके द्वारा किए जाने के बाद अपने Xcode प्रोजेक्ट से बदलावों को धकेलने के लिए:

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

मुझे यकीन है कि ऊपर करने का एक अधिक परिष्कृत तरीका है, लेकिन कम से कम यह काम करता है। बस इतना सब कुछ स्पष्ट है, यहां कुछ स्पष्टीकरण दिए गए हैं: /xcode-project-directoryवह निर्देशिका है जिसे आपकी एक्सकोड परियोजना में संग्रहीत किया गया है। यह संभवतः है /Users/Your_Name/Documents/Project_Name। प्रोजेक्टनेम शाब्दिक रूप से परियोजना का नाम है, लेकिन यह कुछ भी हो सकता है जिसे आप कॉल करना चाहते हैं। Git परवाह नहीं है, आप करेंगे।

SCP आप दूरस्थ सर्वर है कि अनुमति दी गई है पर एक उपयोगकर्ता खाते की आवश्यकता का उपयोग करने के लिए SSH का उपयोग कर सकते। कोई भी अपना सर्वर चला रहा होगा। यदि आप साझा होस्टिंग या पसंद का उपयोग कर रहे हैं, तो आप भाग्य से बाहर हो सकते हैं।

remotehost.comआपके दूरस्थ होस्ट का नाम है। आप आसानी से इसके आईपी पते का उपयोग कर सकते हैं। बस आगे स्पष्टता के लिए मैं SSH कुंजी के साथ दूरस्थ होस्ट पर Gitosis का उपयोग कर रहा हूं , इसलिए जब मैं धक्का देता हूं तो मुझे पासवर्ड के लिए संकेत नहीं दिया जाता है। Git Repositories, Easy (और Secure) वेव की मेजबानी करने वाला लेख आपको बताता है कि यह सब कैसे सेट किया जाए।

— Korutech ऐप समाधान
स्रोत

1

इसका सबसे अच्छा तरीका है:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

यह रिपॉजिटरी को क्लोन कर देगा, लेकिन यह किसी भी कार्यशील कॉपी को नहीं बनाएगा .../remote। यदि आप रिमोट को देखते हैं, तो आपको एक निर्देशिका बनाई जाएगी, जिसे कॉल किया जाएगा currentrepo.git, जो कि शायद आप चाहते हैं।

फिर अपने स्थानीय Git भंडार से:

git remote add remoterepo ..../remote/currentrepo.git

परिवर्तन करने के बाद, आप कर सकते हैं:

git push remoterepo master

— बिल डोनाहुए
स्रोत

1

मैं इस समस्या में हेरोकू पर एक तैनाती गिट रिपॉजिटरी के साथ भाग गया ।

मुझे नहीं पता कि हरोकू के पास अपनी तरफ से एक गैर-नंगे भंडार क्यों है, लेकिन वर्कअराउंड के रूप में मैं रिमोट रिपॉजिटरी, और पुनः लोड को रीसेट करने में सक्षम था।

आपको सहयोग के लिए अपनी एकमात्र रिपॉजिटरी के रूप में अपनी रिपॉजिटरी की हेरोकू कॉपी का उपयोग नहीं करना चाहिए, लेकिन सिर्फ मामले में, मैं स्पष्ट रूप से कहूंगा: ऐसा तब तक न करें जब तक कि आप सुनिश्चित न हों कि आपके पास अपने रिपॉजिटरी की पूरी कॉपी सुरक्षित रूप से कहीं और संग्रहीत है Heroku। रीसेट करने से रिपॉजिटरी सामग्री हट जाएगी।

दुबारा सेट करने के लिए:

यदि आप पहले से ही नहीं है, तो Heroku टूलबेल्ट (जिसमें कमांड लाइन क्लाइंट शामिल है) स्थापित करें ।
यदि आप पहले से ही नहीं है, तो heroku-repo प्लगइन स्थापित करें ।
```
heroku plugins:install https://github.com/heroku/heroku-repo.git
```
रीसेट करें, जो रिपॉजिटरी को हटाता है और एक नया, खाली बनाता है
```
heroku repo:reset
```
अपने हरोकू रिमोट को पुश करें जैसा कि आप सामान्य रूप से करेंगे; यह सब कुछ फिर से लोड करेगा।

— rakslice
स्रोत

इसे काम करने के लिए आपको हरोकू रेपो टूल को इंस्टॉल करना पड़ सकता है। क्याheroku plugins:install https://github.com/heroku/heroku-repo.git

— नूह

1

खाली (नंगे) रिपॉजिटरी बनाने के बाद, आपको दूरस्थ सर्वर पर कॉन्फिग फाइल को बदलना होगा

root@development:/home/git/repository/my-project# cat config

वहाँ आप देखेंगे

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

आप इसे नंगे को सच करने के लिए नंगे कर देंगे और मैंने logallrefupdates = true (इसके उपयोग के बारे में सुनिश्चित नहीं है!) को हटा दिया।

सेवा

[core]
repositoryformatversion = 0
filemode = true
bare = true

आप निम्नलिखित परीक्षण कर सकते हैं

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

यदि आप PUSH में असमर्थ हैं तो यह HEAD शाखा: (अज्ञात) दिखाया जाएगा। तो अगर हेड शाखा अनजानी है, तो आपको नंगे को सच में बदलना चाहिए और सफल होने के बाद आप पुन: उपयोग कर सकते हैं

git remote show origin

और तुम देखोगे

 HEAD branch: master

— विमल कृष्ण
स्रोत

0

मेरे लिए काम कर समाधान है:

रिमोट पर:

git checkout -b some_tmp_name

स्थानीय:

git push

रिमोट पर:

git checkout master
git branch -d some_tmp_name

लेकिन यह वास्तविक समाधान नहीं है यह केवल समाधान है।

— jmarceli
स्रोत

यदि आपके पास केंद्रीय भंडार नहीं है तो यह एक वैध समाधान है।

— रिक

0

बस के मामले में किसी को यह उपयोगी लगता है। मेरे लिए यह एक git सर्वर अनुमतियाँ समस्या थी। मैंने बेजिंग से प्रोजेक्ट को चेक किया और एक साधारण फ़ाइल को पुश किया और फिर मुझे "पुश रिजेक्ट: पुश टू ओरिजिन / लोकेशन रिजेक्ट कर दिया गया।"

— PbxMan
स्रोत

-1

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

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

तो, यहाँ एक उदाहरण है:

पीसी पर, ~ / कार्यक्षेत्र में

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

लैपटॉप पर, ~ / कार्यक्षेत्र में (इनिट आदि न करें)

git clone //LJZ-DELLPC/remote-repository.git/ .

// फिर विभिन्न कमिट करें, और उन्हें पुश करें:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push

फिर पीसी पर, ~ / कार्यक्षेत्र में वापस

git pull

// फिर विभिन्न कमिट करें, और उन्हें पुश करें:

git push

लैपटॉप गिट पुल पर

इत्यादि..

यहाँ एक मशीन पर एक पूर्ण ठोस उदाहरण दिया गया है, जिसे कमांड विंडो से सीधे कॉपी किया गया है, ताकि हम जान सकें कि कोई भी कदम नहीं छोड़ा गया है, कि यह वास्तव में काम करता है, आदि:

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

— लाइल जेड
स्रोत

यह क्या काम करता है, और क्यों की व्याख्या का एक उदाहरण है। आपकी टिप्पणी के अलावा यहाँ कोई गलत जानकारी नहीं है।

— लाइल जेड

1

"गिट के साथ, दो नियमित (गैर-नंगे) रिपॉजिटरी फाइलों को सीधे आगे और पीछे नहीं खींच सकते हैं" - सिवाय इसके कि वे कर सकते हैं।

— एंड्रयू सी

ठीक है, एक हमले के बजाय एक ठोस उदाहरण पोस्ट करें।

— लाइल जेड

या आप इसे Google कर सकते हैं? stackoverflow.com/questions/1764380/…

— एंड्रयू सी

आपके द्वारा थ्रेड साइट में पहली प्रतिक्रिया "... लेकिन गिट तैयार और आधिकारिक गिट विकी के अनुसार शुरू होती है, आपको केवल एक नंगे रेपो को धक्का देना चाहिए।" अगली प्रतिक्रिया में कहा गया है, "यदि आप केवल मास्टर -> मास्टर को पुश करने की कोशिश करना चाहते हैं, तो कमांड बस है: गिट पुश ओरिजिन", और यह बस काम नहीं करता है, और उस प्रभाव को एक zill पोस्टिंग हैं। अंतिम प्रतिक्रिया के साथ शुरू होता है, "मैं आपके सर्वर में एक नंगे-रिपॉजिटरी और एक स्थानीय कामकाजी (गैर-नंगे) प्रतिनिधि का सुझाव देना चाहूंगा।"

— लाइल जेड

-3

मेरा समाधान (उपयोग में)

रिमोट सर्वर पर चेकआउट "मास्टर"
"देव" शाखा पर स्थानीय रूप से काम करें
दूरस्थ देव में परिवर्तन
रिमोट में मास्टर में देव का विलय करें

बिंगो

— decibel.places
स्रोत