গিট রিসেটের পরে আনস্টেজ করা পরিবর্তনগুলি --হার্ড

Question

পরে git reset --hard , বিভাগে git statusফাইল দেয় Changes not staged for commit:।

আমি চেষ্টাও করেছি git reset .,git checkout -- . এবং git checkout-index -f -a, কোন উপকার।

সুতরাং, কীভাবে আমি এই অনাস্থাবিহীন পরিবর্তনগুলি থেকে মুক্তি পেতে পারি?

এটি কেবল ভিজ্যুয়াল স্টুডিও প্রকল্প ফাইলগুলিতে আঘাত হানে বলে মনে হচ্ছে। রহস্যময়। এই পেস্টটি দেখুন: http://pastebin.com/eFZwPn9Z । এই ফাইলগুলির সাথে কী বিশেষ তা হ'ল এটি আমার কাছে .gitattributes এ রয়েছে:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

এছাড়াও, autocrlfআমার বিশ্বব্যাপী মিথ্যাতে সেট করা আছে .gitconfig। এটি কি কোনওভাবে প্রাসঙ্গিক হতে পারে?

Comments

আপনি কি commands আদেশগুলি সংগ্রহস্থলের মূল থেকে প্রয়োগ করেছেন? নোটিশটি .বর্তমান ডিরেক্টরিটি মূল ডিরেক্টরি নয়

— আলেকজান্ডার

আমি তাদের মূল সংগ্রহস্থল থেকে করেছি।

— নর্সপাপ করুন

আপনার gitসংস্করণ কি? হয় আপনি একটি নির্বোধ ভুল করছেন বা আপনার একটি পুরানো সংস্করণ বগী আছে?

— শাহবাজ

এটি গিট 1.7.4 এমএসএসজিট। এটি একটি ভুল হতে পারে, তবে কমান্ডগুলি যথেষ্ট সহজ বলে মনে হচ্ছে এবং আমি কোনও ভুল চিহ্নিত করতে পারি না।

— নর্সপপ

রেকর্ডের জন্য, আমি এমএসজিগিত (1.7.11) এর সর্বশেষ সংস্করণটি ব্যবহার করার চেষ্টা করেছি, তবে সমস্যাটি এখনও থেকেই যায়।

— নর্সপাপ করুন

Answer 1

আমারও একই সমস্যা ছিল এবং এটি .gitattributesফাইলের সাথে সম্পর্কিত ছিল । তবে সমস্যাটির কারণ হিসাবে ফাইল টাইপটি নির্দিষ্ট করা হয়নি .gitattributes।

আমি খালি চালিয়ে সমস্যার সমাধান করতে সক্ষম হয়েছি

git rm .gitattributes
git add -A
git reset --hard

Comments

এটি গিটাট্রিবিউটস ফাইলে * পাঠ্য = স্বয়ংক্রিয় নির্দেশিকা। এটি স্বয়ংক্রিয়ভাবে ফাইলের সমাপ্তি পরিবর্তন করে, সুতরাং যখন আপনি স্থিতি পরীক্ষা করবেন তখন ফাইলগুলি স্বয়ংক্রিয়ভাবে "সংশোধিত" হিসাবে চিহ্নিত হবে।

— কোডি জ্যাঙ্গো

এটি কাজ করে, তবে কেন আমি ঠিক বুঝতে পারছি না। কেউ কি প্রতিটি আদেশের ব্যাখ্যা করতে যত্নশীল?

— এডউইন স্টোলেটার

@ এনএলউইনো, git rm .gitattributesসূচক থেকে .gitattributes অপসারণ করে। git add -Aসূচকটিতে সমস্ত (.gitattributes অপসারণ সহ) যুক্ত করে, যা যদি তখনই সমস্যা হত তবে কেবলমাত্র .gitattributes অপসারণ হওয়া উচিত । git reset --hardসমস্ত আপত্তিহীন পরিবর্তনগুলি পুনরায় সেট করে, যার মধ্যে .gitattributes অপসারণ অন্তর্ভুক্ত থাকবে। মূলত, এটি একটিকে * text=autoমুছে ফেলার মাধ্যমে .gitattributes (এবং নির্দেশিকা) উপেক্ষা করে, সূচিটি মুছে ফেলার সময় পুনরায় সেট করে, সুতরাং এটি পুনরায় রেখে দেওয়া হবে, তবে আপনি ইতিমধ্যে অন্য ফাইলগুলি পুনরায় সেট করার পরে সেগুলি আবার পরিবর্তন করা হয়নি।

— মেঘাবৃত্তি

@ গেমস্ক্রিপ্টিং, এই সমাধানটি আমার পক্ষে কাজ করে না। এই জাতীয় কোনও ফাইল নেই .gitattributes: "মারাত্মক: প্যাথস্পেক '.গিটটিট্রিবিউটস' কোনও ফাইলের সাথে মেলে না"

— পেসারিয়ার

আমি যেমন করি এবং এটি বলে fatal: pathspec '.gitattributes' did not match any files । আমি কি ভুল করছি?

— মধু

Answer 2

স্থির !!!

নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করে আমি এই সমস্যার সমাধান করেছি

1) গিটের সূচক থেকে প্রতিটি ফাইল সরান।

git rm --cached -r .

2) সমস্ত নতুন লাইন শেষ করতে গিট সূচকটি পুনরায় লিখুন।

git reset --hard

সমাধানটি গিট সাইটে বর্ণিত পদক্ষেপের অংশ ছিল https://help.github.com/articles/dealing-with-line-endings/

Comments

যখন অন্য কিছু না করে এই কাজ করে! আমরা এটি এবং অন্যান্য অনেকগুলি থ্রেডে সবকিছু চেষ্টা করে দেখেছি - এটি একটি বড় বিকাশকারী দল তাই একই ক্রাফএলটিতে প্রত্যেককে পাওয়া দুঃস্বপ্ন হয়ে উঠেছে, তবে এটি সমস্যার সমাধান করে।

— tkesh

জবর ... আমি ব্যবহার "Git RM --chached <one_specific_file>, সবকিছু মোছার পরিবর্তে।" Git অবস্থা Git রিসেট --hard "ফাইল এটি ঠিক" যে ফাইল হিসাবে মোছা হয়েছে এবং untracked। তারপর রিপোর্ট " এবং সব অন্যান্য ফাইল যেমন "পরিবর্তনগুলি মঞ্চস্থ নয়" রিপোর্ট করা হয়েছিল হচ্ছে (Git RM ব্যবহারের আগে, আমি হার্ড রিসেট কোনো প্রভাব কঠিন চেষ্টা) আমি যেমন রহস্যময় উৎস কন্ট্রোল সিস্টেম

— joeking

আপনি জানেন, এটি আপনার সমস্ত ক্যাশে মুছে দেয়। বড় প্রকল্পগুলিতে এটি অনেক সময় নষ্ট করতে পারে।

— ওহার

তা নির্মম। আপনি রেপো ডিরেক্টরিটি মুছে ফেলা এবং পুনরায় ক্লোনিং করে একই কাজ করতে পারতেন।

— ingyhere

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

— ingyhere

Answer 3

গিট রিপোজিটরিতে নেই এমন ফাইলগুলি পুনরায় সেট করবে না। তাই আপনি পারেন:

$ git add .
$ git reset --hard

এটি সমস্ত পরিবর্তন মঞ্চস্থ করবে, যার ফলে গিট those ফাইলগুলি সম্পর্কে সচেতন হবে এবং তারপরে সেগুলি পুনরায় সেট করবে।

যদি এটি কাজ না করে, আপনি আপনার পরিবর্তনগুলি স্ট্যাশ করে ফেলে দেওয়ার চেষ্টা করতে পারেন:

$ git stash
$ git stash drop

Comments

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

— নর্সপপ

আপনি যখন গিট স্ট্যাটাস করবেন তখন কি হচ্ছে?

— ইউরিআলবুকার্ক

আমি একটি সমাধান সম্পর্কে চিন্তা। সেই প্রতিশ্রুতিটি মুছে ফেলার জন্য একটি প্রতিশ্রুতিবদ্ধ এবং একটি ইন্টারেক্টিভ রিবেস করুন।

— ইউরিআলবুকার্ক

আমি এটি এক পর্যায়ে চেষ্টা করেছি, এবং এটি কার্যকর হয়েছিল, আমি পরে আরও একবার চেষ্টা করেছিলাম এবং আমার উত্তরটির সম্পাদনায় আশ্চর্যজনক ফলাফলটি নিয়ে এসেছি।

— নর্সপপ

@YuriAlbuquerque, গীত বেশ বোঝে না Pola । git reset --hard" মঞ্চের অঞ্চল এবং কার্যনির্বাহী ডিরেক্টরি দুটি মিলে ফেলার জন্য" পুরো পয়েন্টটি কী নয় ? যদি কোনও ফাইল মঞ্চস্থ না হয়, স্পষ্টতই আমরা যখন করব তখন তা সরিয়ে ফেলতে চাই reset --hard।

— পেসারিয়ার

Answer 4

আপনি যদি উইন্ডোজের জন্য গিট ব্যবহার করেন তবে এটি সম্ভবত আপনার সমস্যা

আমার একই সমস্যা ছিল এবং স্ট্যাশ, হার্ড রিসেট, পরিষ্কার বা এমনকি এগুলি এখনও পরিবর্তনগুলি পিছনে ফেলে চলেছে। যে সমস্যাটি পরিণত হয়েছিল তা হল এক্স ফাইল মোড যা গিট দ্বারা সঠিকভাবে সেট করা হয়নি। এটি উইন্ডোজের গিট সহ একটি "জ্ঞাত সমস্যা"। স্থানীয় পরিবর্তনগুলি কোনও আসল ফাইলের পার্থক্য ছাড়াই গিটক এবং গিটের স্থিতিতে পুরানো মোড 100755 নতুন মোড 100644 হিসাবে দেখায়।

সমাধানটি হ'ল ফাইল মোড উপেক্ষা করুন:

git config core.filemode false

আরও তথ্য এখানে

Comments

এটি তখনও কাজ করেছিল যখন যখন rm -rf *; git checkout HEAD .হয়নি। রাম রাম!

— ফোরামুলেটর

আমার জন্য কাজ করেছেন, যখন স্ট্যাশ ড্রপ / হার্ড রিসেট / আরএম। সমস্ত অবদান ব্যর্থ।

— কাকিয়ো

লিনাক্সে গিট রেপো নিয়ে কাজ করতে আমার যখন সমস্যা ছিল যা ম্যাকের মাধ্যমে হোস্ট করা হয়েছিল তখনও এটি আমার জন্য কাজ করেছিল

— prmph

আমার জন্য কাজ করেছে - অন্য কিছুর চেষ্টা করেছেন এবং হ্যাঁ পুরানো মোড বনাম নতুন মোডটি সমস্যা ছিল (লক্ষ্য করা গেল আমার আলাদা নম্বর ছিল তবে ফাইলগুলি একই)

— তাইহুন এ কিম

জীবন ও সময় রক্ষাকারী

— যোগেশ পাটিল

Answer 5

ঠিক আছে, আমি সমস্যাটি সমাধান করেছি solved

দেখে মনে হয়েছিল যে .gitattributesফাইলটি এতে রয়েছে:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

প্রকল্পের ফাইলগুলি অচিহ্নিত অবস্থায় উপস্থিত করে তুলেছে। আমি কেন এটি নির্বোধ, এবং আমি সত্যিই আশা করছি যে গিটের পথে প্রাইভেট কেউ আমাদের একটি দুর্দান্ত ব্যাখ্যা দেবে।

আমার ফিক্স এই ফাইলগুলি মুছে ফেলার জন্য, এবং যোগ করার জন্য ছিল autocrlf = falseঅধীনে [core]মধ্যে .git/config।

এই পূর্ববর্তী কনফিগারেশন যেমন ঠিক একই জিনিস পরিমাণ নয়, যেমন আছে যে দেব প্রয়োজন autocrlf = false। আমি একটি ভাল সংশোধন করতে চাই

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

আমি লঙ্ঘনকারী লাইনগুলিকে মন্তব্য করেছিলাম, সেগুলিকে সংঘাতহীন করেছি এবং এটি কার্যকর হয়েছে। কি ... আমিও না ...!

Comments

আমি ঠিক এই একই সমস্যা দেখা দিয়েছিল এবং এটিই কাজ করেছিল কেবলমাত্র সমাধান। আমার ক্ষেত্রে আমি একটি বৈশিষ্ট্য শাখা থেকে আমার মাস্টারে স্যুইচ করেছি এবং উজান থেকে কিছু নতুন পরিবর্তন আনতে পেরেছি এবং এটি কেবল 2 টি ফাইলের জন্য ঘটতে শুরু করেছে যা সংশোধিত হয়েছিল। দেখে মনে হচ্ছে ফাইলগুলি ইউনিক্স থেকে উইন্ডোজ লাইন এন্ডিংয়ে স্যুইচ করা হয়েছে যার সাথে এর কিছু করার আছে। কীভাবে বা কেন তা নিশ্চিত নয়।

— স্টিভেন সুরোইয়াক

উইন্ডোজ গিতে +1 একই সমস্যা। ইতিমধ্যে ছিল autocrlf = false। আমি আপস্ট্রিম এসএনএন রেপো ( git svn fetch/ git merge git-svn) থেকে পরিবর্তনগুলিতে মার্জ হয়েছি এবং 1 টি ফাইল পরিবর্তিত হিসাবে চিহ্নিত রেখেছি । আশ্চর্যের বিষয়টি হ'ল আমার আগে এই সমস্যাটি ছিল এবং আমার যা করার দরকার তা হ'ল অন্য একটি শাখা পরীক্ষা করা ( -fপতাকা সহ), এবং তারপরে ফিরে যেতে। আমি এটি করেছি, এবং এটি কাজ করেছে, কিন্তু যখন আমি কোনও বৈশিষ্ট্য শাখায় স্যুইচ করেছি, "পরিবর্তন" ফিরে এসেছে! উত্তরের নীচে আপনার সম্পাদনাটি ছিল সমাধান। আমার ক্ষেত্রে আমি আমার .gitattributes ফাইলের শীর্ষে একটি লাইন মন্তব্য / অবিচ্ছিন্ন করেছি:* text=auto !eol

— অ্যারন ব্লেনকুশ

এই সম্পাদনাটি আমার পক্ষেও কাজ করেছে: লাইনগুলিতে মন্তব্য করুন .gitattributes, চালান git status, লাইনগুলিকে .gitattributesgit status

— অস্বচ্ছন্দ করুন

এটি কারণ গিট সেই ফাইলগুলি পুনরায় সেট করে দিচ্ছে, তারপরে .gitattributesআবার নির্দিষ্ট করা লাইন এন্ডিংগুলি প্রয়োগ করে । git diffসম্ভবত বিখ্যাত দেখায় সবুজ লাল / প্রাচীর প্রাচীর যে লাইন শেষ পার্থক্য আদর্শ।

— ডাগরুম

Answer 6

সম্ভাব্য কারণ # 1 - লাইন সমাপ্তি স্বাভাবিককরণ

একটি পরিস্থিতি যা ঘটতে পারে তা হ'ল যখন প্রশ্নে থাকা ফাইলটি লাইন এন্ডিং (1) এর সঠিক কনফিগারেশন ছাড়াই সংগ্রহস্থলে পরীক্ষা করা হয়েছিল যার ফলশ্রুতিতে কোনও ভুল লাইন সমাপ্তি, বা মিশ্র লাইন সমাপ্তির সাহায্যে সংগ্রহস্থলের একটি ফাইল থাকে। নিশ্চিত করতে, যাচাই করুন যা git diffকেবলমাত্র লাইনের শেষের পরিবর্তনগুলি দেখায় (এগুলি ডিফল্টরূপে দৃশ্যমান নাও হতে পারে, git diff | cat -vক্যারেজ রিটার্নকে আক্ষরিক হিসাবে দেখার চেষ্টা করুন^M অক্ষর )।

পরবর্তীকালে, কেউ সম্ভবত লাইন এন্ডিংগুলি (2) স্বাভাবিক করার জন্য সেটিংটি যুক্ত .gitattributesবা সংশোধন করেছে core.autocrlf। .gitattributesগ্লোবাল কনফিগারেশনের উপর ভিত্তি করে , গিট আপনার কার্যকরী অনুলিপিতে স্থানীয় পরিবর্তনগুলি প্রয়োগ করেছে যা অনুরোধ করা স্বাভাবিককরণের শেষ হওয়া লাইনটি প্রয়োগ করে। দুর্ভাগ্যক্রমে, কোনও কারণেgit reset --hard এই লাইন স্বাভাবিককরণের পরিবর্তনগুলি পূর্বাবস্থায় ফিরে আসে না।

সমাধান

স্থানীয় লাইনের সমাপ্তিগুলি পুনরায় সেট করা এমন কর্মক্ষেত্রগুলি সমস্যার সমাধান করবে না। যতবারই ফাইলটি গিট দ্বারা "দেখা" হয়, এটি সাধারণীকরণ চেষ্টা করে পুনরায় প্রয়োগ করবে, ফলস্বরূপ একই সমস্যার ফলস্বরূপ।

সেরা বিকল্পটি হ'ল গিটটি রেপোর সাথে মেলে সমস্ত রেখার শেষকে স্বাভাবিক করে .gitattributesএবং সেই পরিবর্তনগুলি সম্পাদন করে যা চায় তার স্বাভাবিকাকে প্রয়োগ করতে দেয় - গিট ফিল্টার-শাখার সাথে লাইন-এন্ডিংগুলি ঠিক করার চেষ্টা করা দেখুন , তবে ভাগ্য নেই ।

আপনি যদি সত্যিই ফাইলটিতে পরিবর্তনগুলি ম্যানুয়ালি চেষ্টা করে দেখতে চান এবং তা পরিবর্তন করতে চান তবে সবচেয়ে সহজ সমাধানটি হ'ল পরিবর্তিত ফাইলগুলি মুছে ফেলা হবে এবং তারপরে পুনরুদ্ধার করার জন্য গিটকে বলতে হবে, যদিও আমি নোট করেছি যে এই সমাধানটি 100% নিয়মিত কাজ করে না বলে মনে হচ্ছে সময় ( সতর্কতা: আপনার সংশোধিত ফাইলগুলির লাইন শেষের পরিবর্তে অন্য কোনও পরিবর্তন থাকলে এটি চালাবেন না !):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

মনে রাখবেন, যদি আপনি কোনও পর্যায়ে সংগ্রহস্থলের লাইনের শেষটিকে স্বাভাবিক না করেন তবে আপনি এই সমস্যাটি চালিয়ে যাবেন।

সম্ভাব্য কারণ # 2 - কেস সংবেদনশীলতা

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

/foo/bar

এখন লিনাক্সের কেউ ফাইলগুলিতে কমিট করে /foo/Bar(সম্ভবত কোনও বিল্ড সরঞ্জাম বা সেই ডিরেক্টরি তৈরি করে এমন কিছু কারণে) এবং পুশ করে। লিনাক্সে এটি এখন দুটি পৃথক ডিরেক্টরি:

/foo/bar/fileA
/foo/Bar/fileA

এই রেপো উইন্ডোজ বা ম্যাক আউট চেক করা হচ্ছে পরিবর্তিত হতে পারে fileAউইন্ডোজ চেক উপর রিসেট করা যাবে না, কারণ প্রতিটি রিসেট উপর, Git আউট /foo/bar/fileA, এবং তারপর কারণ উইন্ডোজ কেস অবশ হল, বিষয়বস্তু মুছে ফেলা হয় fileAসঙ্গে /foo/Bar/fileAতাদের ফলে হচ্ছে "রুপান্তরিত",।

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

/foo/bar/fileA
/foo/bar/filea

অনুরূপ অন্যান্য পরিস্থিতিও থাকতে পারে যা এ জাতীয় সমস্যা তৈরি করতে পারে।

সংবেদনশীল ফাইল সিস্টেমে গিটটি সত্যই এই পরিস্থিতিটি সনাক্ত করতে হবে এবং একটি দরকারী সতর্কতা বার্তা প্রদর্শন করা উচিত, তবে এটি বর্তমানে তা নয় (ভবিষ্যতে এটি পরিবর্তিত হতে পারে - এই আলোচনা এবং git.git মেলিং তালিকায় সম্পর্কিত প্রস্তাবিত প্যাচগুলি দেখুন)।

সমাধান

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

(1) এটি সম্ভবত কেউ উইন্ডোজ ব্যবহার করে, প্রশ্নযুক্ত .gitattributesফাইলটির কোনও সংজ্ঞা ছাড়াই এবং ডিফল্ট গ্লোবাল সেটিংস core.autocrlfযার জন্য রয়েছে তা falseদেখুন (দেখুন (2))।

(২) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Comments

অভিশাপস্র পুত্র, এই পথে সমস্ত পথ চালিয়েছে। প্রথম লাইনের পরে আমাকে প্রতিশ্রুতিবদ্ধ হতে হয়েছিল তবে শেষ পর্যন্ত আমি মাস্টার চেকআউট করতে সক্ষম হয়েছি। মজা ছিল না।

— টিম লাইবারম্যান

Answer 7

যদি অন্য উত্তরগুলি কাজ না করে, ফাইলগুলি যুক্ত করার চেষ্টা করে তবে পুনরায় সেট করা

$ git add -A
$ git reset --hard

আমার ক্ষেত্রে, যখন গিট ট্র্যাক করছে এমন একগুচ্ছ খালি ফাইলগুলি এটি তখন সহায়তা করেছিল।

Comments

এইটা কাজ করে. আমি কেবল এর $ git add .পরিবর্তে ব্যবহার করেছি$ git add -A

— বজর্ন গারহার্ড-পেডারসেন

Answer 8

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

আরও তথ্যের জন্য: https://stackoverflow.com/a/2016426/67824

Comments

এই জাতীয় ফাইলগুলির নাম চালানোর জন্যgit ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d

— ডায়োমিডিস স্পিনেলিস

Answer 9

আপনি stashআপনার পরিবর্তনগুলি সরাতে পারেন , তারপরে স্ট্যাশ ফেলে দিন:

git stash
git stash drop

Comments

আপনি এই আগ্রহী হতে পারে ।

— শাহবাজ

Answer 10

এই পদ্ধতির কোনওটিই আমার পক্ষে কাজ করেনি, এর একমাত্র সমাধান ছিল পুরো রেপোকে নাক করে দেওয়া এবং এটি পুনরায় ক্লোন করা। এর মধ্যে রয়েছে স্ট্যাশিং, রিসেট করা, পুনরায় সেট করা, ক্লিফ সেটিংস, কেস সংবেদনশীলতা ইত্যাদি দীর্ঘশ্বাস ..

Comments

আপডেট করুন, এটি আমার মাউন্ট করা কেস সংবেদনশীল ফাইল সিস্টেমটি বাস্তবে সংবেদনশীল নয় sensitive আমি নির্দিষ্ট করার পরে উপরে উল্লিখিত কৌশলগুলি ব্যবহার করে এই সমস্যাটি সমাধানযোগ্য।

— জন হান্ট

Answer 11

ক্লিন কমান্ড চালান :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Comments

দুর্ভাগ্যক্রমে এটি লাইন শেষ সম্পর্কিত সমস্যাগুলি সমাধান করে না।

— ক্রিস্টোফার স্নাইডার

এটি কেবলমাত্র আমার সমস্যাটি সমাধান করুন, আমার সমস্যাটি যাই হোক না কেন। আমার কোনও .gitattributesফাইল ছিল না এবং লাইন সমাপ্তি কোনও সমস্যা ছিল না কারণ আমি একটি লিনাক্স বাক্সে আছি এবং ডেভস এবং আমাদের সার্ভারের সমস্ত লিনাক্স।

— স্যামুয়েল নেফ 22:25

Answer 12

আপনার পরীক্ষা করুন .gitattributes।

আমার ক্ষেত্রে আমার *.js text eol=lfএটি আছে এবং গিট বিকল্প core.autocrlfছিল true।

এটি আমাকে পরিস্থিতি এনে দেয় যখন গিট আমার ফাইলগুলির লাইন শেষের স্বতঃবর্তিত হয় এবং আমাকে এটি ঠিক করতে এবং এমনকি git reset --hard HEADকিছু করতেও বাধা দেয় ।

আমি *.js text eol=lfআমার মন্তব্যে এটি সংশোধন করেছি .gitattributesএবং এটির পরে এটি সংক্ষিপ্ত।

দেখে মনে হচ্ছে এটি কেবল গিট যাদু।

Comments

এটি আমার জন্য ছিল, আমার প্রকল্পটি আমার প্রকল্পের সাথে পরিচয় করিয়ে *.bat text eol=crlfদেওয়া up

— লিও

Answer 13

আমি জড়িত একটি অনুরূপ ইস্যুতে আঘাত করেছি .gitattributes, তবে আমার ক্ষেত্রে গিটহাবের এলএফএস জড়িত। যদিও এটি ওপি-র পরিস্থিতিটি ঠিক নয়, আমি মনে করি এটি .gitattributesফাইলটি কী করে তা ব্যাখ্যা করার একটি সুযোগ সরবরাহ করে এবং কেন এটি "ফ্যান্টম" পার্থক্যের আকারে অযৌক্তিক পরিবর্তন হতে পারে।

আমার ক্ষেত্রে, একটি ফাইল ইতিমধ্যে আমার ভান্ডারে ছিল যেমন সময়ের শুরু থেকেই। সাম্প্রতিক প্রতিশ্রুতিবদ্ধভাবে, আমি git-lfs trackএকটি প্যাটার্নটি ব্যবহার করে একটি নতুন নিয়ম যুক্ত করেছি যা কিছুটা বিস্তৃত ছিল এবং এই প্রাচীন ফাইলটির সাথে মিল রেখে শেষ হয়েছিল ind আমি জানি আমি এই ফাইলটি পরিবর্তন করতে চাইনি; আমি জানি যে আমি ফাইলটি পরিবর্তন করিনি, তবে এখন এটি আমার অযাচিত পরিবর্তনসমূহে ছিল এবং সেই ফাইলটিতে কোনও পরিমাণ চেকআউট বা হার্ড রিসেটই এটি ঠিক করতে যাচ্ছিল না। কেন?

গিটহাব এলএফএস এক্সটেনশানটি প্রাথমিকভাবে ফাইলটির gitমাধ্যমে অ্যাক্সেস সরবরাহ করে এমন হুকগুলি উপকারের মাধ্যমে কাজ করে .gitattributes। সাধারণত, .gitattributesফাইলগুলিতে কীভাবে মিলে যাওয়া প্রক্রিয়া করা উচিত তা নির্দিষ্ট করে এন্ট্রিগুলি । ওপি'র ক্ষেত্রে, এটি লাইন এন্ডিংগুলি স্বাভাবিক করার সাথে সম্পর্কিত ছিল; আমার মধ্যে, এটি এলএফএসকে ফাইল স্টোরেজ পরিচালনা করতে দেয় কিনা তা ছিল। উভয় ক্ষেত্রেই, প্রকৃত ফাইলটি gitযখন একটি গণনা করার সময় দেখা git diffহয় সেই ফাইলটির সাথে মেলে না যে আপনি ফাইলটি পরিদর্শন করার সময় দেখেন। অতএব, আপনি যদি ফাইলটিকে .gitattributesএটির সাথে মিলে যায় এমন প্যাটার্নের মাধ্যমে কীভাবে প্রক্রিয়াজাতকরণ করেন তবে এটি ফাইলের সত্যিকার অর্থে কোনও পরিবর্তন না হলেও স্থিতির প্রতিবেদনে অযৌক্তিক পরিবর্তন হিসাবে প্রদর্শিত হবে।

যা যা বলেছিল, প্রশ্নের "উত্তর" হ'ল .gitattributesফাইলের পরিবর্তন যদি এমন কিছু হয় যা আপনি করতে চান তবে আপনার অবশ্যই সত্য পরিবর্তনগুলি যুক্ত করে এগিয়ে যাওয়া উচিত। যদি তা না হয় তবে .gitattributesআপনি যা করতে চান তা আরও ভালভাবে উপস্থাপন করতে সংশোধন করুন ।

তথ্যসূত্র

1. GitHub LFS স্পেসিফিকেশন - কিভাবে তারা মধ্যে হুক গ্রেট বিবরণ cleanএবং smudgeফাংশান কল আপনার ফাইলটি প্রতিস্থাপন করতে gitএকটি হ্যাশ সঙ্গে একটি সাধারণ টেক্সট ফাইল সঙ্গে বস্তু।

2. gitattributes ডকুমেন্টেশন - কীভাবে gitআপনার ডকুমেন্টগুলি প্রক্রিয়া করে তা কাস্টমাইজ করার জন্য যা উপলভ্য রয়েছে তার সমস্ত বিবরণ ।

Answer 14

আমারও একই সমস্যা ছিল। আমি করেছি git reset --hard HEADতবে এখনও প্রতিবার আমি git statusকিছু ফাইল সংশোধিত হিসাবে দেখছি।

আমার সমাধান তুলনামূলকভাবে সহজ ছিল। আমি সবেমাত্র আমার আইডিই বন্ধ করে দিয়েছি (এটি এটি এক্সকোড ছিল) এবং আমার কমান্ড লাইনটি বন্ধ করে দিয়েছে (এখানে এটি আমার ম্যাক ওএসে টার্মিনাল ছিল) এবং এটি আবার চেষ্টা করেছিলাম এবং এটি কাজ করে।

তবুও আমি কখনই সমস্যার উত্স সৃষ্টি করতে সক্ষম হইনি।

Answer 15

আমি বিশ্বাস করি যে উইন্ডোজের গিট নিয়ে একটি সমস্যা আছে যেখানে গিটটি এলোমেলোভাবে চেকআউটে ভুল রেখার সমাপ্তি লিখেছে এবং একমাত্র কাজ হ'ল অন্য কয়েকটি শাখা চেকআউট করা এবং গিটকে পরিবর্তনগুলি উপেক্ষা করতে বাধ্য করা। তারপরে আপনি যে শাখায় কাজ করতে চান তা চেকআউট করুন।

git checkout master -f
git checkout <your branch>

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

সম্পাদনা: আমি সম্ভবত প্রথমবারের মতো ভাগ্যবান হয়ে উঠতে পারি। দেখা যাচ্ছে যে আমি শাখাগুলি স্যুইচ করার পরে আবার কিছুটা পেয়েছি। দেখা গেল যে শাখাগুলি পরিবর্তন হওয়ার পরে ফাইলগুলি গিট পরিবর্তিত হিসাবে প্রতিবেদন করছে was (স্পষ্টতই যেহেতু গিটটি ধারাবাহিকভাবে ফাইলগুলিতে শেষ হওয়া সিআরএলএফ লাইন প্রয়োগ করছে না))

আমি উইন্ডোজের সর্বশেষতম গিটটিতে আপডেট করেছি এবং আশা করি সমস্যাটি চলে গেছে।

Answer 16

অনুরূপ ইস্যু, যদিও আমি নিশ্চিত কেবল পৃষ্ঠের উপরে। যাইহোক, এটি কাউকে সাহায্য করতে পারে: আমি যা করেছি (এফডাব্লুআইডাব্লু, সোর্সট্রি তে): নিরীক্ষিত ফাইলটি স্ট্যাশ করে, তারপরে একটি হার্ড রিসেট করেছিল।

Answer 17

অন্যান্য উত্তরগুলি যেমন নির্দেশ করেছে, লাইন-এন্ড স্বয়ংক্রিয় সংশোধন করার কারণে সমস্যা। আমি * .svg ফাইলগুলির সাথে এই সমস্যার মুখোমুখি হয়েছি। আমি আমার প্রকল্পে আইকনগুলির জন্য এসভিজি ফাইল ব্যবহার করেছি।

এই সমস্যাটি সমাধান করার জন্য, আমি গিটকে জানাতে চাই যে এস.জি.জি. ফাইলগুলি .gitattributes এ নীচের লাইনটি যুক্ত করে পাঠ্যের পরিবর্তে বাইনারি হিসাবে বিবেচনা করা উচিত

* .svg বাইনারি

Answer 18

একই পরিস্থিতিতে। বহু প্রোগ্রামারদের সাথে বহু বছরের যন্ত্রণার ফলস্বরূপ যারা এক ফাইলের লাইনের শেষ প্রান্তের বিভিন্ন এনকোডিংগুলি (। এসপি , জেএসএস, .সিএসএস ... সারাংশ নয়) সক্ষম করতে পেরেছিলেন । কিছু সময় আগে .gitattributes অস্বীকার করেছে। রেপো বাম জন্য autorclf = trueএবং সেটিংস safecrlf = warn।

আর্কাইভ থেকে লাইনের বিভিন্ন প্রান্তের সাথে সিঙ্ক্রোনাইজ করার সময় শেষ সমস্যাটি দেখা দিয়েছে। সংরক্ষণাগার থেকে অনুলিপি করার পরে, গিট স্ট্যাটাসে নোটের সাহায্যে অনেকগুলি ফাইল পরিবর্তন করা হয়

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

গিতে গাছের লাইনের সমাপ্তি কীভাবে স্বাভাবিক করা যায় তার টিপস সাহায্য

git add -u

Answer 19

আরেকটি সম্ভাবনা যা আমার মুখোমুখি হয়েছিল তা হ'ল সংগ্রহস্থলের প্যাকেজগুলির মধ্যে একটিতে পৃথক হেড শেষ হয়েছিল। যদি এখানে উত্তরগুলির কোনওটিই সহায়তা না করে এবং আপনি এইরকম গিট স্ট্যাটাস বার্তার মুখোমুখি হন তবে আপনার একই সমস্যা হতে পারে:

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:   path/to/package (new commits)

মধ্যে যাওয়া path/to/packageফোল্ডারের একটি git statusনিম্নলিখিত ফল উচিত:

HEAD detached at 7515f05

এবং নিম্নলিখিত কমান্ডের পরে সমস্যাটি ঠিক করা উচিত, যেখানে masterআপনার স্থানীয় শাখাটি দ্বারা প্রতিস্থাপন করা উচিত:

git checkout master

এবং আপনি একটি বার্তা পাবেন যে আপনার স্থানীয় শাখা দূরবর্তী শাখার পিছনে কিছু পরিমাণ কমিট করবে। git pullএবং আপনি বনের বাইরে থাকা উচিত!

Answer 20

কিছু কারণে

git add .

কাজ হয়নি , কিন্তু

$ git add -A

কাজ করা!