1166

কখনও কখনও গিট git rm --cachedকোনও ফাইল আনস্টেজ করার পরামর্শ দেয় , কখনও কখনও git reset HEAD file। আমি কখন ব্যবহার করব?

সম্পাদনা করুন:

D:\code\gt2>git init
Initialized empty Git repository in D:/code/gt2/.git/
D:\code\gt2>touch a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a
#
D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

D:\code\gt2>touch b

D:\code\gt2>git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       b
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add b

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

git git-reset git-rm

— Senthess
সূত্র

20

কেন? আমি বলব কারণ গিটের কমান্ডলাইন ইন্টারফেসটি জৈবিকভাবে বিকশিত হয়েছিল এবং জিনিসগুলিকে সামঞ্জস্যপূর্ণ করার জন্য কখনও কোনও বৃহত পুনর্গঠনের বিষয় হয় নি। (যদি আপনি অসম্মতি, নোট কিভাবে git rmউভয় পারেন পর্যায় একটি মুছে ফেলার এবং unstage একটি উপরন্তু )

— রোমান Starkov

3

@ ক্রমিনস: আমি সম্মত হই যে গিতের ইন্টারফেসের বিভিন্ন জটিলতা রয়েছে কারণ এটি জৈবিকভাবে বিকশিত হয়েছিল, তবে একটি অপসারণ অবশ্যই একটি সংযোজনের একটি বিপরীত ফাংশন, সুতরাং এটি rmপূর্বাবস্থায় ফিরে আসার পক্ষে যুক্তিযুক্ত নয় addকি? আপনার কীভাবে rmআচরণ করা উচিত বলে মনে করেন ?

— জাজ

6

আপনার প্রশ্নের শুধুমাত্র প্রকৃত উত্তর যে অধিকার পর হয় git initকিছু নেই HEADরিসেট করতে।

— মাইলস রাউট

এর জন্য সেরা দস্তাবেজগুলি: help.github.com/articles/changing-a-remote-s-url

— স্কটিব্ল্যাডস

4

@ জাজ, আমি আমার মতামত দেব rmইউনিক্স প্রসঙ্গে মুছে ফেলা বোঝায়। এটি সূচকে যুক্ত করার বিপরীতে নয়। স্টেজিং-স্টেট পরিবর্তন করার জন্য ফাংশনগুলি মুছে ফেলার জন্য একটি ফাংশন ওভারলোড করা উচিত নয়। যদি এমন বাস্তবায়নের বিশদ থাকে যা এগুলিকে একত্রিত করতে সুবিধাজনক করে তোলে, যা কেবল গিটের মধ্যে বিমূর্ততার একটি চিন্তাশীল স্তরটির অভাবকে নির্দেশ করে, যা ব্যবহারকে পরিষ্কার করে দেবে।

— জোশুয়া গোল্ডবার্গ

1891

git rm --cached <filePath> কোনও ফাইল আনস্টেজ করে না , এটি আসলে রেপো থেকে ফাইল (গুলি) অপসারণের প্রক্রিয়াটি ধরে নেয় (ধরে নিলে এটি ইতিমধ্যে প্রতিশ্রুতিবদ্ধ ছিল) তবে ফাইলটি আপনার কার্যকারী গাছের মধ্যে ফেলে দেয় (আপনাকে একটি চিহ্নবিহীন ফাইল রেখে দেয়)।

git reset -- <filePath>প্রদত্ত ফাইল (গুলি) এর জন্য কোনও পর্যায়ের পরিবর্তন আনস্টেজ করবে ।

এটি বলেছিল, আপনি যদি git rm --cachedমঞ্চস্থ হওয়া কোনও নতুন ফাইল ব্যবহার করেন তবে এটি মূলত এমন মনে হবে যে আপনি এটি কেবল আগেই প্রতিশ্রুতিবদ্ধ না হওয়ার কারণে এটি স্টেস্টেস্ট করেছিলেন।

গিট আপডেট করুন 2.24 গিটের
এই নতুন সংস্করণে আপনি এর git restore --stagedপরিবর্তে ব্যবহার করতে পারেন git reset। গিট ডকস দেখুন ।

— রায়ান স্টুয়ার্ট
সূত্র

70

আমি বলব git rm --cachedযে ফাইলটি আনস্টেজ করে তবে এটি ওয়ার্কিং ডিরেক্টরি থেকে সরিয়ে দেয় না।

— পিয়েরে লেস্পিনে

4

সংযোজনের জন্য মঞ্চযুক্ত একটি ফাইল সরানোর জন্য যাতে এটি আর মঞ্চস্থ না হয় অবশ্যই "সংযোজনের জন্য একটি ফাইল আনস্টেজিং" বলা যেতে পারে, তাই না? শেষ ফলাফলটি কোনও পর্যায়ক্রমে মুছে ফেলা নয় , এটি অবশ্যই, সুতরাং আমি মনে করি ভুল বোঝাবুঝি সম্পূর্ণ বোধগম্য।

— রোমান স্টারকভ

4

সুতরাং সাধারণত, কেউ git rm --cached <filePath>রেপোতে থাকা উচিত ছিল না তা বোঝার পরে রেপো থেকে কিছু ফাইল (গুলি) অপসারণ করতে ব্যবহার করা হত : সুতরাং সম্ভবত এই কমান্ডটি চালানো এবং তারপরে প্রাসঙ্গিক ফাইল যুক্ত করা gitignore। আমি কি সঠিক?

— অ্যাড্রিয়েন

13

প্রশ্নোত্তর উভয়ই এই অনেক ভোট দিয়ে, আমি বলতে হবে যে স্পষ্টতই আমরা একটি unstageকমান্ড পেতে চান git।

— milosmns

4

"গিট স্ট্যাটাস" এখনই পরামর্শ দেয়: "গিট রিস্টোর - স্টেজড <ফাইল> ..." আনস্টেজ করতে ব্যবহার করুন

— ইয়ুসার

334

git rm --cachedসূচক থেকে একটি ফাইল অপসারণ করতে ব্যবহৃত হয়। ফাইলটি ইতিমধ্যে রেপোতে রয়েছে সেই ক্ষেত্রে, ফাইলটিকে git rm --cachedসূচক থেকে সরিয়ে ফেলবে, এটি কার্যক্ষম ডিরেক্টরিতে রেখে দেবে এবং একটি প্রতিশ্রুতিবদ্ধতা এখন রেপো থেকেও সরিয়ে ফেলবে। মূলত, প্রতিশ্রুতি দেওয়ার পরে, আপনি ফাইলটি রূপান্তরিত করতে এবং স্থানীয় অনুলিপিটি রাখতে পারবেন।

git reset HEAD file(যা পূর্বনির্ধারিতভাবে --mixedপতাকাটি ব্যবহার করে ) ফাইলটি ইতিমধ্যে রেপোতে থাকে সে ক্ষেত্রে এটি পৃথকভাবে রেপো (হেড) এর সাথে ফাইলের সূচী সংস্করণটি প্রতিস্থাপন করে, কার্যকরভাবে এটির পরিবর্তনগুলি আনস্টেজ করে ।

রূপান্তরিত ফাইলের ক্ষেত্রে, ফাইলটি হেডে নেই বলে এটি পুরো ফাইলটি আনস্টেজ করতে চলেছে। এই দিকটি git reset HEAD fileএবং git rm --cachedএকই, তবে সেগুলি একই নয় (রেপোতে ইতিমধ্যে ফাইলগুলির ক্ষেত্রে ব্যাখ্যা হিসাবে)

এই প্রশ্নটির কাছে Why are there 2 ways to unstage a file in git?- গিটে কিছু করার সত্যিই একমাত্র উপায় নেই। এটাই এর সৌন্দর্য :)

— manojlds
সূত্র

7

গৃহীত উত্তর এবং এটি উভয়ই দুর্দান্ত এবং আপনি কেন অন্যটি বনাম ব্যবহার করবেন তা ব্যাখ্যা করুন। তবে গিট কেন দুটি পৃথক পদ্ধতির পরামর্শ দেয় সে সম্পর্কে অন্তর্নিহিত প্রশ্নের সরাসরি উত্তর দেয় না । ওপি-র উদাহরণের প্রথম ক্ষেত্রে, একটি গিট ইনিশ সবেমাত্র করা হয়েছে। সেক্ষেত্রে গিটটি "গিট আরএম - ক্যাচড" পরামর্শ দেয় কারণ সেই সময়ে ভান্ডারটিতে কোনও কমিট থাকে না এবং তাই হেড বৈধ নয়। "গিট রিসেট হেড - একটি" উত্পাদন করে: "মারাত্মক: 'হেড' বৈধ রেফ হিসাবে সমাধান করতে ব্যর্থ।"

— sootsnoot

5

'গিট চেকআউট'-এর সাহায্যে, আপনি ফাইলটিতে যে সমস্ত পরিবর্তন করেছেন তা কি আপনি হারাবেন না? আমি ভুল বোঝাবুঝি না করলে কোনও ফাইল আনস্টেজ করার মতো জিনিস নয়।

— জন ডিঘান

there is never really only one way to do anything in git. that is the beauty of it- হুম ... কেন? এটি সর্বদা দুর্দান্ত, যখন কেবল একটি স্পষ্ট উপায় থাকে। এটি মস্তিস্কে আমাদের অনেক সময় এবং স্মৃতি সাশ্রয় করে))

— ওটো শাভাদজে

128

বেশ সহজভাবে:

git rm --cached <file> গিটটি ফাইলটিকে পুরোপুরি ট্র্যাক করা বন্ধ করে দেয় (ফাইল সিস্টেমে এটি ছেড়ে, সাধারণ git rm* এর বিপরীতে )
git reset HEAD <file> শেষ প্রতিশ্রুতিবদ্ধ হওয়ার পরে ফাইলটিতে কোনও পরিবর্তন আনস্টেজ করে (তবে কমান্ডের নাম বলতে পারে ** এর বিপরীতে ফাইল সিস্টেমে সেগুলি ফিরিয়ে দেয় না)) ফাইলটি পুনর্বিবেচনার নিয়ন্ত্রণে রয়েছে।

ফাইলটি যদি আগে সংশোধন নিয়ন্ত্রণে না থাকে (যেমন আপনি git addপ্রথমবারের জন্য সম্পাদনা করেছিলেন এমন একটি ফাইল আনস্টেজ করছেন ), তবে দুটি কমান্ডের একই প্রভাব রয়েছে, সুতরাং "কিছু করার দুটি উপায়" এর উপস্থিতি "।

_{* অনুগ্রহপূর্বক প্রতিবেদনের জন্য প্রতিশ্রুতিবদ্ধgit rm --cached একটি ফাইল সম্পর্কিত তার উত্তর, ড্র্রুটি তার উত্তরে উল্লেখ করেছেন Keep এই প্রশ্নের প্রসঙ্গে একটি ফাইল সবেমাত্র যুক্ত হয়েছে এবং প্রতিশ্রুতিবদ্ধ নয়, এটি নিয়ে উদ্বিগ্ন হওয়ার কিছু নেই।}

_{** নামটির কারণে গিট রিসেট কমান্ডটি ব্যবহার করতে আমি বিব্রতকরভাবে দীর্ঘ সময় ধরে ভয় পেয়েছিলাম - এবং এখনও আমি প্রায়শই সিনট্যাক্সটি সন্ধান করি যাতে নিশ্চিত হয় না যে আমি কোনও ত্রুটি না ফেলে। ( আপডেট : অবশেষে একটি টিএলডিআর পৃষ্ঠায় ব্যবহারের সংক্ষিপ্ত বিবরণ দেওয়ারgit reset জন্য আমি সময় নিলাম , সুতরাং এখন এটি কীভাবে কাজ করে তার একটি আরও ভাল মানসিক মডেল এবং আমি যখন কিছু বিবরণ ভুলে যাই তার জন্য একটি দ্রুত রেফারেন্স পেয়েছি))}

— waldyrious
সূত্র

এটিgit rm <file> --cached

— নবজাতক

8

আমি সত্যিই মনে করি না যে এই উত্তরটির 4 ই আগস্টের সম্পাদনাটি সামগ্রিক উন্নতি হয়েছিল। এটিতে প্রযুক্তিগত নির্ভুলতা থাকতে পারে (আমি এটি মূল্যায়নের জন্য যোগ্য মনে করি না) তবে আমি ভয় পাচ্ছি যে "বর্তমানে-চিহ্নবিহীন ফাইলটি ট্র্যাকিং শুরু করা আবশ্যকীয় ভাষাকে আনসেটস" এর মতো ভাষায় পরিচয় করিয়ে উত্তরটির সুরটি খুব কম অ্যাক্সেসযোগ্য করে তুলেছে ", এবং" সূচক "এবং" শিরোনাম "এর মতো জার্গন ব্যবহার করে, স্পষ্টভাবে ধরণের ধরণের স্টাফ যা নতুনদেরকে ভয় দেখায়। যদি কেউ পারেন তবে দয়া করে আরও নতুন আগত-বান্ধব ভাষা পুনরুদ্ধার করতে সম্পাদনা করুন।

— ওয়াল্ডরিয়াস

5

@ ওয়াল্ডরিয়াসের সাথে একমত মূল উত্তরটি সম্ভবত গিট পাঠ্যপুস্তকের বাইরে ছিল না, তবে এটি যথেষ্ট প্রযুক্তিগত পর্যায়ে প্রশ্নের উত্তর দিয়েছে। প্রযুক্তিগত বিবরণগুলি মন্তব্যগুলিতে স্পষ্ট করা উচিত ছিল, এমন কোনও সম্পাদনা হিসাবে নয় যে আসল উদ্দেশ্যটিকে অস্পষ্ট করে।

— সাইমন রব

আমি সম্পাদনাটি উল্টেছি। আমি বিশ্বাস করি যে সম্প্রদায়ের দ্বারা পর্যাপ্ত বৈধতা ছিল (পূর্ববর্তী মন্তব্যে এবং তাদের ভোটে) যে সম্পাদনাটি উত্তরের স্পষ্টতার জন্য ক্ষতিকারক ছিল।

— ওয়াল্ডরিয়াস

দ্রষ্টব্য @ ড্র্রুটি হুঁশিয়ারি উচ্চারণ করে যে যদি rm --cachedকেউ ব্যবহার করে এবং চাপ দিলে, একই শাখাটি টানলে যে কেউ ফাইল (গুলি) আসলে তাদের কার্যকারী গাছ থেকে সরিয়ে ফেলবে।

— টম হেল

53

এই থ্রেডটি খানিকটা পুরানো, তবে এখনও এটি একটি স্বজ্ঞাত সমস্যা না হওয়ায় আমি কিছুটা বিক্ষোভ যুক্ত করতে চাই:

me$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   to-be-added
#   modified:   to-be-modified
#   deleted:    to-be-removed
#

me$ git reset -q HEAD to-be-added

    # ok

me$ git reset -q HEAD to-be-modified

    # ok

me$ git reset -q HEAD to-be-removed

    # ok

# or alternatively:

me$ git reset -q HEAD to-be-added to-be-removed to-be-modified

    # ok

me$ git status
# On branch master
# 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)
#
#   modified:   to-be-modified
#   deleted:    to-be-removed
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   to-be-added
no changes added to commit (use "git add" and/or "git commit -a")

git reset HEAD(ছাড়াই -q) পরিবর্তিত ফাইল সম্পর্কে একটি সতর্কতা দেয় এবং এর প্রস্থান কোড 1 যা কোনও স্ক্রিপ্টে একটি ত্রুটি হিসাবে বিবেচিত হবে।

সম্পাদনা: git checkout HEAD to-be-modified to-be-removedআনস্টেজ করার জন্যও কাজ করে, তবে পরিবর্তনটি পুরোপুরি ওয়ার্কস্পেস থেকে সরিয়ে দেয়

আপডেট গিট ২.২৩.০: সময়ে সময়ে, আদেশগুলি পরিবর্তিত হয়। এখন, git statusবলেছেন:

  (use "git restore --staged <file>..." to unstage)

... যা তিনটি ধরণের পরিবর্তনের জন্য কাজ করে

— ড্যানিয়েল অ্যাল্ডার
সূত্র

ধন্যবাদ, প্রথম দুটি উত্তর থেকে সম্পূর্ণ পরিষ্কার ছিল না (সম্ভবত পরিভাষা সম্পর্কে আমার অজ্ঞতা) যে গিট রিসেট স্থানীয়ভাবে ফাইলটিতে পরিবর্তনগুলি রেখেছিল (গিট চেকআউটের বিপরীতে যা সেগুলি ফিরিয়ে দেবে)।

— স্যুপডগ

আপনার সংস্করণটির সূচনাতে একটি সতর্কতা দেওয়া উচিত, কারণ পুরানো সংস্করণটি নতুন সংস্করণগুলিতে ফাইলগুলি মুছে দেয়

— লুই মরিসিও

36

যদি আপনি দুর্ঘটনাক্রমে এমন ফাইল মঞ্চস্থ করেন যা আপনি প্রতিশ্রুতিবদ্ধ করতে চান না এবং আপনি অবশ্যই পরিবর্তনগুলি পরিবর্তন করে রাখতে চান তবে আপনি এটি ব্যবহার করতে পারেন:

git stash
git stash pop

এটি হেডে একটি রিসেট সম্পাদন করে এবং আপনার পরিবর্তনগুলি পুনরায় প্রয়োগ করে, আপনাকে পৃথক ফাইলগুলি প্রতিশ্রুতি দেওয়ার জন্য পুনরায় মঞ্চ করার অনুমতি দেয়। আপনি যদি টান অনুরোধের জন্য কোনও বৈশিষ্ট্য শাখা তৈরি করতে ভুলে গেছেন তবে এটিও সহায়ক git stash ; git checkout -b <feature> ; git stash pop।

— Ives
সূত্র

3

এটি একটি পরিষ্কার সমাধান এবং "গিট আরএম" টাইপ করার চেয়ে অনেক কম উদ্বেগজনক

— সাবমিজ

1

git stashঅন্যান্য সম্পর্কিত বেনিফিট রয়েছে, কারণ এটি রিফ্লগটিতে এন্ট্রি তৈরি করে যা ভবিষ্যতে উপলব্ধ। সন্দেহ হলে, এগিয়ে যান এবং একটি git stash(উদাহরণস্বরূপ git stash save -u "WIP notes to self"('-u' হ'ল স্ট্যাশ প্রতিশ্রুতিতে কোনও নতুন / তালাবিহীন ফাইল অন্তর্ভুক্ত করা) ... তারপরে স্ট্যাশ কমিট git reflog show stashএবং তাদের শা এর তালিকা দেখার চেষ্টা করুন I ওরফে মতalias grs="git reflog show stash"

— চিত্তাকর্ষক

15

এই 2 টি কমান্ডের বেশ কয়েকটি সূক্ষ্ম পার্থক্য রয়েছে যদি প্রশ্নে থাকা ফাইলটি ইতিমধ্যে রেপোতে রয়েছে এবং সংস্করণ নিয়ন্ত্রণে রয়েছে (পূর্বে প্রতিশ্রুতিবদ্ধ ইত্যাদি):

git reset HEAD <file> বর্তমান প্রতিশ্রুতিতে ফাইলটি আনস্টেজ করে।
git rm --cached <file>ভবিষ্যতে কমিট করার জন্য ফাইলটি স্টেস্টেজ করা হবে। এটি স্টেস্টেড না হওয়া পর্যন্ত এটি আবার যুক্ত হয়ে যায় git add <file>।

এবং আরও একটি গুরুত্বপূর্ণ পার্থক্য রয়েছে:

চালানোর পর git rm --cached <file>এবং দূরবর্তী আপনার শাখা ধাক্কা, দূরবর্তী থেকে আপনার শাখা কাছে যে কেউ ফাইল পাবেন আসলে তাদের ফোল্ডার থেকে মুছে ফেলা, আপনার স্থানীয় শ্রমিক মাত্র untracked (অর্থাত শারীরিকভাবে ফোল্ডার থেকে মোছা) হয়ে ফাইল সেট যদিও।

এই শেষ পার্থক্যটি এমন প্রকল্পগুলির জন্য গুরুত্বপূর্ণ যা একটি কনফিগার ফাইল অন্তর্ভুক্ত যেখানে দলের প্রতিটি বিকাশকারী একটি আলাদা কনফিগার (যেমন বিভিন্ন বেস ইউআরএল, আইপি বা পোর্ট সেটিং) ব্যবহার করে থাকে তাই আপনি যদি git rm --cached <file>আপনার শাখাটি টানেন এমন কাউকে ব্যবহার করে ম্যানুয়ালি পুনরায় চাপতে হবে - কনফিগারেশন তৈরি করুন, বা আপনি এগুলিকে আপনার নিজের পাঠাতে পারেন এবং তারা এটিকে তাদের আইপি সেটিংসে পুনরায় সম্পাদনা করতে পারে (ইত্যাদি), কারণ মুছে ফেলা কেবলমাত্র লোকজনকে দূরবর্তী থেকে আপনার শাখাটি টানতে প্রভাবিত করে।

— DrewT
সূত্র

10

এর stageমাধ্যমে আপনাকে একটি সম্পূর্ণ ডিরেক্টরি বলি git add <folder>, তবে আপনি মঞ্চযুক্ত তালিকা থেকে কোনও ফাইল বাদ দিতে চান (অর্থাত্ চলমান সময় উত্পন্ন উত্স তালিকা git status) এবং বাদ দেওয়া ফাইলের মধ্যে পরিবর্তনগুলি রাখতে চান (আপনি কোনও কিছুর উপর কাজ করছেন এবং এটি প্রতিশ্রুতি দেওয়ার জন্য প্রস্তুত নয়, তবে আপনি আপনার কাজ হারাতে চান না ...)। আপনি কেবল ব্যবহার করতে পারেন:

git reset <file>

যখন আপনি চালাতে git status, আপনি যে যাই হোক না কেন ফাইল (গুলি) আপনি দেখতে পাবেন resetহয় unstagedএবং আপনি যে ফাইলগুলি বাকি addedএখনও stagedতালিকা।

— jiminikiz
সূত্র

10

1।

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a

(অবরুদ্ধ করতে "গিট আরএম - ক্যাচড ..." ব্যবহার করুন)

গিট হল পয়েন্টারগুলির একটি সিস্টেম
আপনার পয়েন্টারটি এ পরিবর্তন করতে আপনার এখনও কোন প্রতিশ্রুতি নেই
'বালতি থেকে ফাইলগুলি বাইরে নিয়ে যাওয়ার' একমাত্র উপায় হ'ল পরিবর্তনগুলি দেখার জন্য আপনি গিটকে যে ফাইলগুলি বলেছেন সেগুলি সরিয়ে ফেলা

2।

D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a

গিট কমিট -মা

আপনি প্রতিশ্রুত, ' সংরক্ষিত '

3।

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

(আনস্টেজ করার জন্য "গিট রিসেট হেড ..." ব্যবহার করুন)

আপনি এই মুহুর্তে আপনার কোডে একটি প্রতিশ্রুতিবদ্ধ করেছেন
এখন আপনি আপনার পয়েন্টারটিকে আপনার প্রতিশ্রুতিতে পুনরায় সেট করতে পারেন ' শেষ বারে ফিরে যান '

— টিমোথি এলজে স্টুয়ার্ট
সূত্র

1

এটি আসলে একমাত্র উত্তর যা সঠিকভাবে প্রশ্নের উত্তর দেয়, আইএমও। এটি আসলে সেই প্রশ্নের উত্তর দেয়, যা 'গিট আরএম - ক্যাশেড' এবং 'গিট রিসেট হেড'-এর মধ্যে পার্থক্যগুলি কী নয়' তবে 'গিট অসামঞ্জস্যভাবে উভয়কে বিকল্প হিসাবে কেন দেয়?', উত্তরটি হ'ল পুনরায় সেট করার কোনও মাথা নেই আপনি git initপ্রথমবারের জন্য যখন ।

— মাইলস রাউট

5

আমি অবাক হয়েছি কেউ গিট রিফ্লোগের কথা উল্লেখ করেছে ( http://git-scm.com/docs/git-reflog ):

# git reflog
<find the place before your staged anything>
# git reset HEAD@{1}

রিফ্লোগ হ'ল একটি গিটার ইতিহাস যা কেবল রেপোতে পরিবর্তনগুলি ট্র্যাক করে না, তবে ব্যবহারকারীর ক্রিয়াগুলিও সনাক্ত করে (উদাহরণস্বরূপ, বিভিন্ন শাখায় চেকআউট ইত্যাদি) এবং এই ক্রিয়াগুলি পূর্বাবস্থায় ফেলার অনুমতি দেয়। সুতরাং ভুলভাবে মঞ্চস্থ হওয়া ফাইলটি আনস্টেজ করার পরিবর্তে আপনি যেখানে সেই ফাইলটিতে ফিরতে পারেন যেখানে আপনি ফাইলগুলি স্টেজ করেননি।

এটি অনুরূপ git reset HEAD <file>তবে নির্দিষ্ট ক্ষেত্রে আরও দানাদার হতে পারে।

দুঃখিত - সত্যই আপনার প্রশ্নের উত্তর না দিয়ে, তবে আমি প্রায়শই ব্যবহার করি এমন ফাইলগুলি আনস্টেজ করার জন্য আরেকটি উপায় দেখিয়েছি (আমি রায়ান স্টুয়ার্টের উত্তরগুলির মতো এবং ওয়ালিডেরিয়াস খুব বেশি।)) আমি আশা করি এটি সহায়তা করবে।

— অ্যালেক্স
সূত্র

5

শুধু ব্যবহার করুন:

git reset HEAD <filename>

এটি ফাইলটি আনস্টেজ করে এবং আপনি যে পরিবর্তনগুলি করেছিলেন তা ঠিক রাখে, যাতে আপনি চাইলে শাখা এবং git addসেই ফাইলগুলি অন্য কোনও শাখায় বদলে নিতে পারেন। সমস্ত পরিবর্তন রাখা হয়।

— এডগার কুইন্টেরো
সূত্র

3

এটি আমার কাছে মনে হবে যে git rm --cached <file>ডিরেক্টরিটি সরল git rm <file>না করেই ফাইলটিকে সূচক থেকে সরিয়ে দেয় যেখানে কোনও সমতল উভয়ই কাজ করে, ঠিক যেমন কোনও ওএস rm <file>ফাইলটি এর সংস্করণ না সরিয়ে ডিরেক্টরি থেকে মুছে ফেলবে।

— এরনি কোড্ডেল
সূত্র

1

২.২৩ সংস্করণ এবং কেবলমাত্র উপরে,

এই পরামর্শগুলির পরিবর্তে, আপনি ফাইল (গুলি) এর git restore --staged <file>জন্য ব্যবহার করতে পারেন unstage।

— কান তাহা কোকেন
সূত্র

এটি --stageপাশাপাশি উভয় বিকল্পের সাথে কাজ করে --staged।

— ধানা 1310

গিটে একটি ফাইল আনস্টেজ করার দুটি উপায় কেন?

1।

2।

3।