লিনাস টরভাল্ডস যখন গিটকে "কখনও কখনও" ফাইল ট্র্যাক করেন না তখন তার অর্থ কী?

Question

২০০ 2007 সালে গুগলে তার টেক টক চলাকালীন গিট কতগুলি ফাইল পরিচালনা করতে পারে জানতে চাইলে লিনাস টোরভাল্ডসের উদ্ধৃতি দিয়েছিলেন (৪৩:০৯):

… গিট আপনার সামগ্রী ট্র্যাক করে। এটি কখনও কোনও একক ফাইলকে ট্র্যাক করে না। আপনি গিতে কোনও ফাইল ট্র্যাক করতে পারবেন না। আপনি যা করতে পারেন তা হ'ল আপনি এমন একটি প্রকল্প ট্র্যাক করতে পারেন যার একটি একক ফাইল রয়েছে তবে আপনার প্রকল্পে যদি একটি একক ফাইল থাকে তবে অবশ্যই তা করুন এবং আপনি এটি করতে পারবেন, তবে আপনি যদি 10,000 টি ফাইল ট্র্যাক করেন তবে গিট কখনই সেগুলিকে স্বতন্ত্র ফাইল হিসাবে দেখেন না। গিট সবকিছুকে সম্পূর্ণ বিষয়বস্তু হিসাবে মনে করে। গিটের সমস্ত ইতিহাস পুরো প্রকল্পের ইতিহাসের উপর ভিত্তি করে ...

^{(প্রতিলিপি এখানে ।)}

তবুও, আপনি যখন গিট বইটিতে ডুব দিয়েছিলেন , প্রথমে আপনাকে বলা হয় যে গিটের কোনও ফাইল হয় হয় ট্র্যাক করা যায় বা ট্রেড করা যায় না । তদুপরি, এটি আমার কাছে পুরো গিট অভিজ্ঞতা ফাইল সংস্করণের দিকে এগিয়ে যাওয়ার মতো বলে মনে হচ্ছে। ব্যবহার git diffবা git statusআউটপুট যখন প্রতিটি ফাইল ভিত্তিতে উপস্থাপন করা হয়। ব্যবহার করার সময় git addআপনি প্রতি ফাইলের ভিত্তিতেও চয়ন করতে পারেন। এমনকি আপনি ফাইলের ভিত্তিতে ইতিহাস পর্যালোচনা করতে পারেন এবং দ্রুত বজ্রপাত করছেন।

এই বিবৃতিটি কীভাবে ব্যাখ্যা করা উচিত? ফাইল ট্র্যাকিংয়ের ক্ষেত্রে গিট কীভাবে সিভিএসের মতো অন্যান্য উত্স নিয়ন্ত্রণ সিস্টেমের থেকে আলাদা?

Comments

reddit.com/r/git/comments/5xmrkv/ what_is_a_snapshot_in_git - "আপনি এই মুহুর্তে যেখানে রয়েছেন, আমি সন্দেহ করি তার চেয়ে বেশি গুরুত্বপূর্ণ যেটি বুঝতে হবে যে গিট কীভাবে ব্যবহারকারীদের কাছে ফাইল উপস্থাপন করে এবং এটি কীভাবে অভ্যন্তরীণভাবে তাদের সাথে ডিল করে । ব্যবহারকারীর কাছে উপস্থাপিত হিসাবে, একটি স্ন্যাপশটে সম্পূর্ণ ফাইল রয়েছে, কেবল ভিন্নতা নয় But (এটি তীব্র বিপরীত, উদাহরণস্বরূপ।

— সাব্ভারশন

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

— এলিয়ট ফ্রিচ

পছন্দ করেছেন আপনার বিবরণ যেমন ডার্কগুলি কি করে তার নিকটবর্তী । গিট স্ন্যাপশট সংরক্ষণ করে, চেঞ্জসেটগুলি নয়।

— মেলপোমেন

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

— এলিপেকে

সম্পর্কিত: রিন্ডাল শোয়ার্জ'স লিনাসের টক অব টক ' (একটি গুগল টেক আলাপও) - "... গিট আসলে কী, ... লিনাস বলেছিলেন গিট কী নয়"।

— পিটার মর্টেনসেন

Answer 1

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

অন্যদিকে, গিট পুরো প্রকল্পের রাজ্যের স্ন্যাপশট নেয়। ফাইলগুলি স্বতন্ত্রভাবে ট্র্যাক করা এবং সংস্করণিত হয় না; সংগ্রহস্থলের একটি সংশোধন একটি ফাইল নয় পুরো প্রকল্পের একটি রাষ্ট্রকে বোঝায়।

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

Comments

আপনি যুক্ত করতে পারেন যে এই কারণেই সিভিএস এবং সাবভার্সনে আপনি $Id$কোনও ফাইলের মতো ট্যাগ ব্যবহার করতে পারেন । গিটে একই কাজ করে না, কারণ নকশা ভিন্ন।

— অঙ্কুরিত

এবং বিষয়বস্তু কোনও ফাইলের সাথে আবদ্ধ নয় যেমনটি আপনি আশা করবেন। এক ফাইলের কোডের ৮০% অন্য ফাইলটিতে নিয়ে যাওয়ার চেষ্টা করুন। আপনি বিদ্যমান ফাইলগুলিতে সবেমাত্র কোড সরিয়ে নিয়ে গেলেও গিট স্বয়ংক্রিয়ভাবে একটি ফাইলের সরানো + ২০% পরিবর্তন সনাক্ত করে।

— allo

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

— ইজকাটা

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

— জেরেমি

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

— অ্যালভিন থম্পসন

Answer 2

আমি ব্রায়ান মি এর সাথে একমত কার্লসনের উত্তর : লিনাস প্রকৃতপক্ষে ফাইল-ভিত্তিক এবং প্রতিশ্রুতি-ভিত্তিক সংস্করণ নিয়ন্ত্রণ সিস্টেমের মধ্যে পার্থক্যযুক্ত। তবে আমি মনে করি এর চেয়ে আরও কিছু আছে is

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

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

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

আপনি যখন গিটকে এটি ব্যবহার করে কোনও ফাইলের ইতিহাস দেখানোর জন্য বলেন:

git log [--follow] [starting-point] [--] path/to/file

কি গীত সত্যিই করছে হাঁটা হয় কমিট ইতিহাস, যা শুধুমাত্র ইতিহাস গীত হয়েছে, কিন্তু না দেখাচ্ছে এইসব করে কোনো যদি না:

• প্রতিশ্রুতিবদ্ধতা হ'ল একটি বিহীন অঙ্গীকার, এবং
• সেই প্রতিশ্রুতির পিতামাতার কাছেও ফাইল থাকে তবে পিতামাতার মধ্যে থাকা বিষয়বস্তু আলাদা হয় বা কমিটের পিতামাতার কাছে ফাইলটি থাকে না

(তবে এই শর্তগুলির কয়েকটি অতিরিক্ত git logবিকল্পের মাধ্যমে সংশোধন করা যেতে পারে এবং ইতিহাসের সরলীকরণ নামে পার্শ্ব প্রতিক্রিয়া বর্ণনা করা খুব কঠিন যা গিটকে ইতিহাস থেকে সম্পূর্ণ কিছুটা কমিটকে পুরোপুরি চলতে দেয় না) it আপনি যে ফাইল ইতিহাসটি দেখছেন সেটি হ'ল সংগ্রহস্থলটিতে কিছুটা অর্থে নেই: পরিবর্তে, এটি কেবল আসল ইতিহাসের একটি সিনথেটিক উপসেট। আপনি বিভিন্ন git logবিকল্প ব্যবহার করলে আপনি একটি ভিন্ন "ফাইলের ইতিহাস" পাবেন !

Comments

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

— ওয়েস টলেম্যান

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

— টের্ক

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

— আমায়া

@ টোরেক আপনার বইয়ের লিঙ্কটির জন্য ধন্যবাদ, আমি এর মতো আর কিছু দেখিনি।

— gnarledRoot 13

Answer 3

বিভ্রান্তিকর বিটটি এখানে:

গিট কখনও এগুলিকে স্বতন্ত্র ফাইল হিসাবে দেখেনি। গিট সবকিছুকে সম্পূর্ণ বিষয়বস্তু হিসাবে মনে করে।

গিট প্রায়শই নিজস্ব রেপোতে বস্তুর জায়গায় 160 বিট হ্যাশ ব্যবহার করে। ফাইলগুলির একটি গাছ হ'ল মূলত প্রত্যেকটির সামগ্রীর সাথে যুক্ত নামের এবং হ্যাশগুলির একটি তালিকা (আরও কিছু মেটাডেটা)।

তবে 160 বিট হ্যাশ সামগ্রীটিকে অনন্যভাবে সনাক্ত করে (গিট ডাটাবেসের মহাবিশ্বের মধ্যে)। সুতরাং সামগ্রী হিসাবে হ্যাশযুক্ত একটি গাছ তার রাজ্যের বিষয়বস্তু অন্তর্ভুক্ত করে ।

আপনি যদি কোনও ফাইলের সামগ্রীর স্থিতি পরিবর্তন করেন তবে এর হ্যাশ পরিবর্তন হয়। তবে যদি এর হ্যাশ পরিবর্তন হয় তবে ফাইলের নামের সাথে যুক্ত হ্যাশও পরিবর্তিত হয়। যা পরিবর্তিতভাবে "ডিরেক্টরি ট্রি" এর হ্যাশ পরিবর্তন করে।

যখন একটি গিট ডাটাবেস ডিরেক্টরি ট্রি সংরক্ষণ করে, সেই ডিরেক্টরি ট্রিটি সমস্ত উপ-ডিরেক্টরি এবং এর মধ্যে থাকা সমস্ত ফাইলের সমস্ত সামগ্রী অন্তর্ভুক্ত করে ।

এটি একটি গাছের কাঠামোয় (অপরিবর্তনীয়, পুনরায় ব্যবহারযোগ্য) ব্লবস বা অন্যান্য গাছের পয়েন্টার সহ সংগঠিত, তবে যৌক্তিকভাবে এটি সম্পূর্ণ গাছের সম্পূর্ণ সামগ্রীর একক স্ন্যাপশট। উপস্থাপনা Git ডাটাবেসের মধ্যে ফ্ল্যাট তথ্য বিষয়বস্তু নয়, কিন্তু কথাটি এটা তার ডেটা, অন্য কিছু নয় সব।

যদি আপনি গাছটিকে একটি ফাইল সিস্টেমে সিরিয়ালাইজ করে থাকেন, সমস্ত .git ফোল্ডার মুছে ফেলেছেন এবং গাছটিকে তার ডাটাবেসে ফিরিয়ে আনতে গিটকে বলেছেন, আপনি ডাটাবেসে কোনও কিছুই যুক্ত করবেন না - উপাদানটি ইতিমধ্যে উপস্থিত থাকবে।

গিটের হ্যাশগুলি অপরিবর্তনীয় ডেটা হিসাবে রেফারেন্স গণনা পয়েন্টার হিসাবে ভাবতে সহায়তা করতে পারে।

যদি আপনি তার চারপাশে একটি অ্যাপ্লিকেশন তৈরি করেন তবে একটি নথি হ'ল পৃষ্ঠাগুলির একগুচ্ছ, যার স্তর রয়েছে, যার গোষ্ঠী রয়েছে, যার অবজেক্ট রয়েছে।

আপনি যখন কোনও বস্তু পরিবর্তন করতে চান, আপনাকে এটির জন্য একটি সম্পূর্ণ নতুন গ্রুপ তৈরি করতে হবে। আপনি যদি একটি গোষ্ঠী পরিবর্তন করতে চান তবে আপনাকে একটি নতুন স্তর তৈরি করতে হবে, যার জন্য একটি নতুন পৃষ্ঠা প্রয়োজন, যার জন্য একটি নতুন ডকুমেন্ট দরকার।

যতবারই আপনি একটি একক বস্তু পরিবর্তন করেন, এটি একটি নতুন দস্তাবেজ তৈরি করে। পুরানো নথিটি অবিরত রয়েছে। নতুন এবং পুরানো নথিতে তাদের বেশিরভাগ সামগ্রী ভাগ করা আছে - তাদের একই পৃষ্ঠা রয়েছে (1 বাদে)। এই পৃষ্ঠায় একই স্তর রয়েছে (1 বাদে)। এই স্তরটির একই গ্রুপ রয়েছে (1 বাদে)। এই গোষ্ঠীর একই জিনিস রয়েছে (1 বাদে)।

এবং একইভাবে, আমি যুক্তিযুক্তভাবে একটি অনুলিপি বলতে চাইছি, তবে বাস্তবায়ন অনুসারে এটি একই অপরিবর্তনীয় অবজেক্টের কাছে অন্য একটি রেফারেন্স গণনা করা।

গিট রেপো অনেকটা এরকম।

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

এই পিতামাতাদের পরিবর্তনগুলিতে সমস্ত পথে ফিরে আসা তাদের পিতামাতার পরিবর্তনগুলি রয়েছে।

ইতিহাস রয়েছে এমন গিট রেপোর অংশটি সেই পরিবর্তনগুলির শৃঙ্খলা। এই ডিরেক্টরিটি "ডিরেক্টরি" গাছের উপরে একটি স্তরকে পরিবর্তিত করে - একটি "ডিরেক্টরি" গাছ থেকে, আপনি স্বতন্ত্রভাবে কোনও পরিবর্তন সেট এবং পরিবর্তনের শৃঙ্খলে যেতে পারবেন না।

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

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

সুতরাং গিট একটি "ফাইলের ইতিহাস" একসাথে প্যাচওয়ার্ক করতে পারে।

তবে এই ফাইলের ইতিহাস ফাইলটির একটি সংস্করণ থেকে অন্য সংস্করণে কোনও লিঙ্ক থেকে নয়, "পুরো চেঞ্জসেট" এর দক্ষ পার্সিং থেকে আসে।

Answer 4

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

এখন এটি ভান্ডার। গিটের একটি কার্যনির্বাহী গাছও রয়েছে এবং এই কার্যক্ষম গাছটিতে ট্র্যাকড এবং অনিবন্ধিত ফাইল রয়েছে। কেবলমাত্র ট্র্যাক করা ফাইলগুলি সূচীতে রেকর্ড করা হয় (মঞ্চ অঞ্চল? ক্যাশে?) এবং কেবল সেখানে যা ট্র্যাক করা হয় তা এটিকে সংগ্রহস্থলে পরিণত করে।

সূচকটি ফাইল-ভিত্তিক এবং এটিকে ম্যানিপুলেট করার জন্য কিছু ফাইল-ওরিয়েন্টেড কমান্ড রয়েছে। তবে সংগ্রহস্থলে যা শেষ হয় তা কেবল ফাইল ট্রি স্ন্যাপশট এবং সম্পর্কিত ব্লব ডেটা এবং কমিটের পূর্বপুরুষদের আকারে কমিট করে।

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

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

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

Answer 5

গিট কোনও ফাইল সরাসরি ট্র্যাক করে না, তবে সংগ্রহশালার স্ন্যাপশটগুলি ট্র্যাক করে এবং এই স্ন্যাপশটগুলিতে ফাইল থাকে।

এটি দেখার জন্য এখানে একটি উপায়।

অন্যান্য সংস্করণ নিয়ন্ত্রণ সিস্টেমে (এসভিএন, রেশনাল ক্লিয়ার কেস), আপনি কোনও ফাইলের উপর ডান ক্লিক করতে পারেন এবং এর পরিবর্তনের ইতিহাস পেতে পারেন ।

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

Comments

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

— জো লি-ময়েত

আপনার লিঙ্ক করা প্রশ্নের প্রথম কয়েকটি উত্তর আমি এড়িয়ে গিয়েছিলাম এবং সেগুলির সমস্তগুলি ব্যবহার করে git logবা তার উপরে নির্মিত কিছু প্রোগ্রাম (বা একইরকম কিছু উপন্যাস)। তবে সেখানে বিভিন্ন উপায়ে প্রচুর পরিমাণে থাকার পরেও জো যা বলেছিল এটি শাখার ইতিহাস দেখানোর ক্ষেত্রেও সত্য। (এছাড়াও git log -p <file>এটি অন্তর্নির্মিত এবং ঠিক এটি করে)

— ভু

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

— আরতুর বিসিয়াদভস্কি

Answer 6

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

এটি সর্বদা ক্ষেত্রে ছিল না, এবং কেবল গিট 1.4 (মে 2006) 443f833 কমিটমেন্ট সহ সেই "ট্র্যাকিং সামগ্রী" নীতিটি প্রয়োগ করেছিল :

গিটের স্থিতি: খালি ডিরেক্টরিগুলি এড়িয়ে যান এবং সমস্ত চিহ্নবিহীন ফাইলগুলি দেখানোর জন্য অ্যাড করুন

ডিফল্টরূপে, আমরা --others --directoryতাদের বিষয়বস্তু ছাড়াই (ব্যবহারকারীর দৃষ্টি আকর্ষণ করতে) আগ্রহী ডিরেক্টরিগুলি (ব্যবহারকারীর দৃষ্টি আকর্ষণ করতে) দেখানোর জন্য ব্যবহার করি ।
খালি ডিরেক্টরি দেখানো অর্থহীন নয়, সুতরাং --no-empty-directoryযখন আমরা এটি করি তখন পাস করুন ।

-u(বা --untracked) প্রদান করা এই অনাবন্ধককে অক্ষম করে যাতে ব্যবহারকারীকে সমস্ত অনার্যাকড ফাইলগুলি পেতে দেয়।

এটি বছরের পর বছর জানুয়ারীতে প্রতিধ্বনিত হয়েছিল। ২০১১ সালে 8fe533 , গিট ভি 1.7.4 দিয়ে:

এটি সাধারণ ইউআই দর্শনের সাথে সামঞ্জস্য রেখে: গিটটি সামগ্রী খালি করে, খালি ডিরেক্টরিগুলি নয়।

এরই মধ্যে, গিট 1.4.3 (সেপ্টেম্বর 2006) এর সাথে, গিট 2074cb0 কমিট করে , খালি খালি ফোল্ডারে অবরুদ্ধ লিখিত সামগ্রী সীমাবদ্ধ করতে শুরু করে :

এটি সম্পূর্ণরূপে চিহ্নবিহীন ডিরেক্টরিগুলির বিষয়বস্তু তালিকাভুক্ত করা উচিত নয়, তবে কেবলমাত্র সেই ডিরেক্টরিটির নাম (প্লাস একটি ট্রেলিং ' /')।

কন্টেন্ট ট্র্যাকিং হ'ল গিটকে খুব তাড়াতাড়ি দোষ দেওয়া হয়েছিল, (গিট 1.4.4, অক্টোবর 2006, গিটকে সিই 7 এফ 24 কমিট করুন ) আরও পারফরম্যান্স হতে পারে:

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

এটি (ট্র্যাকিংয়ের বিষয়বস্তু) গিট এপিআই-তে গিট অ্যাডও দেয় যা গিট 1.5.0.0 (ডিসেম্বর 2006, কমিট 366bfcb ) সহ

সূচকটিতে প্রথম শ্রেণীর ব্যবহারকারী বান্ধব ইন্টারফেসকে 'গিট অ্যাড' করুন

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

প্রতিশ্রুতিবদ্ধ কোন সামগ্রী অবশ্যই একসাথে যুক্ত করা উচিত।
সেই সামগ্রীটি নতুন ফাইলগুলি থেকে আসে বা পরিবর্তিত ফাইলগুলি বিবেচনা করে না।
গিট-অ্যাড সহ, বা গিট-কমিট সরবরাহ করে আপনাকে কেবল এটি "যুক্ত" করতে হবে-a (কেবলমাত্র ইতিমধ্যে পরিচিত ফাইলগুলির জন্য) আপনাকে কেবল ।

অর্থাৎ যা কিছু তোমরা তৈরি git add --interactiveসম্ভব একই গীত 1.5.0 সঙ্গে ( 5cde71d কমিট )

নির্বাচন করার পরে বিষয়বস্তু পর্যায়ক্রমে খালি লাইন দিয়ে উত্তর দিন সূচীতে নির্বাচিত পাথের জন্য কাজ করা গাছের ফাইলগুলির ।

এই কারণেই, ডিরেক্টরি থেকে সমস্ত বিষয়বস্তু বারবার মুছে ফেলার জন্য আপনাকে -rকেবল ডিরেক্টরি নাম হিসাবে <path>(এখনও গিট 1.5.0.0, 9f95069 কমিট ) হিসাবে পাস করতে হবে না ।

ফাইলের পরিবর্তে ফাইলের বিষয়বস্তু দেখানোই যা বর্ণনা করা হয়েছে তার মতো মার্জ দৃশ্যের মঞ্জুরি দেয় কমিট 1de70db (গিট ভি 2.18.0-আরসি0, এপ্রিল 2018) মেশানো দৃশ্যের মঞ্জুরি দেয় what

একটি নাম পরিবর্তন / সংঘাত যোগ করার সাথে নিম্নলিখিত সংযুক্তিটি বিবেচনা করুন:

• পাশ A: সংশোধন করুন foo , সম্পর্কযুক্ত নয় latedbar
• পাশ বি: নতুন নামকরণ foo->bar (তবে মোড বা সামগ্রীগুলি পরিবর্তন করবেন না)

এই ক্ষেত্রে, মূল foo, A এর foo এবং B এর ত্রি-মুখী সংহতির barফলস্বরূপ A এর barএকই মোড / সামগ্রীগুলির পছন্দসই পথের নাম হবে foo।
সুতরাং, এ ফাইলটির জন্য সঠিক মোড এবং বিষয়বস্তু ছিল এবং এটির সঠিক নামটি উপস্থিত ছিল (যথা bar:)।

প্রতিশ্রুতিবদ্ধ 37b65ce , গিট ভি 2.21.0-আরসি0, ডিসেম্বর, 2018, সম্প্রতি সংঘর্ষ বিরোধী সমাধানগুলির সংশোধন হয়েছে।
এবং প্রতিশ্রুতিবদ্ধ bbafc9c ফার্মার নাম / পুনর্নামকরণ (2to1) দ্বন্দ্বগুলির জন্য পরিচালনা পরিচালনা করার মাধ্যমে ফাইলের বিষয়বস্তু বিবেচনার গুরুত্বকে চিত্রিত করে :

• পরিবর্তে ফাইল সংরক্ষণ collide_path~HEADএবংcollide_path~MERGE ফাইলগুলি দ্বি-মুখী মার্জ এবং রেকর্ড করা হয় collide_path।
• সূচকের নাম পরিবর্তিত অংশে বিদ্যমান নাম পরিবর্তিত ফাইলটির সংস্করণ রেকর্ড করার পরিবর্তে (এভাবে নামটির পরিবর্তে ইতিহাসের পাশের ফাইলটিতে যে কোনও পরিবর্তন করা হয়েছে তা উপেক্ষা করা), আমরা নতুন নামকরণে একটি ত্রি-মুখী বিষয়বস্তু একীকরণ করি পাথ, তারপরে এটি স্টেজ 2 বা 3 পর্যায়ে সংরক্ষণ করুন।
• নোট করুন যেহেতু প্রতিটি নাম পরিবর্তনের জন্য সামগ্রীর মার্জটিতে দ্বন্দ্ব থাকতে পারে এবং তারপরে আমাদের দুটি নামকরণকৃত ফাইল একত্রীকরণ করতে হবে, তাই আমরা নেস্টেড সংঘাতের চিহ্নিতকারীদের সাথে শেষ করতে পারি।