বর্তমান শাখায় অনির্ধারিত পরিবর্তনগুলি উপস্থিত হলে অন্য একটি শাখা চেকআউট করুন

Question

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

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

এখানে বিধি কি? পরিবর্তনগুলি মঞ্চস্থ করা হয় বা স্টেস্টেড না হওয়া থেকে কী আসে যায়? অন্য একটি শাখায় পরিবর্তনগুলি বহন করা আমার কোনও অর্থবোধ করে না, কখনও কখনও গিট কেন এটি অনুমতি দেয়? যে, এটি কিছু পরিস্থিতিতে সহায়ক?

Answer 1

প্রাথমিক নোট

এখানে পর্যবেক্ষণটি হ'ল, আপনি কাজ শুরু করার পরে branch1(ভুলে যাওয়া বা বুঝতে না পেরে branch2প্রথমে কোনও ভিন্ন শাখায় স্যুইচ করা ভাল হবে ), আপনি চালান:

git checkout branch2

কখনও কখনও গিট বলে "ঠিক আছে, আপনি এখন শাখা 2 এ আছেন!" কখনও কখনও, গিট বলে "আমি এটি করতে পারি না, আমি আপনার কিছু পরিবর্তন হারাব।"

যদি গিট আপনাকে এটি করতে দেয় না তবে এগুলি স্থায়ীভাবে কোথাও সংরক্ষণ করতে আপনাকে নিজের পরিবর্তন করতে হবে। আপনি git stashতাদের সংরক্ষণ করতে ব্যবহার করতে পারেন ; এটি এর জন্য ডিজাইন করা জিনিসগুলির মধ্যে একটি। নোট করুন git stash saveবা git stash pushপ্রকৃত অর্থ "সমস্ত পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ করুন, তবে কোনও শাখায় নেই, তবে এখন আমি যেখানে আছি সেখান থেকে সেগুলি সরিয়ে ফেলুন।" এটি স্যুইচ করা সম্ভব করে তোলে: আপনার এখন কোনও অগ্রগতি পরিবর্তন নেই। আপনি তারপরে git stash applyস্যুইচ করার পরে এগুলি করতে পারেন ।

সাইডবার: git stash saveএটি পুরানো বাক্য গঠন; git stash pushআর্গুমেন্টগুলির সাথে কিছু সমস্যা সমাধানের জন্য git stashএবং নতুন বিকল্পগুলির অনুমতি দেওয়ার জন্য , গিট সংস্করণ 2.13 এ চালু হয়েছিল । উভয় একই জিনিস করেন, যখন মৌলিক উপায়ে ব্যবহৃত হয়।

আপনি এখানে পড়া বন্ধ করতে পারেন, আপনি যদি চান!

গিট যদি আপনাকে স্যুইচ করতে না দেয়, আপনার ইতিমধ্যে একটি প্রতিকার রয়েছে: ব্যবহার git stashবা git commit; বা, যদি আপনার পরিবর্তনগুলি পুনরায় তৈরির জন্য তুচ্ছ হয় তবে git checkout -fতা জোর করে ব্যবহার করুন । আপনি কিছু পরিবর্তন শুরু করলেও গিট আপনাকে কখন ছাড় দেবে এ বিষয়ে এই উত্তরটি git checkout branch2। কেন এটি কখনও কখনও কাজ করে , এবং অন্যান্য সময় নয়?

এখানে নিয়মটি এক উপায়ে সহজ, এবং জটিল / শক্ত-তে-অন্যভাবে ব্যাখ্যা:

আপনি যদি কার্য-বৃক্ষের অনির্দিষ্ট পরিবর্তনের সাথে শাখাগুলি স্যুইচ করতে পারেন এবং যদি কেবল তখনই বলা হয় যে স্যুইচিংয়ের জন্য এই পরিবর্তনগুলি ক্লোবার্বিংয়ের প্রয়োজন হয় না।

এটি — এবং দয়া করে মনে রাখবেন যে এটি এখনও সরলীকৃত; স্টেজড git addএস, git rmএস এবং এর সাথে কিছু অতিরিক্ত-জটিল কোণ রয়েছে ose মনে করুন আপনি চালু আছেন branch1। একটি git checkout branch2এই কাজ করতে হবে:

• প্রত্যেক যে ফাইলটি জন্য হয় মধ্যে branch1এবং না মধ্যে branch2, ¹ সরানোর যে ফাইল।
• প্রত্যেক যে ফাইলটি জন্য হয় মধ্যে branch2এবং না মধ্যে branch1, যে ফাইল (উপযুক্ত বিষয়বস্তু সহ) তৈরি করুন।
• উভয় শাখায় থাকা প্রতিটি ফাইলের জন্য, যদি সংস্করণটি branch2আলাদা হয় তবে কার্যক্ষম গাছের সংস্করণটি আপডেট করুন।

এই পদক্ষেপের প্রতিটি আপনার কাজের গাছের মধ্যে কিছু আঁকড়ে যেতে পারে:

• ওয়ার্ক-ট্রিতে থাকা সংস্করণটি প্রতিশ্রুতিবদ্ধ সংস্করণটির একই রকম হলে কোনও ফাইল সরানো "নিরাপদ" branch1; যদি আপনি পরিবর্তন করেন তবে এটি "অনিরাপদ"।
• এটি উপস্থিত না থাকলে যেভাবে ফাইল উপস্থিত হয় সেটিকে তৈরি branch2করা "নিরাপদ"। ² এটি "অনিরাপদ" যদি এটি এখন বিদ্যমান থাকে তবে এতে "ভুল" বিষয়বস্তু রয়েছে।
• এবং অবশ্যই, যদি ওয়ার্ক-ট্রি সংস্করণটি ইতিমধ্যে প্রতিশ্রুতিবদ্ধ থাকে তবে কোনও ফাইলের ওয়ার্ক-ট্রি সংস্করণকে আলাদা সংস্করণ দিয়ে প্রতিস্থাপন করা "নিরাপদ" branch1।

একটি নতুন শাখা ( git checkout -b newbranch) তৈরি করা সর্বদা "নিরাপদ" হিসাবে বিবেচিত হয় : এই প্রক্রিয়াটির অংশ হিসাবে কোনও ফাইল যুক্ত বৃত্তে যুক্ত করা, অপসারণ করা বা পরিবর্তন করা হবে না এবং সূচি / স্টেজিং-এরিয়াও অস্পৃশ্য। (ক্যাভেট: নতুন শাখার প্রারম্ভিক বিন্দুটি পরিবর্তন না করেই নতুন শাখা তৈরি করার সময় এটি নিরাপদ; তবে আপনি যদি আরও একটি যুক্তি যুক্ত করেন, উদাহরণস্বরূপ, এতে স্থান git checkout -b newbranch different-start-pointপরিবর্তন করতে পারে তবে জিনিসগুলিকে পরিবর্তন করতে হতে পারে different-start-pointit গিটটি যথারীতি চেকআউট সুরক্ষা বিধি প্রয়োগ করবে) ।)

---

¹ এটির জন্য আমাদের একটি শাখায় ফাইল থাকার অর্থ কী তা আমরা সংজ্ঞায়িত করতে পারি যার ফলস্বরূপ শাখা শব্দের শব্দটি সঠিকভাবে সংজ্ঞা দেওয়া দরকার requires (আরো দেখুন ঠিক কি আমরা "শাখা" দ্বারা কি বোঝাতে চেয়েছেন? ) এখানে, একটা কাজ যা আমি গড় যা কমিট শাখা-নাম সমাধান করা: একটি ফাইল যার পথ হল মধ্যে যদি একটি হ্যাশ উৎপন্ন হয়। পরিবর্তে ত্রুটি বার্তা পেলে সেই ফাইলটি নেই in এই নির্দিষ্ট প্রশ্নের উত্তর দেওয়ার সময় আপনার সূচক বা কাজের গাছের পথে অস্তিত্ব প্রাসঙ্গিক নয়। সুতরাং, এখানে গোপনীয় প্রতিটি ফলাফল পরীক্ষা করা হয়P branch1git rev-parse branch1:Pbranch1Pgit rev-parsebranch-name:path। এটি হয় ব্যর্থ হয় কারণ ফাইলটি সর্বাধিক একটি শাখায় "ইন" থাকে বা আমাদের দুটি হ্যাশ আইডি দেয়। দুটি হ্যাশ আইডি যদি একই হয় তবে ফাইলটি দুটি শাখায় একই the কোন পরিবর্তন প্রয়োজন হয় না। যদি হ্যাশ আইডি পৃথক হয় তবে ফাইলটি দুটি শাখায় আলাদা এবং শাখাগুলিতে স্যুইচ করতে অবশ্যই পরিবর্তন করতে হবে।

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

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

---

পরিবর্তনগুলি মঞ্চস্থ করা হয় বা স্টেস্টেড না হওয়া থেকে কী আসে যায়?

হ্যাঁ, কিছু উপায়ে বিশেষত, আপনি একটি পরিবর্তন মঞ্চ করতে পারেন, তারপরে ওয়ার্ক ট্রি ফাইলটি "ডি-মডিফিকেশন" করতে পারেন। এখানে দুটি শাখায় একটি ফাইল রয়েছে, যা এর চেয়ে আলাদা branch1এবং branch2:

$ git show branch1:inboth
this file is in both branches
$ git show branch2:inboth
this file is in both branches
but it has more stuff in branch2 now
$ git checkout branch1
Switched to branch 'branch1'
$ echo 'but it has more stuff in branch2 now' >> inboth

এই মুহুর্তে, কাজ গাছ ফাইল inbothএক সাথে মিলে যায় branch2, যদিও আমারা আছি branch1। এই পরিবর্তনটি প্রতিশ্রুতিবদ্ধ হওয়ার জন্য মঞ্চস্থ করা হয়নি, যা git status --shortএখানে এটি প্রদর্শন করে:

$ git status --short
 M inboth

স্পেস-তৎকালীন এম মানে "পরিবর্তিত তবে মঞ্চস্থ নয়" (বা আরও স্পষ্টভাবে বলা যায়, ওয়ার্কিং-ট্রি কপি স্টেজড / ইনডেক্স কপির চেয়ে আলাদা) dif

$ git checkout branch2
error: Your local changes ...

ঠিক আছে, এখন আমরা ওয়ার্কিং-ট্রি কপিটি মঞ্চ করি যা আমরা ইতিমধ্যে জানি এটি অনুলিপিটির সাথেও মেলে branch2।

$ git add inboth
$ git status --short
M  inboth
$ git checkout branch2
Switched to branch 'branch2'

এখানে মঞ্চযুক্ত এবং কাজের উভয় অনুলিপি যা ছিল তা মিলেছে branch2তাই চেকআউটটি অনুমোদিত হয়েছিল।

আসুন আরেকটি পদক্ষেপ চেষ্টা করুন:

$ git checkout branch1
Switched to branch 'branch1'
$ cat inboth
this file is in both branches

আমি যে পরিবর্তনটি করেছি তা এখন স্টেজিং অঞ্চল থেকে হারিয়ে গেছে (কারণ চেকআউটটি মঞ্চের মধ্য দিয়ে লিখেছে)। এটি কর্নারের কিছুটা কেস। পরিবর্তনটি যায় নি, তবে আমি এটি যে মঞ্চস্থ করেছিলাম তা শেষ হয়ে যায়।

আসুন ফাইলটির তৃতীয় বৈকল্পটি মঞ্চ করি, যা কোনও শাখা-অনুলিপি থেকে আলাদা, তারপরে বর্তমান শাখার সংস্করণটির সাথে মেলে কাজের কপিটি সেট করুন:

$ echo 'staged version different from all' > inboth
$ git add inboth
$ git show branch1:inboth > inboth
$ git status --short
MM inboth

দুই Mগুলি এখানে বলতে চাইছেন: থেকে ফাইল পৃথক মঞ্চস্থ HEADফাইল, এবং , থেকে কাজ-ট্রি ফাইল পৃথক ফাইল মঞ্চস্থ করেছিল। ওয়ার্কিং-ট্রি সংস্করণটি branch1(ওরফে HEAD) সংস্করণের সাথে মেলে :

$ git diff HEAD
$

তবে git checkoutচেকআউটটি অনুমতি দেবে না:

$ git checkout branch2
error: Your local changes ...

আসুন branch2সংস্করণটি কার্যক্ষম সংস্করণ হিসাবে সেট করুন :

$ git show branch2:inboth > inboth
$ git status --short
MM inboth
$ git diff HEAD
diff --git a/inboth b/inboth
index ecb07f7..aee20fb 100644
--- a/inboth
+++ b/inboth
@@ -1 +1,2 @@
 this file is in both branches
+but it has more stuff in branch2 now
$ git diff branch2 -- inboth
$ git checkout branch2
error: Your local changes ...

যদিও বর্তমানের কার্যকরী অনুলিপি একটির সাথে মিলে যায় branch2, মঞ্চযুক্ত ফাইলটি git checkoutহ'ল না, সুতরাং একটি সেই অনুলিপিটি হারাবে, এবং এটি git checkoutবাতিল হয়ে যায়।

প্রযুক্তিগত নোটগুলি - কেবলমাত্র উত্সাহী কৌতূহলের জন্য :-)

এই সমস্তগুলির অন্তর্নিহিত বাস্তবায়ন ব্যবস্থাটি হ'ল গিটের সূচক । সূচকটি, "স্টেজিং এরিয়া" নামে পরিচিত, এটিই আপনি পরবর্তী প্রতিশ্রুতিটি তৈরি করেন : এটি বর্তমান প্রতিশ্রুতি মেলাতে শুরু করে, অর্থাত্, আপনি এখন যা যা পরীক্ষা করেছেন, এবং তারপরে প্রতিবার আপনি যখন git addফাইল ফাইল করেন, আপনি সূচী সংস্করণটি প্রতিস্থাপন করেন আপনার কাজের গাছে যা আছে তা দিয়ে।

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

যখন আপনি চালাতে git checkout branch2, গীত কভার নীচে কি তুলনা হয় ডগা কমিট এর branch2যাই হোক না কেন উভয় বর্তমান কমিট এবং এখন সূচক হয়। এখন যা আছে তার সাথে মেলে এমন কোনও ফাইল, গিট একা থাকতে পারে। এগুলি সবই ছোঁয়াচে। কোন ফাইল উভয় একই করে , গীত পারেন এছাড়াও একা-এবং ছেড়ে এই বেশী আপনি শাখা সুইচ দিন আছে।

কমিট-স্যুইচিং সহ বেশিরভাগ গিট এই সূচকটির কারণে তুলনামূলকভাবে দ্রুত । সূচীতে আসলে যা আছে তা প্রতিটি ফাইলই নয়, বরং প্রতিটি ফাইলের হ্যাশ । ফাইলটির অনুলিপিটি গিটকে একটি ব্লব অবজেক্ট হিসাবে সংগ্রহস্থল হিসাবে সংরক্ষণ করা হয় । এটি একইভাবে যেমন ফাইলগুলিও কমিটে সংরক্ষণ করা হয়: কমিটগুলিতে আসলে ফাইল থাকে না , তারা কেবল প্রতিটি ফাইলের হ্যাশ আইডিতে গিটকে নিয়ে যায়। সুতরাং গিট হ্যাশ আইডিগুলির তুলনা করতে পারে - বর্তমানে 160-বিট-লম্বা স্ট্রিং X X এবং Y একই ফাইল আছে কিনা তা নির্ধারণ করতে। এটি তখন সেই সূচকগুলিতে হ্যাশ আইডিগুলির সাথে সেই হ্যাশ আইডিগুলির তুলনা করতে পারে।

এটি যা উপরের সমস্ত অডবোল কোণার ক্ষেত্রে নিয়ে যায়। আমাদের এক্স এবং ওয়াইয়ের সাথে প্রতিশ্রুতি রয়েছে যে উভয়েরই ফাইল রয়েছে path/to/name.txtএবং এর জন্য আমাদের একটি সূচক এন্ট্রি রয়েছে path/to/name.txt। তিনটিই হ্যাশ মেলাতে পারে। তাদের মধ্যে দুটি মিলছে এবং একটিও মিলছে না। তিনটিই হয়ত আলাদা। এবং, আমরা আরো থাকতে পারে another/file.txtযে শুধুমাত্র আছে এক্স বা শুধুমাত্র ওয়াই এবং বা ইনডেক্স এখন নয়। এই বিভিন্ন ক্ষেত্রে প্রত্যেকটির নিজস্ব পৃথক বিবেচনা প্রয়োজন : গিটের কি X থেকে Y এ স্যুইচ করতে কমিট থেকে সূচি থেকে ফাইলটি অনুলিপি করতে বা সূচি থেকে অপসারণ করা দরকার ? যদি তা হয়, এটিও করতে হবেওয়ার্ক-ট্রিতে ফাইলটি অনুলিপি করুন, বা এটি ওয়ার্ক-ট্রি থেকে সরান। এবং যদি এটি হয় তবে সূচি এবং কর্ম-গাছের সংস্করণগুলির প্রতিশ্রুতিবদ্ধ সংস্করণগুলির মধ্যে কমপক্ষে একটির সাথে আরও ভাল মিল থাকতে পারে; অন্যথায় গিট কিছু ডেটা ক্লবারবারিং করবে।

(এই সব জন্য সম্পূর্ণ নিয়ম না বর্ণনা করা হয় git checkoutডকুমেন্টেশন হিসাবে আপনি আশা করতে পারে, বরং ডকুমেন্টেশন, "দুই বৃক্ষ মার্জ" শীর্ষক ধারার অধীন ।)git read-tree

Comments

... এছাড়াও রয়েছে git checkout -m, যা আপনার ওয়ার্কট্রি এবং সূচি পরিবর্তনগুলিকে নতুন চেকআউটে রূপান্তর করে।

— jthill

এই দুর্দান্ত ব্যাখ্যার জন্য ধন্যবাদ! তবে সরকারী ডক্সে আমি কোথায় তথ্যটি পেতে পারি? নাকি এগুলি অসম্পূর্ণ? যদি তা হয় তবে গিটের জন্য অনুমোদনযোগ্য রেফারেন্স কী (আশা করি এর উত্স কোড ব্যতীত অন্য)?

— সর্বোচ্চ

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

— টেরিক

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

— নিউট্রিনো

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

— টোকর

Answer 2

আপনার দুটি পছন্দ আছে: আপনার পরিবর্তনগুলি স্ট্যাশ করুন:

git stash

তারপরে সেগুলি ফিরে পেতে:

git stash apply

বা আপনার পরিবর্তনগুলি একটি শাখায় রাখুন যাতে আপনি দূরবর্তী শাখাটি পেতে পারেন এবং তারপরে আপনার পরিবর্তনগুলিকে এতে মার্জ করতে পারেন। গিট সম্পর্কিত এটি সর্বশ্রেষ্ঠ বিষয়গুলির মধ্যে একটি: আপনি একটি শাখা তৈরি করতে পারেন, এটি প্রতিশ্রুতিবদ্ধ করতে পারেন, তারপরে আপনি যে শাখায় ছিলেন সেটিতে অন্য পরিবর্তন আনতে পারেন।

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

Comments

সঠিক আদেশ না git stash apply? এখানে ডক্স।

— থমাস 8

আমি যা খুঁজছিলাম, সাময়িকভাবে বিভিন্ন শাখায় স্যুইচ করতে, কিছু সন্ধান করতে এবং যে শাখায় আমি কাজ করছি তার একই অবস্থায় ফিরে আসার জন্য। থ্যাঙ্কস রব!

— নাইস্তার

হ্যাঁ, এটি করার সঠিক উপায়। আমি গৃহীত উত্তরের বিবরণটির প্রশংসা করি, তবে এটি তাদের প্রয়োজনের তুলনায় আরও শক্ত করে তুলেছে।

— মাইকেল লিওনার্ড

এছাড়াও, যদি আপনার কাছে স্ট্যাশ রাখার কোনও প্রয়োজন না থাকে তবে আপনি ব্যবহার করতে পারেন git stash popএবং যদি এটি সফলভাবে প্রয়োগ হয় তবে এটি আপনার তালিকা থেকে স্ট্যাশটিকে বাদ দেবে।

— মাইকেল লিওনার্ড

আরও ভাল ব্যবহার করুন git stash pop, যদি না আপনি আপনার রেপো ইতিহাসে

— স্ট্যাশগুলির

Answer 3

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

উদাহরণ:

$ echo 'hello world' > file.txt
$ git add file.txt
$ git commit -m "adding file.txt"

$ git checkout -b experiment
$ echo 'goodbye world' >> file.txt
$ git add file.txt
$ git commit -m "added text"
     # experiment now contains changes that master doesn't have
     # any future changes to this file will keep you from changing branches
     # until the changes are stashed or committed

$ echo "and we're back" >> file.txt  # making additional changes
$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
    file.txt
Please, commit your changes or stash them before you can switch branches.
Aborting

এটি ট্র্যাক করা ফাইলগুলির পাশাপাশি অচিহ্নযুক্ত ফাইলগুলির জন্য যায়। একটি আনরে্যাকড ফাইলের জন্য এখানে একটি উদাহরণ।

উদাহরণ:

$ git checkout -b experimental  # creates new branch 'experimental'
$ echo 'hello world' > file.txt
$ git add file.txt
$ git commit -m "added file.txt"

$ git checkout master # master does not have file.txt
$ echo 'goodbye world' > file.txt
$ git checkout experimental
error: The following untracked working tree files would be overwritten by checkout:
    file.txt
Please move or remove them before you can switch branches.
Aborting

পরিবর্তনগুলি করার সময় আপনি কেন শাখাগুলির মধ্যে চলাচল করতে চান তার একটি উত্তম উদাহরণ হ'ল আপনি যদি মাস্টার সম্পর্কে কিছু পরীক্ষা-নিরীক্ষা করছিলেন, তাদের প্রতিশ্রুতিবদ্ধ করতে চেয়েছিলেন, তবে এখনও মাস্টার না করার জন্য ...

$ echo 'experimental change' >> file.txt # change to existing tracked file
   # I want to save these, but not on master

$ git checkout -b experiment
M       file.txt
Switched to branch 'experiment'
$ git add file.txt
$ git commit -m "possible modification for file.txt"

Comments

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

— Xufeng

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

— গর্ডোলিও

Answer 4

সঠিক উত্তরটি হ'ল

git checkout -m origin/master

এটি আপনার স্থানীয় এমনকি অননুমোদিত পরিবর্তনের সাথে মূল উত্স শাখা থেকে পরিবর্তনগুলি মার্জ করে।

Answer 5

আপনি যদি চান না যে এই পরিবর্তনগুলি একেবারেই প্রতিশ্রুতিবদ্ধ হয় git reset --hard।

পরবর্তী আপনি চেয়েছিলেন শাখায় চেকআউট করতে পারেন, তবে মনে রাখবেন যে অনির্দিষ্ট পরিবর্তনগুলি হারাবে be