मैं दूरस्थ Git रिपॉजिटरी में संशोधित संशोधन कैसे करूं?

Question

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

> git commit --amend

दुर्भाग्य से कमेट को रिपॉजिटरी में वापस नहीं लाया जा सकता है। इसे इस तरह खारिज कर दिया जाता है:

> git push origin
To //my.remote.repo.com/stuff.git/
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to '//my.remote.repo.com/stuff.git/'

मुझे क्या करना चाहिए? (मैं दूरस्थ रिपॉजिटरी तक पहुंच सकता हूं।)

Comments

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

@ एफएबी: मुझे लगता है कि यह एक एफएक्यू है। कमिट के साथ-साथ एक मैसेज भी हैश किया जाता है, इसलिए इसका जाप करने से रिविड (हैश) बदल जाता है। अगर यह स्पष्ट नहीं है: नहीं, आप नहीं कर सकते। IIRC नोटों में सूचनाओं का भंडार जमा कर सकता है (ताकि आप मौजूदा बदलावों को रद्द किए बिना उन्हें बदल सकें)। विशिष्ट

— हिट्स

आप जल्द ही (git1.8.5, Q4 2013) अधिक सावधानी से करgit push -force पाएंगे ।

— वॉन सीपीसी

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

— नेहेम

@ user58777 अगर आपका -मैन्ड केवल कमिट मैसेज को बदलने के लिए था और आपने तब से कोई अतिरिक्त स्थानीय कमिट नहीं किया है, तो आप अपनी लोकल ब्रांच को रिमोट कमेट पर रीसेट कर सकते हैं जिसे आपने कमिट मैसेज में संशोधन करने से पहले धकेला है।

— स्कॉट अहेन

Answer 1

मैंने वास्तव में एक बार --forceऔर .gitरिपोजिटरी के साथ धक्का दिया और लिनुस बिग टाइम द्वारा डांटा गया । सामान्य तौर पर यह अन्य लोगों के लिए बहुत सारी समस्याएं पैदा करेगा। एक सरल जवाब है "ऐसा मत करो"।

मैं देख रहा हूँ कि दूसरों ने वैसे भी ऐसा करने का नुस्खा दिया है, इसलिए मैं उन्हें यहाँ नहीं दोहराऊंगा। लेकिन यहां स्थिति से उबरने के लिए एक टिप दी गई है, जब आप संशोधित प्रतिबद्ध को --force (या + मास्टर) के साथ बाहर कर दिया है।

1. git reflogउस पुरानी कमिट को खोजने के लिए उपयोग करें जिसे आपने संशोधित किया है (इसे कॉल करें old, और हम आपके द्वारा संशोधित नई कमेटी को कॉल करेंगे new)।
2. जो मर्ज बनाएं oldऔर new, के वृक्ष की रिकॉर्डिंग new, की तरह git checkout new && git merge -s ours old।
3. उसको अपने गुरु के साथ मिला दें git merge master
4. परिणाम के साथ अपने स्वामी को अपडेट करें git push . HEAD:master
5. परिणाम को धक्का दें।

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

Comments

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

— 12

हमारी कंपनी में, हम लोगों द्वारा विकसित फीचर शाखाओं पर ... नियमित रूप से जोर देते हैं।

— ओंद्र kaसुका

लिनुस से डांट इसलिए थी क्योंकि आपने इतिहास को बल विकल्प से मिटा दिया था, इसलिए नहीं कि आपको ऐसा नहीं करना चाहिए। GabrielleV का समाधान ठीक काम करता है, क्योंकि यह इतिहास को नहीं बदलता है।

— user411279

कृपया, क्योंकि इस उत्तर के लेखक (गिटस्टर) अब मौजूद नहीं हैं, क्या कोई व्यक्ति आइटम नंबर 1 को स्पष्ट करने में मदद कर सकता है: पुरानी प्रतिबद्ध खोजें। यदि आपके पास बैकअप नहीं है, तो आप इसे कहां पाएंगे? संशोधन और बल धक्का इसे नष्ट नहीं होता? हो सकता है कि वह इसे किसी मित्र / सहयोगी से प्राप्त करने की बात कर रहा हो जो अभी भी पेड़ में है?

— डॉ। बेको

डॉ ब्रेको आप git reflogइसे खोजने के लिए उपयोग कर सकते हैं

— शमौन Zyx

Answer 2

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

अगर ऐसा नहीं होता, तो एक ही समय में एक ही भंडार में धकेलने वाले दो लोग यह नहीं जानते होंगे कि एक ही समय में एक नई प्रतिबद्धता आ रही थी और जिसने भी अंतिम धक्का दिया, वह पिछले ढकेलने वाले के काम को खो देगा या तो बिना उन्हें इस बात का एहसास है।

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

git push -f origin master

यहां तक ​​कि यह काम नहीं कर सकता क्योंकि जीआईटी दूरस्थ रिपॉजिटरी को कॉन्फ़िगरेशन चर का उपयोग करके दूर के अंत में गैर-फास्टवर्ड पुश से इनकार करने की अनुमति देता है receive.denynonfastforwards। यदि यह मामला है तो अस्वीकृति कारण इस तरह दिखेगा ('रिमोट अस्वीकृत' भाग पर ध्यान दें):

 ! [remote rejected] master -> master (non-fast forward)

इसके आस-पास जाने के लिए, आपको या तो दूरस्थ रिपॉजिटरी के कॉन्फ़िगरेशन को बदलने की जरूरत है या एक गंदे हैक के रूप में आप शाखा को हटा सकते हैं और इसे फिर से बना सकते हैं:

git push origin :master
git push origin master

सामान्य रूप से git pushप्रारूप का उपयोग करने के लिए अंतिम पैरामीटर <local_ref>:<remote_ref>, जहां local_refस्थानीय रिपॉजिटरी पर शाखा remote_refका नाम है और रिमोट रिपॉजिटरी पर शाखा का नाम है। यह कमांड जोड़ी दो शॉर्टहैंड का उपयोग करती है। :masternull local_ref है जिसका अर्थ है कि एक अशक्त शाखा को दूर की ओर धकेलें master, अर्थात दूरस्थ शाखा को हटा दें। एक शाखा नाम जिसका कोई :अर्थ नहीं है, स्थानीय शाखा को दिए गए नाम के साथ दूरस्थ शाखा को उसी नाम के साथ धकेलें। masterइस स्थिति के लिए कम है master:master।

Comments

यह गितुब के साथ काम नहीं किया, इसने मुझे निम्नलिखित संदेश दिया: [दूरस्थ खारिज] मास्टर (वर्तमान शाखा को हटाने पर रोक)

— वेदांग

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

— वेदांग

यह एकमात्र समाधान है जो असेंबल के साथ होस्ट किए गए मेरे रेपो के लिए काम करता है।

— जस्टिन

दूरस्थ मास्टर शाखा को हटाने से दूरस्थ रेपो में स्थान खाली हो जाएगा?

— Mr_and_Mrs_D

@Mr_and_Mrs_D: तुरंत नहीं, लेकिन एक git gcबार रिफ्लैक्स की समय सीमा समाप्त हो जाने के बाद पुरानी वस्तुओं को हटा दिया जाएगा। कोई भी जो रिपॉजिटरी को क्लोन नहीं करता है, उसे ऐसी कोई भी वस्तु मिलेगी, जो ब्रांच के अपडेट होते ही अब उपलब्ध नहीं है।

— सीबी बेली

Answer 3

त्वरित शेख़ी: तथ्य यह है कि किसी ने भी यहां सरल उत्तर पोस्ट नहीं किया है, जीएसएल सीएलआई द्वारा प्रदर्शित हताश उपयोगकर्ता-शत्रुता को प्रदर्शित करता है।

वैसे भी, ऐसा करने का "स्पष्ट" तरीका, यह मानकर कि आपने पुश को बल देने की कोशिश नहीं की है, पहले खींचना है। यह उस परिवर्तन को खींचता है जिसे आपने संशोधित किया (और अब नहीं है) ताकि आपके पास फिर से हो।

एक बार जब आप किसी भी संघर्ष को हल कर लेते हैं, तो आप फिर से धक्का दे सकते हैं।

इसलिए:

git pull

यदि आपको खींचने में त्रुटियां मिलती हैं, तो शायद आपके स्थानीय रिपॉजिटरी कॉन्फ़िगरेशन में कुछ गलत है (मेरे पास .गित / कॉन्फिगरेशन शाखा में गलत रेफरी था)।

और बाद में

git push

हो सकता है कि आपको विषय के साथ एक अतिरिक्त प्रतिबद्धता मिलेगी, जो "ट्रिवियल मर्ज" के बारे में बताएगा।

Comments

हां, मैंने इसके बारे में लिखा, देखें stackoverflow.com/questions/253055/… ;)

— Spoike

यह वास्तव में काम नहीं करता है जैसे मुझे इसकी उम्मीद थी। यह दो नए आवागमन बनाता है। एक जो पुराने की प्रतिकृति है, लेकिन संशोधित परिवर्तनों के साथ। और एक मर्ज एक खाली अंतर के साथ प्रतिबद्ध है। अभी भी पुरानी प्रतिबद्ध को अपरिवर्तित छोड़ रहा है, संभवतः संवेदनशील डेटा का खुलासा करता है जिसे मैं दूर करने की कोशिश कर रहा था। मेरा मानना है कि git push -fया git resetयहां से जाने के लिए एक ही रास्ता है।

— thnee

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

— डैन जोन्स

Answer 4

संक्षिप्त जवाब: संशोधित किए गए कमेंट्स को सार्वजनिक रेपो में न धकेलें।

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

हालाँकि, यदि आप वास्तव में, वास्तव में एक संशोधित कमिट को आगे बढ़ाना चाहते हैं, तो आप ऐसा कर सकते हैं:

$ git push origin +master:master

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

Comments

Git push -f की तुलना में यह अलग (बेहतर या बदतर) कैसे है? धन्यवाद!

— बेंटफोर्ड

@ बेंटफोर्ड: यह मूल रूप से एक ही बात है git push -f।

— mipadi

Answer 5

यहां आपके द्वारा पहले से ही किए गए परिवर्तनों को धकेलने का एक बहुत ही सरल और साफ तरीका है commit --amend:

git reset --soft HEAD^
git stash
git push -f origin master
git stash pop
git commit -a
git push origin master

जो निम्न कार्य करता है:

• पैरेंट कमिट के लिए ब्रांच हेड को रीसेट करें।
• इस आखिरी वचन को तोड़ो।
• फोर्स पुश टू रिमोट। रिमोट अब अंतिम प्रतिबद्ध नहीं है।
• अपना स्टाॅप पॉप करें।
• सफाई से काम करें।
• रिमोट से पुश करें।

"मूल" और "मास्टर" को बदलने के लिए याद रखें अगर इसे एक अलग शाखा या रिमोट पर लागू करना है।

Comments

2 टिप्पणी: - यदि आप एक दूसरे पर काम कर रहे हैं तो शाखा का नाम बदलना सुनिश्चित करें - मुझे git addबदलावों को शामिल करने के लिए अपनी प्रतिबद्धता से पहले उपयोग करना था ।

— सिल्वेनबी

विंडोज सीएमडी में, पहले कमांड को बच जाना चाहिए git reset --soft "HEAD^":। बाकी ठीक काम करता है।

— 15

"एक बहुत ही सरल और साफ तरीका .." सिट। इस प्रक्रिया में जबरन धक्का शामिल है। ऊपर दिए गए उत्तरों में सभी क्रिटिसिम्स की रोशनी में मुझे यकीन नहीं है कि क्या यह प्रक्रिया वास्तव में एक साफ है।

— Na13-c

Answer 6

मैंने अपनी स्थानीय संशोधित प्रतिबद्धताओं को त्याग कर और शीर्ष पर नए बदलाव जोड़कर इसे हल किया है:

# Rewind to commit before conflicting
git reset --soft HEAD~1

# Pull the remote version
git pull

# Add the new commit on top
git add ...
git commit
git push

Comments

यह सबसे सरल संस्करण है!

— mknaf

एक और 'परिवर्तन' कमिट जोड़ना इतिहास के पुनर्लेखन के साथ खिलवाड़ करने से बेहतर है। मैं @mknaf से सहमत हूँ

— sdkks

Answer 7

मुझे भी यही समस्या थी।

• दुर्घटनावश अंतिम प्रतिबद्ध संशोधन किया गया था जो पहले ही धकेल दिया गया था
• स्थानीय रूप से बहुत सारे बदलाव किए, कुछ पांच बार प्रतिबद्ध हुए
• धक्का देने की कोशिश की, एक त्रुटि हुई, घबरा गए, रिमोट को मर्ज कर दिया, बहुत कुछ नहीं मिला-मेरी-फाइलें, धक्का दिया, असफल रहा, आदि।

Git-newbie के रूप में, मुझे लगा कि यह पूरा FUBAR था ।

समाधान: कुछ हद तक @bara ने सुझाव दिया + एक स्थानीय बैकअप शाखा बनाई

# Rewind to commit just before the pushed-and-amended one.
# Replace <hash> with the needed hash.
# --soft means: leave all the changes there, so nothing is lost.
git reset --soft <hash>

# Create new branch, just for a backup, still having all changes in it.
# The branch was feature/1234, new one - feature/1234-gone-bad
git checkout -b feature/1234-gone-bad

# Commit all the changes (all the mess) not to lose it & not to carry around
git commit -a -m "feature/1234 backup"

# Switch back to the original branch
git checkout feature/1234

# Pull the from remote (named 'origin'), thus 'repairing' our main problem
git pull origin/feature/1234

# Now you have a clean-and-non-diverged branch and a backup of the local changes.
# Check the needed files from the backup branch
git checkout feature/1234-gone-bad -- the/path/to/file.php

शायद यह एक तेज़ और स्वच्छ समाधान नहीं है, और मैंने अपना इतिहास खो दिया (5 के बजाय 1 प्रतिबद्ध), लेकिन इसने एक दिन के काम को बचा लिया।

Answer 8

यदि आपने कोड को अपनी दूरस्थ शाखा (GitHub / Bitbucket) में नहीं धकेला है तो आप नीचे दिए गए कमांड लाइन पर प्रतिबद्ध संदेश को बदल सकते हैं।

 git commit --amend -m "Your new message"

यदि आप किसी विशिष्ट शाखा पर काम कर रहे हैं, तो यह करें:

git commit --amend -m "BRANCH-NAME: new message"

यदि आपने पहले ही किसी गलत संदेश के साथ कोड को धक्का दे दिया है तो आपको संदेश बदलते समय सावधानी बरतने की आवश्यकता है। यानी जब आप प्रतिबद्ध संदेश बदलते हैं और इसे फिर से आगे बढ़ाने की कोशिश करते हैं तो आप समस्याएँ खत्म कर देते हैं। इसे सुचारू बनाने के लिए निम्न चरणों का पालन करें।

कृपया इसे करने से पहले पूरा उत्तर पढ़ें

git commit --amend -m "BRANCH-NAME : your new message"

git push -f origin BRANCH-NAME                # Not a best practice. Read below why?

महत्वपूर्ण नोट: जब आप सीधे बल पुश का उपयोग करते हैं तो आप कोड मुद्दों के साथ समाप्त हो सकते हैं जो अन्य डेवलपर्स एक ही शाखा पर काम कर रहे हैं। इसलिए उन संघर्षों से बचने के लिए आपको बल को धक्का देने से पहले अपनी शाखा से कोड खींचने की जरूरत है :

 git commit --amend -m "BRANCH-NAME : your new message"
 git pull origin BRANCH-NAME
 git push -f origin BRANCH-NAME

यह सबसे अच्छा अभ्यास है जब यह पहले से ही धकेल दिया गया था, तो प्रतिबद्ध संदेश को बदलना।

Comments

यदि आपने अपने अंतिम उदाहरण में कमिट को सफलतापूर्वक वापस ले लिया है, तो आपको पुश को मजबूर करने की आवश्यकता क्यों है? एक मानक धक्का पर्याप्त नहीं होगा? धन्यवाद

— थॉमस

थॉमस द्वारा पूछा गया प्रश्न वास्तव में बहुत मान्य है। खुद को पुल के बाद पुश को मजबूर करने की आवश्यकता नहीं थी।

— Na13-c

कृपया इसे "सबसे अच्छा अभ्यास" न कहें क्योंकि चारों ओर काम करने का एक तरीका है --force, स्वीकृत उत्तर देखें

— फ़रीद

Answer 9

यदि आप जानते हैं कि किसी ने भी आपकी अन-कमिटेड कमिट नहीं खींची है, तो उपयोग करें --force-with-lease विकल्प काgit push ।

TortoiseGit में, आप "पुश ..." विकल्प "बल: मई त्याग" और "ज्ञात परिवर्तन" की जाँच के तहत एक ही काम कर सकते हैं।

बल (ज्ञात परिवर्तनों को त्यागना) दूरस्थ रिपॉजिटरी को सुरक्षित गैर-फास्ट-फॉरवर्ड पुश स्वीकार करने की अनुमति देता है। यह रिमोट रिपॉजिटरी को कम करने का कारण बन सकता है; इसका उपयोग सावधानी से करें। यह रिमोट पर अन्य लोगों से अज्ञात परिवर्तनों को खोने से रोक सकता है। यह जांचता है कि क्या सर्वर शाखा रिमोट-ट्रैकिंग शाखा (ज्ञात परिवर्तन) के समान ही इंगित करती है। यदि हाँ, तो एक बल धक्का प्रदर्शन किया जाएगा। अन्यथा इसे अस्वीकार कर दिया जाएगा। चूँकि git में रिमोट-ट्रैकिंग टैग नहीं हैं, इसलिए इस विकल्प का उपयोग करके टैग्स को ओवरराइट नहीं किया जा सकता है।

Answer 10

आपको यह त्रुटि इसलिए मिल रही है क्योंकि Git रिमोट में पहले से ही ये कमिट फाइलें हैं। आपको इसके लिए शाखा को काम करने के लिए मजबूर करना होगा:

git push -f origin branch_name

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

git pull origin branch_name

यह उन मामलों में से एक है, जहां हमें कमिटमेंट को रिमोट से धकेलना पड़ता है।

Comments

पिछले उत्तरों में उठाए गए प्रमुख टिप्पणियों के लिए यह जवाब क्यों नहीं है?

— Na13-c

Answer 11

यहाँ के बाद आप पहले से ही बना दिया है अपने परिवर्तनों को पुश करने के लिए एक एक बहुत ही सरल और साफ रास्ता है git add "your files"और git commit --amend:

git push origin master -f

या:

git push origin master --force

Comments

मैं सुनता हूं कि यह बुरा है, और मुझे यकीन है कि यह है। डिफ़ॉल्ट रूप से विफल होने का एक (अच्छा) कारण है (और आवश्यकता - प्रवर्तन), मुझे यकीन है।

— रॉल्फ

Answer 12

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

Comments

ज़रुरी नहीं। मुद्दा यह हो सकता है कि आपने रिमोट रेपो से अपनी स्थानीय प्रति अपडेट नहीं की है। Git इसे आगे नहीं बढ़ाएगा क्योंकि आपको मैन्युअल रूप से मर्ज से निपटना पड़ सकता है। मेरे अन्य उत्तर में, मेरे पास एक कमांड (और स्पष्टीकरण) है जो एक धक्का को मजबूर करेगा - लेकिन सावधान रहें जो रिमोट में परिवर्तन को हटा सकता है।

— मियादी

Answer 13

मैं बस वही करता रहा जो मुझे करने के लिए गिट ने कहा था। इसलिए:

• संशोधित कमिट के कारण धक्का नहीं दे सकता।
• मैं सुझाव के अनुसार एक पुल करता हूं।
• विलय विफल हो जाता है। इसलिए मैं इसे मैन्युअल रूप से ठीक करता हूं।
• एक नई कमिट बनाएं ("मर्ज" लेबल) और इसे पुश करें।
• यह काम करने लगता है!

नोट: संशोधित प्रतिबद्धता नवीनतम थी।

Comments

अगर मैं और अधिक प्रतिष्ठा अंक होता है, तो मैं नीचे जाना होगा, तो मैं यहाँ विनम्रता से पूछना चाहता हूँ, जो एक आप पीड़ित थे? वह जो संशोधन हुआ? वह, जिसने संशोधित प्रतिबद्ध के साथ एक शाखा को खींचा और काम किया? संशोधन से पहले, या इसके बाद? मैंने सिर्फ मेरे हर संशोधन को मंजूरी दे दी क्योंकि मैंने आपको गलत समझा ... सौभाग्य से बहुत कुछ नहीं था ...

— बार्टिस Áron

Answer 14

लेखक के लिए और एक कमेटी को बदलते समय निम्नलिखित ने मेरे लिए काम किया।

git push -f origin master

Git यह पता लगाने के लिए पर्याप्त स्मार्ट था कि ये समान डेल्टास के कमिट थे जो केवल मेटा सूचना अनुभाग में भिन्न थे।

दोनों स्थानीय और दूरदराज के प्रमुखों ने सवाल में कमिट्स की ओर इशारा किया।

Answer 15

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

https://marketplace.visualstudio.com/items?itemName=cimdalli.git-commit-amend-push-force

जैसा कि आप इसके नाम से समझ सकते हैं, यह लगातार कमांड निष्पादित करता है

• git commit --amend
• git push --force

Answer 16

यहाँ, मैंने पिछली प्रतिबद्ध में एक संपादन कैसे तय किया:

1. अपना काम बचाओ अब तक।
2. किए गए परिवर्तनों को अभी के लिए दूर git stashकर दें : अब आपकी अंतिम प्रति की अवस्था में आपकी कामकाजी प्रति साफ है।
3. संपादन और सुधार करें।
4. "संशोधन" मोड में परिवर्तन करें:git commit --all --amend

5. आपका संपादक एक लॉग संदेश (डिफ़ॉल्ट रूप से, पुराने लॉग संदेश) के लिए पूछेगा। जब आप इससे खुश हों तो संपादक को सहेजें और छोड़ें।

   पुराने बदलाव के लिए नए बदलाव किए गए हैं। अपने लिए देखें git logऔरgit diff HEAD^

6. यदि आपके किए गए परिवर्तन फिर से लागू होते हैं, तो: git stash apply