फ़ाइल चाल के रूप में हटाए गए और एक नई फ़ाइल को कैसे चिह्नित करें?

505

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

git

— pupeno
स्रोत

3

किसी दिए गए फ़ाइल के लिए old_file.txtहै, तो git mv old_file.txt new_file.txtके बराबर है git rm --cached old_file.txt, mv old_file.txt new_file.txt, git add new_file.txt।

— जारल सेप

3

Jarl: नहीं, यह नहीं है। यदि फ़ाइल के भीतर भी परिवर्तन हैं, git mvतो उन्हें कैश में नहीं जोड़ा git addजाएगा , लेकिन होगा। मैं फ़ाइल को वापस ले जाना पसंद करता हूं ताकि मैं उपयोग कर सकूं git mv, फिर git add -pअपने परिवर्तन सेट की समीक्षा कर सकूं।

— 15

मेरी स्क्रिप्ट चेकआउट कृपया github.com/Deathangel908/python-tricks/blob/master/...

— deathangel908

संभव डुप्लिकेट क्या यह संभव है कि git में फ़ाइलों को स्थानांतरित करना / उनका नाम बदलना और उनका इतिहास बनाए रखना चाहिए?

— माइकल फ्रीजिम

पिछले 8 वर्षों में Git में सुधार हुआ है, अगर यह सिर्फ एक फ़ाइल है, तो शीर्ष उत्तर stackoverflow.com/a/433142/459 ने कुछ नहीं किया ... लेकिन आप rover पाने के लिए stackoverflow.com/a/1541072/459 का अनुसरण कर सकते हैं / अपडेट जोड़ सकते हैं एक एमवी / संशोधित स्थिति के लिए।

— dlamblin

434

यदि आपका संशोधन बहुत गंभीर नहीं है, तो गिट स्वचालित रूप से चाल / नाम का पता लगाएगा। बस git addनई फ़ाइल, और git rmपुरानी फ़ाइल। git statusफिर दिखाएगा कि क्या इसने नाम बदला है।

इसके अलावा, निर्देशिकाओं के चारों ओर ले जाने के लिए, आपको निम्न की आवश्यकता हो सकती है:

उस निर्देशिका संरचना के शीर्ष पर सीडी।
Daud git add -A .
git statusयह सत्यापित करने के लिए चलाएँ कि "नई फ़ाइल" अब एक "बदला हुआ" फ़ाइल है

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

— Bombe
स्रोत

75

स्पष्टता: 'बहुत गंभीर नहीं' का अर्थ है कि नई फ़ाइल और पुरानी फ़ाइल> 50% 'समान' हैं जो कुछ समान अनुक्रमित अनुक्रमों पर आधारित हैं जो गिट उपयोग करता है।

— पीजेड

151

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

— marczych

19

यह ध्यान देने योग्य है कि जब " गिट की बात स्वचालित रूप से चाल / नाम का पता लगाएगी "। यह समय आप उपयोग पर ऐसा नहीं करता है git status, git logया git diff, नहीं समय आप करते हैं पर git add, git mvया git rm। इसके अलावा नाम बदलने का पता लगाने की बात करते हुए, यह केवल मंचन फ़ाइलों के लिए समझ में आता है। तो git mvफ़ाइल में एक बदलाव के बाद ऐसा लग सकता है git statusजैसे कि वह इसे एक के रूप में मानता है rename, लेकिन जब आप फ़ाइल पर git stage(जैसे ही git add) उपयोग करते हैं, तो यह स्पष्ट हो जाता है कि नाम बदलने के लिए परिवर्तन बहुत बड़ा है।

— जारल सेप

5

असली कुंजी नए और पुराने दोनों स्थानों को जोड़ने के लिए लगती है git add, जैसा कि @ jrhorn424 से पता चलता है, शायद केवल एक ही बार में पूरे रेपो होना चाहिए।

— 18

4

यह अचूक नहीं है, खासकर अगर फ़ाइल बदल गई और छोटी है। क्या इस कदम के बारे में विशेष रूप से बताने के लिए एक विधि है?

— rebs

112

अलग-अलग कमिट में कदम और संशोधित करें।

— हांक गे
स्रोत

12

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

— पुतीनो

1

पर्ल को भी इसकी आवश्यकता है, और मैंने कभी भी चाल / नाम का पता लगाने के लिए Git नहीं लिया है।

— जकरवे

10

@ जॉकवे, मेरे पास था। छोटी फ़ाइलों के साथ आसानी से होता है, मुझे लगता है कि वे "एक कदम का मतलब करने के लिए 'बहुत अलग हो जाते हैं"।

— ANEves

2

क्या यह स्वचालित करने का कोई तरीका है? मेरे पास अनुक्रमणिका में कई फाइलें हैं, पहले इस कदम को कमिट करना चाहते हैं, और फिर बदलाव, लेकिन इसे मैन्युअल रूप से करना मुश्किल है

— पुनः प्रकाशित करें।

5

एक बात का ध्यान रखें कि यदि git diffएक नाम के तहत कोई नाम नहीं पहचाना जाता है, तो वह इसे दो कमिट में नहीं पहचानेगा। ऐसा करने के लिए आपको -Mउर्फ उपयोग की आवश्यकता होगी --find-renames। इसलिए यदि प्रेरणा जिसने आपको इस प्रश्न के लिए प्रेरित किया है, तो नाम को एक पुल अनुरोध (अनुभव से बोलना) में देखना है, इसे दो कमिट में विभाजित करना आपको उस लक्ष्य की ओर नहीं बढ़ाएगा।

— मटलियू

44

यह सब एक अवधारणात्मक बात है। Git आम तौर पर चाल को पहचानने में अच्छा है, क्योंकि GIT एक कंटेंट ट्रैकर है

यह सब वास्तव में निर्भर करता है कि आपकी "स्टेट" इसे कैसे प्रदर्शित करती है। यहाँ एकमात्र अंतर -M ध्वज है।

git log --stat -M

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300


        Category Restructure

     lib/Gentoo/Repository.pm                |   10 +++++-----
     lib/Gentoo/{ => Repository}/Base.pm     |    2 +-
     lib/Gentoo/{ => Repository}/Category.pm |   12 ++++++------
     lib/Gentoo/{ => Repository}/Package.pm  |   10 +++++-----
     lib/Gentoo/{ => Repository}/Types.pm    |   10 +++++-----
     5 files changed, 22 insertions(+), 22 deletions(-)

गिट लॉग --stat

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300

    Category Restructure

 lib/Gentoo/Base.pm                |   36 ------------------------
 lib/Gentoo/Category.pm            |   51 ----------------------------------
 lib/Gentoo/Package.pm             |   41 ---------------------------
 lib/Gentoo/Repository.pm          |   10 +++---
 lib/Gentoo/Repository/Base.pm     |   36 ++++++++++++++++++++++++
 lib/Gentoo/Repository/Category.pm |   51 ++++++++++++++++++++++++++++++++++
 lib/Gentoo/Repository/Package.pm  |   41 +++++++++++++++++++++++++++
 lib/Gentoo/Repository/Types.pm    |   55 +++++++++++++++++++++++++++++++++++++
 lib/Gentoo/Types.pm               |   55 -------------------------------------
 9 files changed, 188 insertions(+), 188 deletions(-)

गिट मदद लॉग इन करें

   -M
       Detect renames.

   -C
       Detect copies as well as renames. See also --find-copies-harder.

— केंट फ्रेड्रिक
स्रोत

76

क्षमा करें यदि यह थोड़ा कठिन लगता है, लेकिन "Git आम तौर पर चाल को पहचानने में अच्छा है, क्योंकि GIT एक कंटेंट ट्रैकर है" मेरे लिए एक गैर-सीक्वेटुर की तरह लगता है। यह एक कंटेंट ट्रैकर है, हाँ, और शायद यह चालों का पता लगाने में अच्छा होता है, लेकिन एक कथन वास्तव में दूसरे का अनुसरण नहीं करता है। सिर्फ इसलिए कि यह एक कंटेंट ट्रैकर है जिसका पता लगाना जरूरी नहीं है। वास्तव में, एक कंटेंट ट्रैकर का कोई भी पता नहीं चल सकता है।

— लॉरेंस गोंसाल्वेस

1

@WarrenSeine जब आप किसी निर्देशिका का नाम बदलते हैं, तो उस निर्देशिका में फ़ाइलों का SHA1 नहीं बदलता है। आपके पास एक ही SHA1s के साथ एक नया TREE ऑब्जेक्ट है। कोई कारण नहीं है कि निर्देशिका का नाम बदलने से महत्वपूर्ण डेटा परिवर्तन होगा।

— केंट फ्रेड्रिक

1

@KentFredric आपने दिखाया कि "git log" के साथ -M का उपयोग करके हम यह जांच सकते हैं कि फ़ाइल का नाम बदला गया है या नहीं और मैंने इसे और इसके ठीक काम की कोशिश की, लेकिन जब मैं अपने कोड को समीक्षा के लिए पोस्ट करता हूं और उस फ़ाइल को gerrit ( gerritcodereview.com ) में देखता हूं यह दिखाता है कि फ़ाइल नई जोड़ी गई है और पिछली हटा दी गई थी। तो क्या "git कमिट" में एक विकल्प है जिसके उपयोग से मैं कमिट करता हूं और gerrit इसे ठीक से दिखाता है।

— पैट्रिक

1

नहीं, मैंने ऐसा बिल्कुल नहीं दिखाया। मैंने दिखाया Git एक ऐड + डिलीट का नाटक करने में सक्षम है, कंटेंट समान होने के कारण उसका नाम बदला गया है। यह जानने का कोई तरीका नहीं है कि क्या हुआ, और इसकी परवाह नहीं है। सभी गिट याद है "जोड़ा" और "हटाए गए"। "नाम बदला" कभी दर्ज नहीं किया जाता है।

— केंट फ्रेड्रिक

1

उदाहरण के लिए, मैंने हाल ही में रेपो पर बहुत सारे "कॉपी + एडिट" किए। इसे देखने के अधिकांश तरीके केवल "नई फ़ाइल" देखते हैं, लेकिन यदि आप पास होते हैं git log -M1 -C1 -B1 -D --find-copies-harder, तो "खोज" कर सकते हैं कि नई फ़ाइल को पहले कॉपी किया गया है। कभी-कभी यह सही करता है, अन्य समय में, यह पूरी तरह से असंबंधित फाइलें पाता है जो समान सामग्री के साथ हुआ था।

— केंट फ्रेड्रिक

36

git diff -Mया git log -Mस्वचालित रूप से जब तक वे वास्तव में हैं तब तक मामूली परिवर्तनों के साथ नाम बदलने के रूप में स्वचालित रूप से ऐसे परिवर्तनों का पता लगाना चाहिए । यदि आपके छोटे बदलाव मामूली नहीं हैं, तो आप समानता को कम कर सकते हैं, उदाहरण के लिए

$ git log -M20 -p --stat

इसे डिफ़ॉल्ट 50% से 20% तक कम करने के लिए।

— साइमन पूर्व
स्रोत

13

क्या विन्यास में दहलीज को परिभाषित करना संभव है?

— 11

34

यहां एक, या कुछ, नामांकित और संशोधित फ़ाइलों के लिए एक त्वरित और गंदे समाधान है जो कि अन-कम है।

मान लीजिए कि फ़ाइल का नाम रखा गया था fooऔर अब इसका नाम bar:

नाम बदलें barएक अस्थायी नाम करने के लिए:
```
mv bar side
```
चेकआउट foo:
```
git checkout HEAD foo
```
नाम बदलें fooकरने के लिए barGit के साथ:
```
git mv foo bar
```
अब अपनी अस्थायी फ़ाइल को फिर से नाम दें bar।
```
mv side bar
```

यह अंतिम चरण वह है जो आपकी परिवर्तित सामग्री को फ़ाइल में वापस लाता है।

हालांकि यह काम कर सकता है, अगर स्थानांतरित फ़ाइल मूल गिट से सामग्री में बहुत अलग है, तो यह तय करने के लिए अधिक कुशल माना जाएगा कि यह एक नई वस्तु है। मुझे प्रदर्शित करें:

$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md
    modified:   work.js

$ git add README.md work.js # why are the changes unstaged, let's add them.
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    deleted:    README
    new file:   README.md
    modified:   work.js

$ git stash # what? let's go back a bit
Saved working directory and index state WIP on dir: f7a8685 update
HEAD is now at f7a8685 update
$ git status
On branch workit
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .idea/

nothing added to commit but untracked files present (use "git add" to track)
$ git stash pop
Removing README
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README
    modified:   work.js

Dropped refs/stash@{0} (1ebca3b02e454a400b9fb834ed473c912a00cd2f)
$ git add work.js
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README

$ git add README # hang on, I want it removed
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    deleted:    README
    new file:   README.md
    modified:   work.js

$ mv README.md Rmd # Still? Try the answer I found.
$ git checkout README
error: pathspec 'README' did not match any file(s) known to git.
$ git checkout HEAD README # Ok the answer needed fixing.
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README.md
    modified:   work.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Rmd

$ git mv README README.md
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   work.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Rmd

$ mv Rmd README.md
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md
    modified:   work.js

$ # actually that's half of what I wanted; \
  # and the js being modified twice? Git prefers it in this case.

— dlamblin
स्रोत

27

यह प्रक्रिया बिना किसी उद्देश्य के कार्य करती है। git नाम बदलने के लिए कोई मेटाडेटा नहीं जोड़ता है, git mvबस git rm/ git addजोड़ी के लिए एक सुविधा है । यदि आप पहले से ही 'एमवी बार फू' कर चुके हैं, तो आपको बस इतना करना होगा कि आप git add fooऔर git rm barकमिट करने से पहले यह सुनिश्चित कर लें । यह एक ही git add -Aआदेश, या संभवतः एक git add foo; git commit -aअनुक्रम के रूप में किया जा सकता है ।

— सीबी बेली

17

मुझे पता है कि इससे पहले कि मैंने ऐसा किया, Git ने इसे एक चाल के रूप में नहीं पहचाना। ऐसा करने के बाद, Git ने इसे एक चाल के रूप में मान्यता दी।

8

यह इसे एक चाल के रूप में पहचानता है। लेकिन यह भी एक अस्थिर परिवर्तन के रूप में परिवर्तन अब है। एक बार जब आप addफिर से फाइल करते हैं, तो git इस कदम को तोड़ता है / हटाए गए / फिर से जोड़ देता है।

— माइकल पिफेल

4

git commitचरण 3 के बाद यह प्रक्रिया काम करेगी , अन्यथा यह गलत है। इसके अलावा, @CharlesBailey सही है, आप आसानी mv blah fooसे चरण 3 में एक सामान्य कर सकते हैं और उसके बाद एक ही परिणाम प्राप्त कर सकते हैं।

— DaFlame

5

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

— डैनैक

20

यदि आप git statusनाम नहीं दिखाने के बारे में बात कर रहे हैं , तो git commit --dry-run -aइसके बजाय प्रयास करें

— मंडल
स्रोत

11

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

संपादित करें: जाहिरा तौर पर यदि आप नई फाइलें जोड़ते हैं और फिर कमांड लाइन से एक git स्टेटस करते हैं, तो नाम बदलने से पहले कमिट करना चाहिए।

संपादन 2: इसके अलावा, TortoiseGit में, कमिटमेंट में नई फाइलें जोड़ें, लेकिन उन्हें कमिट न करें। फिर यदि आप शो लॉग कमांड में जाते हैं और वर्किंग डायरेक्टरी को देखते हैं, तो आप देखेंगे कि कमिट करने से पहले Git ने नाम बदला है या नहीं।

यहाँ एक ही सवाल उठाया गया था: https://tortoisegit.org/issue/1389 और यहाँ फिक्स करने के लिए बग के रूप में लॉग इन किया गया है: https://tortoisegit.org/issue/1440 यह पता चलता है कि यह Tortoiseit की प्रतिबद्धता के साथ एक प्रदर्शन मुद्दा है। यदि आपने नई फाइलें नहीं जोड़ी हैं, तो डायलॉग और जीआईटी स्थिति में भी मौजूद है।

— जाइल्स रॉबर्ट्स
स्रोत

2

आप सही हैं, भले ही TortoiseGit डिलीट + ऐड दिखाता हो, भले ही git स्टेटस डिलीट + ऐड दिखाता हो, भले ही git कमिट -ड्री-रन शो डिलीट + ऐड हो, git कमिट के बाद मैं नाम बदलकर देखता हूं और डिलीट + ऐड नहीं करता।

— टॉमस क्यूब्स

1

मुझे पूरा यकीन है कि इतिहास पुनर्लेखन के दौरान स्वचालित नाम का पता लगाता है ; कमिट में यह हमेशा + डिलीट होता है। यह भी आप का वर्णन स्किज़ोफ्रेनिक व्यवहार की व्याख्या करता है। इसलिए यहां विकल्प: stackoverflow.com/a/434078/155892

— मार्क सोउल

10

या आप इस सवाल का जवाब एम्बर द्वारा यहाँ कौड देते हैं ! इसे फिर से उद्धृत करने के लिए:

सबसे पहले, मैन्युअल रूप से स्थानांतरित फ़ाइल के लिए अपने मंचन को रद्द करें:

$ git reset path/to/newfile
$ mv path/to/newfile path/to/oldfile

फिर, फ़ाइल को स्थानांतरित करने के लिए Git का उपयोग करें:

$ git mv path/to/oldfile path/to/newfile

बेशक, यदि आप पहले से ही मैनुअल कदम रखते हैं, तो आप इसके बजाय कदम से पहले संशोधन करने के लिए रीसेट करना चाह सकते हैं, और फिर बस वहां से mv प्राप्त कर सकते हैं।

— Zingam
स्रोत

7

git mvओएस चाल आदेशों के बजाय, फ़ाइलों को स्थानांतरित करने के लिए कमांड का उपयोग करें : https://git-scm.com/docs/git-mv

कृपया ध्यान दें कि git mvकमांड केवल Git संस्करणों में 1.8.5 और ऊपर मौजूद है। इसलिए आपको इस कमांड का उपयोग करने के लिए अपने Git को अपडेट करना पड़ सकता है।

— mostafa.elhoushi
स्रोत

3

मुझे यह समस्या हाल ही में थी, जब कुछ फाइलों को स्थानांतरित करना (लेकिन संशोधित नहीं करना) था।

समस्या यह है कि जब मैंने फ़ाइलों को स्थानांतरित किया था, तो गिट ने कुछ लाइन अंत को बदल दिया, और फिर यह बताने में सक्षम नहीं था कि फाइलें समान थीं।

का उपयोग करते हुए git mvसमस्या हल, लेकिन यह केवल एक फ़ाइलें / निर्देशिका पर काम करता है, और मैं ऐसा करने के लिए भंडार की जड़ में फ़ाइलों का एक बहुत कुछ था।

इसे ठीक करने का एक तरीका कुछ बैश / बैच मैजिक के साथ होगा।

दूसरा तरीका निम्नलिखित है

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

— cedd
स्रोत

1

मेरे लिए यह कमिट करने से पहले सभी परिवर्तनों को बचाने और उन्हें फिर से बाहर पॉप करने के लिए काम करता था। इसने जोड़ / हटाए गए फ़ाइलों का फिर से विश्लेषण किया और इसे सही ढंग से स्थानांतरित के रूप में चिह्नित किया।

— एलेक्स इली
स्रोत

0

ऐसा करने के लिए शायद एक बेहतर "कमांड लाइन" तरीका है, और मुझे पता है कि यह एक हैक है, लेकिन मैं कभी भी एक अच्छा समाधान नहीं ढूंढ पाया।

TortoiseGIT का उपयोग करना: यदि आपके पास एक GIT है, जहां कुछ फ़ाइल चालन संचालन, नाम बदलने के बजाय लोड / हटाने के लोड के रूप में दिखाई दे रहे हैं, भले ही फ़ाइलों में केवल छोटे परिवर्तन हों, तो यह करें:

आपने स्थानीय स्तर पर जो किया है, उसमें जाँच करें
एक 2 प्रतिबद्ध में एक मिनी एक लाइन में परिवर्तन की जाँच करें
कछुआ गिट में GIT लॉग इन करें
दो कमिट का चयन करें, राइट क्लिक करें, और "एक कमेट में मर्ज करें" का चयन करें

नई कमिट अब फ़ाइल का नाम ठीक से दिखाएगी ... जो उचित फ़ाइल इतिहास को बनाए रखने में मदद करेगी।

— जॉन री
स्रोत

0

जब मैं एक ही समय में एक फ़ाइल को संपादित, नाम बदलने और स्थानांतरित करता हूं, तो इनमें से कोई भी समाधान काम नहीं करता है। इसका समाधान दो कमिट में करना है (एडिट और रीनेम / मूव सेपरेट) और फिर fixupदूसरा कमिट git rebase -iटू थिस कमिट टू वन कमिट।

— Hativ
स्रोत

0

जिस तरह से मैं इस सवाल को समझता हूं वह है "कैसे एक पुरानी फ़ाइल को हटाने और फ़ाइल चाल के रूप में एक नई फ़ाइल के निर्माण को पहचानें"।

हाँ एक पुरानी फ़ाइल को हटाने और एक पुरानी फ़ाइल डालने के बाद कार्यशील निर्देशिका में, git status" deleted: old_file" और " Untracked files: ... new_file" कहेंगे

लेकिन स्टेजिंग इंडेक्स / लेवल में एक बार जब आप फाइल को जोड़ते और हटाते हैं, तो इसे फाइल मूव के रूप में पहचाना जाएगा। ऐसा करने के लिए, यह मानते हुए कि आपने अपने ऑपरेशन सिस्टम का उपयोग करके विलोपन और निर्माण किया है, निम्नलिखित कमांड दें:

git add new_file
git rm old_file

यदि फ़ाइल की सामग्री 50% या अधिक समान है, तो रनिंग git statusकमांड आपको देना चाहिए:

renamed: old_file -> new_file

— harshainfo
स्रोत

1

git status" deleted: old_file" और " Untracked files: ... new_file" कहेंगे : जीआईटी 2.18 के बाद से नहीं: stackoverflow.com/a/50573107/6309

— VonC