কোনও ধাক্কায় চূড়ান্ত প্রতিশ্রুতি না দেওয়া পর্যন্ত কি মধ্যবর্তী কমিটগুলি ভাঙ্গা ভাল?


13

সম্পর্কিত: প্রতিটি গিট কমিট প্রকল্পের কাজকর্মের অবস্থায় ছেড়ে দেওয়া উচিত?

ধরুন আমি স্থানীয়ভাবে নিম্নলিখিত কমিটগুলি করি:

  • অ্যাপ্লিকেশন ভঙ্গ করে ডাটাবেস স্কিমা পরিবর্তন করুন।

  • অ্যাপ্লিকেশনটি আপডেট করুন যাতে এটি আবার ডেটাবেস স্কিমার সাথে সামঞ্জস্য হয়।

যতক্ষণ না আমি উভয় প্রতিশ্রুতি দেয়, ততক্ষণ masterকর্মক্ষম অবস্থায় থাকে। তবে, একটি .তিহাসিক সংস্করণ ভাঙা।

আমি সচেতন যে আমি git rebase -iএকসঙ্গে কমিটগুলি স্কোয়াশ করতে ব্যবহার করতে পারি । যাইহোক, ফলাফল প্রতিশ্রুতি বৃহত্তর এবং কম বর্ণনামূলক হবে। আমি কেন কিছু পরিবর্তন করেছি তা অনুসন্ধান করার জন্য যদি প্রতিশ্রুতিবদ্ধ ইতিহাস অনুসন্ধান করতে হয় তবে আমি বরং আমি কী করেছি এবং কেন তা দেখিয়ে আসল প্রতিশ্রুতিটি খুঁজে পেতে পারি।

আমার প্রশ্নগুলি হ'ল:

  • মাস্টার ভাঙ্গা historical তিহাসিক কমিটের কারণে কি কেউ সমস্যার সম্মুখীন হয়েছে ?

  • যদি তা হয় তবে স্বতন্ত্র প্রতিশ্রুতি বার্তাগুলি এবং পরিবর্তনগুলি ত্যাগ না করে এই জাতীয় সমস্যাগুলি এড়াতে কি সহজ উপায় আছে?


1
আপনি কেন এক পদক্ষেপে উভয় পরিবর্তন করতে পারবেন না? আপনি কি কাজের অর্থপূর্ণ অংশ করার কথা বলছেন না?
জর্জিও

উত্তর:


9

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

দূষণকারী মাস্টার ছাড়াই স্বতন্ত্র প্রতিশ্রুতিবদ্ধ রাখার সহজ উপায়টি শাখা ব্যবহার করা। আপনি সেখানে ব্রেকিং / পরীক্ষামূলক স্টাফ রাখতে পারেন যাতে মাস্টার ব্রাঞ্চের ইতিহাসকে দূষিত না করে আপনার সূক্ষ্ম ইতিহাস থাকতে পারে।


3
হ্যাঁ, তবে যখন আমি কোনও বৈশিষ্ট্যকে মাস্টারে রূপান্তর করি এবং এটি দ্রুত এগিয়ে যায়, তখন মাস্টারের সেই সমস্ত কমিট রয়েছে। যদি এটি প্রচুর কমিট হয় তবে আমি কি --no-ffগিট-মার্জ করার বিকল্পটি কোনও মার্জ কমিট করতে বাধ্য করার জন্য ব্যবহার করা উচিত ?
জোয়ে অ্যাডামস

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

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

3
পার্টিতে কিছুটা দেরি হলেও আপনি যদি ভাঙা কমিটস সত্যিই পছন্দ না করেন তবে আপনার ব্রাঞ্চকে মাস্টারে মার্জ করার আগে রিবেস করুন।
ড্যান প্যান্ট্রি

3

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

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

যদি আপনার দলটি এই জাতীয় ব্রাঞ্চিং মডেল অবলম্বন না করে, তবে পুরো পটটি পুরোপুরি চাপিয়ে দেওয়ার এবং এটি দিয়ে কাজ করার আপনার কাছে একটি বৈধ অজুহাত রয়েছে।


3

না, ঠিক আছে না।

আপনি যদি কখনও কোনও করেন git bisect(এবং যারা সেই ঘাতক বৈশিষ্ট্যটি ভালবাসেন না) তবে আপনি এমন একটি ইতিহাসের মূল্য জানেন যেখানে প্রতিটি প্রতিশ্রুতিবদ্ধ হয়।

bisectএটি নির্মাণ না করার সময় যদি আপনার অনেক কমিট থাকে তবে আপনার কাছে প্রচুর git bisect skipগুলি থাকবে যা শেষ ভাল প্রতিশ্রুতি খুঁজে পাওয়া কঠিন করে তোলে।

যদি আপনি কোনও বৈশিষ্ট্য শাখাটি শেষ করেন এবং এটিকে মাস্টার হিসাবে মার্জ করেন তবে মার্জ করার আগে শাখাটি পরিষ্কার করুন যাতে আপনার ইতিহাস সুস্পষ্ট এবং বিল্ডিং হয়।


3

মাস্টার ভাঙ্গা historicalতিহাসিক কমিটের কারণে কি কেউ সমস্যার সম্মুখীন হয়েছে?

হ্যাঁ. ব্যাকপোর্ট, রিভার্ট এবং বাইসেক্টগুলি আরও শক্ত। সুতরাং ইতিহাস পড়ছে (নীচে দেখুন)।

যদি তা হয় তবে স্বতন্ত্র প্রতিশ্রুতি বার্তাগুলি এবং পরিবর্তনগুলি ত্যাগ না করে এই জাতীয় সমস্যাগুলি এড়াতে কি সহজ উপায় আছে?

আমি জানি না, যদিও শাখাগুলি একটি শালীন সমাধান।

তবে আমি মনে করি যে ব্যক্তি স্বতঃস্ফূর্তভাবে বাতিল (বা বরং স্কোয়াশিং) করাই সঠিক কাজ।

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

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

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

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


1

সংক্ষিপ্ত উত্তর: হ্যাঁ

পরীক্ষামূলক:

পরীক্ষিত চালিত বিকাশ মানে আপনি পরীক্ষাগুলি লিখুন যা বিরতি (যেমন ব্যর্থতা দেখান)।
তারপরে আপনি পরীক্ষাগুলি কার্যকর করার জন্য কোডটি লিখুন।

উন্নয়ন:

ছোট প্রতিশ্রুতিবদ্ধ, প্রায়শই প্রতিশ্রুতিবদ্ধ।
প্রতিটি প্রতিশ্রুতি রোলব্যাক পয়েন্ট হয়। আপনি যদি বুঝতে পারেন যে আপনি ভুল পথে আছেন আপনি তুলনামূলকভাবে সহজেই আগের পয়েন্টে রোলব্যাক করতে পারেন। আপনি যদি কমিট করেন তবে যথেষ্ট পরিমাণে শস্য হলে আপনি সঠিক পয়েন্টে রোলব্যাক করতে পারেন।

সতর্কীকরণ:

এর অর্থ এই নয়

1) আপনি ভাঙ্গা কোড মাস্টার হিসাবে পরীক্ষা করুন।
2) আপনাকে পর্যালোচনা করার জন্য সকল মাইক্রো কমিটকে চাপ দেওয়া দরকার।

আপনার কাজটি করার জন্য শাখা ব্যবহার করুন। পর্যালোচনা প্রক্রিয়াগুলির জন্য মাইক্রো কমিটিকে সম্ভাব্যভাবে কমপ্রেস করা উচিত যাতে তারা উপযুক্ত মন্তব্যের সাথে যুক্তিযুক্তভাবে স্বতন্ত্র ইউনিটে থাকে are আপনি যদি গিট ব্যবহার করে থাকেন তবে আপনি কমিটের মূল সেটটি ছাড়বেন না আপনি কেবল পর্যালোচনা প্রসেসের জন্য আরও নতুন একটি লজিক্যাল সেট তৈরি করতে পারবেন যা মাস্টার হিসাবে একীভূত হবে।


0

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.