গিটের দ্বি-পর্যায়ের কমিট প্রক্রিয়া (মঞ্চায়ন) এর সুবিধা কী?

Question

আমি গিট শিখছি এবং আমি লক্ষ্য করেছি যে এটিতে দ্বি-পদক্ষেপের প্রতিশ্রুতিবদ্ধ প্রক্রিয়া রয়েছে:

1. git add <files>
2. git commit

প্রথম পদক্ষেপটি "স্টেজেজিং এরিয়া" বা "সূচক" নামে পরিচিত এর মধ্যে সংশোধন করে places

আমি যে বিষয়ে আগ্রহী তা হ'ল কেন এই নকশার সিদ্ধান্ত নেওয়া হল এবং এর সুবিধাগুলি কী?

এছাড়াও, গিট ব্যবহারকারী হিসাবে আপনি কি এটি করেন বা কেবল ব্যবহার করেন git commit -a?

আমি বিজেআর (বাজার) থেকে আসার সাথে সাথে এটি জিজ্ঞাসা করব যার এই বৈশিষ্ট্যটি নেই।

Comments

জিজ্ঞাসা করার জন্য +1। আমি টরটোইজ এসভিএন ব্যবহার করি যা একই পদ্ধতির এবং আমি কেন বুঝতে পারি নি।

— DPD

মঞ্চ অঞ্চলটি যে অস্বাভাবিক নয়। সমতুল্য, বলুন, টিএফএস চেক ইন করার আগে কোনও ফাইলের পাশের বাক্সটি চেক বা আনচেক করছে Only কেবলমাত্র পরীক্ষিত ফাইলগুলি প্রতিশ্রুতিবদ্ধ। গিটের সাথে পার্থক্য হ'ল আপনি যদি ব্যবহার করেন git add -pতবে একই ফাইলের অন্য টুকরোটি প্রতিশ্রুতি না দেওয়ার সময় আপনি কোনও ফাইলের এক টুকরো কমিট করতে বেছে নিতে পারেন ।

— কিরালেসা

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

— ভিভারকে

এই প্রশ্নের আসলে ইতিমধ্যে বললেন, কিন্তু এখানেও এক ভাল ব্যাখ্যা হল: stackoverflow.com/questions/4878358/...

— guitar_freak

ভুলবেন না git statusএবং সম্ভবত git push। গিট সম্পর্কিত সমস্ত

— হাইপগুলির

Answer 1

কাজ আলাদা ভাতে বিভক্ত করুন। আপনি সম্ভবত একাধিকবার একটি একক-লাইন ফিক্স লেখার জন্য একটি ফাইল খোলেন, কিন্তু একই সময়ে আপনি চিহ্নিত করেছেন যে ফর্ম্যাটিংটি ভুল ছিল, কিছু ডকুমেন্টেশন উন্নত করা যেতে পারে, বা কিছু অন্য সম্পর্কযুক্ত সমাধান। অন্যান্য আরসিএস এর সাথে আপনাকে এটি লিখতে বা স্মৃতিতে প্রতিশ্রুতিবদ্ধ করতে হবে, আপনি যে ফিক্সটি এসেছিলেন তা শেষ করুন, এটি প্রতিশ্রুতিবদ্ধ করুন এবং তারপরে অন্য জিনিসগুলি ঠিক করতে ফিরে আসুন (বা সম্পর্কযুক্ত জিনিস দিয়ে বল-অফ-কাদার প্রতিশ্রুতি তৈরি করুন) । গিটের সাহায্যে আপনি কেবল একবারে এটি ঠিক করে ফেলুন এবং স্টেজ + একক লাইনটি আলাদাভাবে প্রতিশ্রুতিবদ্ধ করুন git add -iবা দিয়ে git-gui।

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

Comments

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

— থোমাস্রুটার

"অন্যান্য আরসিএসেস" সম্পর্কিত, এটি অগত্যা সত্য নয়। আসলে, আপনি প্যাচগুলি ব্যবহার করে মার্চুরিয়ালে সেই একই কার্যকারিতা অর্জন করতে পারেন ।

— লুসিও পাইভা

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

— alpha_989

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

— alpha_989

@ থোমাস্রুটটার, আপনার বক্তব্য থেকে মনে হচ্ছে আপনি পরামর্শ দিচ্ছেন যে মঞ্চ অঞ্চলটি "ম্যানুয়াল পূর্বাবস্থায় বিন্দু" তৈরি করে। অবিচ্ছিন্ন-পূর্বাবস্থায় ভিআইএম-এ আপনি খুব নির্ভরযোগ্যভাবে সীমাহীন ইতিহাস পেতে পারেন। এটি কোনও git-branchধরণের ফ্যাশনে স্বয়ংক্রিয়ভাবে ট্র্যাক করা হয় ( jovicailic.org/2017/04/vim-pers depend-undo )। আপনি যখনই স্বাভাবিক মোডে যান তখন আপনার পূর্বাবস্থার ইতিহাস স্বয়ংক্রিয়ভাবে ট্র্যাক করা হয়। সুতরাং এটি "ম্যানুয়াল পূর্বাবস্থায় পয়েন্টস" তৈরি করার মানসিক বোঝা হ্রাস করে। আপনার সম্পাদকরা "পূর্বাবস্থায়" বাফারগুলি কেন ব্যবহারিক হিসাবে ব্যবহার করছেন না?

— alpha_989

Answer 2

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

তাই হ্যাঁ, আমি মঞ্চের অঞ্চলটি খুব সহায়ক বলে মনে করি।

এবং না, আমি কখনও ব্যবহার করি না git commit -a। তবে আমি প্রায়শই ব্যবহার করি git add -u। এইভাবে আমি কী প্রতিশ্রুতিবদ্ধ তা কল্পনা করতে পারি।

Comments

যথাযথভাবে। আপনি যেটা কমিট করছেন ঠিক তার চেয়ে সুবিধাটি আরও অনেক সূক্ষ্ম দানাদার নিয়ন্ত্রণ।

— জোশ কে

আপনি এক ফাইল একাধিকবার স্টেজ করলে কী হবে? মঞ্চে এটি "সংযুক্ত" হয়ে যায়?

— m4l490n

Answer 3

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

Comments

এটি কীভাবে করা যায় তা নিয়ে আমি সবসময়ই ভাবতাম। আমি আশা করি কোনও ফাইল রয়েছে .gitignorelinesযাতে আপনি পৃথক লাইনে স্থানীয় পরিবর্তন করতে পারেন যা কমিটগুলি থেকে বাঁচতে পারে এবং অক্ষত থাকতে পারে।

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

@ রেনহেনরিচস, কনফিগারেশন ফাইলগুলির বিষয়ে চিন্তা করুন যা প্রতিটি বিকাশকারী দ্বারা পরিবর্তিত হওয়া দরকার।

— ইয়ান

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

— রেন হেনরিচস

@ রেইনহেনরিচস, হ্যাঁ এবং এটি খুব সাধারণ বিষয় যখন ফাইলটিতে ডাটাবেস সার্ভারের নাম থাকে এবং প্রতিটি দেবের নিজস্ব ডাটাবেস থাকে।

— আয়ান

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

— এইডিয়াকাপি

Answer 4

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