কেন স্কোয়াশ গিট টানার অনুরোধের জন্য কমিট করে?

Question

আমি কেন প্রতিটি গুরুতর গিথুব রেপো আমার অনুরোধগুলিকে আমার একক প্রতিশ্রুতিবদ্ধভাবে স্কোয়াশ করার জন্য অনুরোধ জানায়?

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

এটি "প্রাথমিকভাবে প্রতিশ্রুতিবদ্ধ এবং প্রায়শই প্রতিশ্রুতিবদ্ধ" মন্ত্রটির বিরুদ্ধেও যায় বলে মনে হয়।

Comments

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

— raptortech97

" এটি" তাড়াতাড়ি প্রতিশ্রুতিবদ্ধ এবং প্রায়শই "মন্ত্রের বিরুদ্ধে" বলে মনে হয় - না, আপনি তাড়াতাড়ি / প্রায়শই প্রতিশ্রুতিবদ্ধ হন, তবে আপনি প্রতিটি ক্ষুদ্র পরিবর্তনকে জনসংযোগ করতে চান না। এবং পর্যালোচক এগুলি সন্ধান করতে চান না, এটি নিশ্চিত।

— JensG

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

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

— এমকোবিট

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

— Tjart

Answer 1

যাতে আপনার স্পষ্ট এবং সংক্ষিপ্ত গিট ইতিহাস রয়েছে যা পরিষ্কারভাবে এবং সহজেই সম্পাদিত পরিবর্তনগুলি এবং কী কারণে ডকুমেন্ট করে।

উদাহরণস্বরূপ, আমার জন্য একটি সাধারণ 'ছিটমহল' গিট লগ নীচের মত দেখাতে পারে:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

কী এলোমেলো!

যদিও আরও যত্ন সহকারে পরিচালিত এবং একত্রীভূত গিট লগ এর জন্য বার্তাগুলিতে কিছুটা অতিরিক্ত ফোকাস যুক্ত হতে পারে:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

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

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

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

8754390gf87... Implement feature switches

"1 টুকরো কাজের" বলে মনে হচ্ছে। হয় তাদের অস্তিত্ব আছে বা তারা নেই! এটিকে ভেঙে ফেলার কোনও অর্থ বোধ হয় না। তবে অভিজ্ঞতা আমাকে দেখিয়েছে যে (সাংগঠনিক আকার এবং জটিলতার উপর নির্ভর করে) আরও দানাদার পথ হতে পারে:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

ছোট ছোট টুকরো বলতে বোঝায় সহজ কোড পর্যালোচনা, সহজ ইউনিট টেস্টিং, ক্যু করার আরও ভাল সুযোগ, একক দায়িত্বের নীতিমালায় আরও ভাল প্রান্তিককরণ ইত্যাদি etc.

প্রকৃতপক্ষে কখন এ জাতীয় স্কোয়াশ করতে হবে তার ব্যবহারিকতার জন্য, মূলত দুটি স্বতন্ত্র পর্যায় রয়েছে যার নিজস্ব কর্মপ্রবাহ রয়েছে

• আপনার বিকাশ, যেমন অনুরোধ টানুন
• আপনার কাজটি মূল লাইনের শাখায় যুক্ত হয়েছে, যেমন মাস্টার

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

ব্যবহার --no-ffযখন কেউ একত্রীকরণ জন্য কমিট ব্যবহার করবে এবং ইতিহাস সংরক্ষণ (শাখায়) মাস্টার মার্জ। কিছু সংস্থা এটিকে একটি সেরা অনুশীলন বলে মনে করে। Https://stackoverflow.com/q/9069061/631619 এ আরও দেখুন git logযেখানে আপনি --no-ffকমিটের সর্বশেষ প্রতিশ্রুতি যেখানে ব্যবহার করা হবে সেখানে তার ব্যবহারিক প্রভাবটিও দেখতে পাবেন, যেখানে শীর্ষস্থানীয় (যখন সবেমাত্র সম্পন্ন হবে) থাকবে, যেখানে --no-ffতা ছাড়াও ইতিহাসে আরও নীচে, তারিখ এবং অন্যান্য চুক্তির উপর নির্ভর করে।

Comments

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

— জেজ

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

— মাইকেল ডুরান্ট

আমিও অ্যান্টি স্কোয়াশ। আপনার প্রথমে মূর্খ প্রতিশ্রুতি বার্তা লেখা উচিত নয়। এবং উদাহরণে (85493g2458 ... স্থির স্লাইডশো প্রদর্শন ইস্যুতে ইস্যু) যদি আমি এর সাথে সম্পর্কিত কোডটি ডিবাগ করি তবে এটি আরও বেশি সহায়ক হবে।

— থমাস ডেভিস

দুর্ভাগ্যজনক যে এসসিএম অনুশীলনে এ জাতীয় গাফিলতি এবং ভুল জায়গায় স্থানচ্যুত হয়েছে। ফিল্টারিং সরঞ্জামগুলি ব্যবহারের প্রতিশ্রুতি না দিয়ে ইতিহাস পাঠের ব্যবস্থাপনার জন্য ব্যবহার করা উচিত।

— সিটিপেনরোজ

বিরক্তিকর প্রবণতা এবং ডগমা। তোকে। আমি আরও সত্যান্বেষী উপায়ে উপস্থাপন করা আরও একটি ফ্যাক্ট ভিত্তিক যুক্তি পছন্দ করব। আপনি ভিন্ন মতামত পোস্ট / ভোট দিতে স্বাগত জানাই। জনগণের ভোটদানের বিষয়টি এটিই

— মাইকেল ডুরান্ট

Answer 2

কারণ প্রায়শই একজন পিআর টান ব্যক্তি কমিটের "যুক্ত বৈশিষ্ট্য এক্স" এর নেট এফেক্ট সম্পর্কে চিন্তা করে, "বেস টেম্পলেটগুলি, বাগফিক্স ফাংশন এক্স, ফাংশন ওয়াই যুক্ত করে, মন্তব্যে স্থির টাইপস, অ্যাডজাস্টেড ডেটা স্কেলিং পরামিতি, হ্যাশম্যাপের চেয়ে আরও ভাল পারফর্ম করে তালিকা "... বিস্তারিত স্তর

আপনি যদি মনে করেন যে আপনার 16 টি কমিটগুলি 1 "অতিরিক্ত বৈশিষ্ট্যযুক্ত এক্স, জেডকে এক্স ব্যবহার করার জন্য পুনরায়-বিবৃত জেড" এর পরিবর্তে 2 টি কমিট দ্বারা সেরা উপস্থাপিত হয়েছে তবে এটি সম্ভবত 2 টি কমিটের সাথে একটি জনসম্পর্কিত প্রস্তাব করা ভাল, তবে তারপরে প্রস্তাব দেওয়া ভাল might সেক্ষেত্রে 2 পৃথক জনসংযোগ (যদি রেপো এখনও একক প্রতিশ্রুতিবদ্ধ জনগণের উপর জোর দেয়)

এটি আপনার রেপোর মতো "তাড়াতাড়ি প্রতিশ্রুতিবদ্ধ এবং প্রায়শই প্রতিশ্রুতিবদ্ধ" মন্ত্রের বিরুদ্ধে যায় না, আপনি যখন বিকাশ করছেন তখনও আপনার কাছে দানাদার বিশদ রয়েছে, সুতরাং আপনার কাছে কাজ হারাবার ন্যূনতম সম্ভাবনা রয়েছে এবং অন্যান্য ব্যক্তিরা পর্যালোচনা / টান / প্রস্তাব করতে পারবেন নতুন জনসংযোগ বিকাশকালে আপনার কাজের বিপরীতে pr

Comments

কিন্তু যখন আপনি স্কোয়াশ প্রতিশ্রুতিবদ্ধ আপনি ঠিক নিজের কাঁটাচামচে সেই ইতিহাসটি হারিয়ে ফেলেন? আপনি কেন সেই ইতিহাস ফেলে দিতে চান?

— হামস্টার

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

— অ্যান্ড্রু হিল

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

— 25-25

Answer 3

আমি যা দেখতে পাচ্ছি তার প্রধান কারণটি হ'ল:

• পুলের অনুরোধগুলিকে মার্জ করার জন্য গিটহাব ইউআই বর্তমানে (অক্টোবর 2015) আপনাকে বাধ্যতামূলক বার্তার প্রথম লাইনটি সম্পাদনা করার অনুমতি দেয় না, এটি বাধ্য করে Merge pull request #123 from joebloggs/fix-snafoo
• কমিটের ইতিহাস ব্রাউজ করার জন্য গিটহাব ইউআই বর্তমানে আপনাকে শাখার ইতিহাস --first-parentদৃষ্টিকোণ থেকে দেখার অনুমতি দেয় না
• গিটহাব ইউআই বর্তমানে কোনও ফাইলের জন্য দোষ দেখার জন্য আপনাকে ফাইলটির --first-parentদোষটি দৃষ্টিকোণ দিয়ে দেখতে দেয় না (নোট করুন এটি কেবল গিট ২.6.২ এ স্থির করা হয়েছিল, তাই আমরা গিটহাবকে ক্ষমা করতে পারিনি যাতে এটি ছিল না উপলব্ধ)

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

স্কোয়াশেড কমিটগুলির সাথে আপনার ইতিহাসটি দেখতে কিছুটা দেখতে হবে

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

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

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

যখন আপনি গিটিহাব ইউআই ব্যবহারের মধ্যে নিজেকে সীমাবদ্ধ রাখেন এমন কোনও পিআর ট্রেসিংয়ে যখন আপনি প্রচুর প্রতিশ্রুতিবদ্ধ হন তখন কিছুটা দুঃস্বপ্ন হয়ে উঠতে পারে ।

উদাহরণস্বরূপ, আপনি কোনও নাল পয়েন্টারটি কোনও ফাইলের কোথাও ডি-রেফারেন্সড হিসাবে দেখতে পেয়েছেন ... সুতরাং আপনি বলবেন "এটি কে করেছে এবং কখন? কোন প্রকাশ সংস্করণগুলি প্রভাবিত হয়?" তারপরে আপনি গিটহাব ইউআইতে দোষারোপের দিকে ঘুরে দেখেন এবং দেখবেন যে লাইনটি পরিবর্তিত হয়েছিল789fdfffdf... "ওহ তবে এক সেকেন্ড অপেক্ষা করুন, সেই বাকী কোডটি বাকী কোডের সাথে ফিট করার জন্য কেবল তার লাইনটি বদলেছে", সুতরাং এখন আপনাকে প্যারেন্ট কমিটে আবার ফাইলের জন্য ট্রি স্টেটে নেভিগেট করতে হবে এবং পুনরায় দেখা করতে হবে দোষ পৃষ্ঠার ... অবশেষে আপনি প্রতিশ্রুতিটি সন্ধান করুন ... এটি 6 মাস আগে থেকে একটি প্রতিশ্রুতি ... "ওহ **** এটি 6 মাস ব্যবহারকারীদের উপর প্রভাব ফেলতে পারে" আপনি বলছেন ... আহ, তবে অপেক্ষা করুন, সেই প্রতিশ্রুতি আসলে একটি পুল অনুরোধে ছিল এবং এটি গতকালই একীভূত হয়েছিল এবং এখনও কেউ মুক্তি প্রকাশ করেনি ... "স্কোয়াশিং ইতিহাস ছাড়াই কমিটস মার্জ করার জন্য ধিক্কার জানাই মানুষ" এমন কান্না যা সাধারণত প্রায় 2 বা 3 কোড প্রত্নতত্ত্ব অভিযানের পরে শোনা যায় গিটহাব ইউআই

আপনি এখন গিট কমান্ড লাইনটি (এবং সুপার-অসাধারণ ২.6.২ যার সমাধান রয়েছে git blame --first-parent) ব্যবহার করে এটি কীভাবে কাজ করে তা এখন বিবেচনা করা যাক

• আপনি যদি গিট কমান্ড লাইনটি ব্যবহার করে থাকেন তবে আপনি মার্জ কমিট ম্যাসেজ সম্পূর্ণরূপে নিয়ন্ত্রণ করতে সক্ষম হবেন এবং এভাবে মার্জ কমিটের একটি চমৎকার সারসংক্ষেপ লাইন থাকতে পারে।

সুতরাং আমাদের প্রতিশ্রুতিবদ্ধ ইতিহাস দেখতে হবে

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

তবে আমরাও করতে পারি

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(অন্য কথায়: গিট সিএলআই আপনাকে আপনার পিষ্টক পেতে দেয় এবং এটিও খেতে দেয়)

এখন যখন আমরা নাল পয়েন্টার ইস্যুতে আঘাত করি ... ভাল আমরা কেবল ব্যবহার করি git blame --first-parent -w dodgy-file.cএবং আমাদের তত্ক্ষণাত সেই সঠিক প্রতিশ্রুতি দেওয়া হয় যেখানে সাধারণ শ্বেত স্পেস পরিবর্তনগুলি উপেক্ষা করে মাস্টার শাখায় নাল পয়েন্টার ডি-রেফারেন্স চালু হয়েছিল।

অবশ্যই আপনি যদি গিটহাব ইউআই ব্যবহার করে মার্জগুলি করছেন তবে git log --first-parentসত্যই কৃপণতার সাথে গিটহাবকে একীভূত প্রতিশ্রুতি বার্তার প্রথম লাইন জোর করে বলার জন্য ধন্যবাদ:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

একটি দীর্ঘ গল্প সংক্ষিপ্ত কাটা:

গিটহাব ইউআই (অক্টোবর ২০১৫) এর কীভাবে টানার অনুরোধগুলিকে একীভূত করে, কীভাবে এটি প্রতিশ্রুতিবদ্ধ ইতিহাস উপস্থাপন করে এবং কীভাবে এটি দোষী তথ্যের বৈশিষ্ট্যকে বিশিষ্ট করে তার সাথে অনেকগুলি ত্রুটি রয়েছে। গিটহাব ইউআইতে এই ত্রুটিগুলি ঘাটানোর বর্তমান সেরা উপায় হ'ল লোককে মার্জ করার আগে তাদের প্রতিশ্রুতিগুলি স্কোয়াশ করার জন্য অনুরোধ করা।

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

স্ক্রিপ্ট পোস্ট করুন

স্কোয়াশিং কমিটের প্রায়শই উল্লেখ করা চূড়ান্ত কারণটি হ'ল ব্যাকপোর্টিং সহজ করে তোলা ... যদি আপনার কাছে কেবল ব্যাক বোর্টে প্রতিশ্রুতি থাকে (যেমন স্কোয়াশেড কমিট) থাকে তবে চেরি পিক করা সহজ ...

ঠিক আছে আপনি যদি গিট ইতিহাসের সাথে তাকান git log --first-parentতবে আপনি কেবল মেশানো কমিটগুলি চেরি চয়ন করতে পারেন। অধিকাংশ মানুষ বিভ্রান্ত চেরি পিকিং একত্রীকরণ করে কারণ আপনার নির্দিষ্ট করতে হবে পেতে -m Nবিকল্প কিন্তু যদি আপনার কাছ থেকে কমিট পেয়েছিলাম git log --first-parentতারপর আপনাকে জানাতে চাই যে এটি প্রথম পিতা বা মাতা যে আপনাকে অনুসরণ করতে তাই এটি হতে হবে চাইgit cherry-pick -m 1 ...

Comments

চমৎকার উত্তর! তবে চেরি-বাছাই করা পরিসীমা যথেষ্ট সহজ, নিশ্চিত নয় যে আমি এটি কারণ হিসাবে কিনেছি।

— স্টিগলার

@ স্টিগ্লগার আমি ব্যক্তিগতভাবে এটিকে কারণ হিসাবে ক্রয় করি না, তবে এটির কারণ হিসাবে অন্যরা এটিকে উদ্ধৃত করে দেখেছি। গিট টুলিংটি আপনি কী চান এবং স্কোয়াশিং কমিটস তা হ'ল আইএমএইচও, তবে আমি বলব যে --first-parentস্কোয়াশিংয়ের বিরুদ্ধে যুক্তি জয়ের জন্য নিজেকে স্থির করে নেওয়া হয়েছে ;-)

— স্টিফেন কনলি

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

— সিটিপেনরোজ

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

— অ্যামি পেলেগ্রিনি ২

Answer 4

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

Comments

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

— জন পুরদি

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

— ফ্রেড থমসন

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

— মাইকেল ডুরান্ট

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

— gbjbaanb

Answer 5

দৃষ্টিভঙ্গির কারণে ... সর্বোত্তম অনুশীলন হ'ল <<issue-management-system>>সম্ভব হলে একক ইস্যুতে একক প্রতিশ্রুতিবদ্ধ হওয়া।

আপনার নিজের বৈশিষ্ট্য শাখা / রেপোতে আপনি যতটা কমিট করতে চান, কিন্তু আপনার দৃষ্টিভঙ্গির জন্য আপনি এখন যা করছেন তার জন্য এটি আপনার ইতিহাস প্রাসঙ্গিক ... পুরো টিম / প্রকল্পের বা ইতিহাসের কাছ থেকে আবেদন করার জন্য তিনি ইতিহাস নয় দৃষ্টিভঙ্গি এখন থেকে কয়েক মাস রাখা হবে ...

সুতরাং আপনি যখনই কোনও সাধারণ রেপোতে বাগ ফিক্স বা বৈশিষ্ট্যটি প্রতিশ্রুতিবদ্ধ করতে চান (উদাহরণস্বরূপ বিকাশকারী শাখার সাথে রয়েছে) আপনি নীচের মতো এটি কী করতে পারেন:

কীভাবে আপনার বৈশিষ্ট্য শাখাটিকে দ্রুত বিকাশ করতে হবে

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

Comments

এটি জিজ্ঞাসা করা প্রশ্নটি সমাধান করার চেষ্টাও করে না, কেন স্কোয়াশ গিটটি টানার অনুরোধের জন্য কমিট করে? দেখুন কিভাবে উত্তর দিতে

— মশা

ব্যাখ্যা করার চেষ্টা করার পরে এটি করা উচিত ...

— ইওর্ডান জর্জিভ

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

— gnat

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

— ইওর্ডান জর্জিভ

Answer 6

আমি কোডটি সর্বজনীন হচ্ছে কিনা তা দেখতে পাব।

যখন প্রকল্পগুলি ব্যক্তিগত থাকে:

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

যখন প্রকল্পগুলি সর্বজনীন হয়:

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