কমিটের মধ্যে ইতিমধ্যে যখন আমি দীর্ঘ প্রতীক্ষা করেছি তখন আমার কী করা উচিত?

Question

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

এর চেয়ে ভাল কি?

1. আমার পরিবর্তিত সমস্ত জিনিসের তালিকাভুক্ত করার জন্য একটি খুব বড় কমিট করুন
2. ফাইলগুলিতে একাধিক সংশোধন, পরিবর্তন, অতিরিক্ত পদ্ধতির নাম ইত্যাদি রয়েছে বলে এটি সম্ভবত ছোট ছোট কমিটে ভাঙ্গার চেষ্টা করুন likely
3. কেবল উপযুক্ত কমিটের জন্য ফাইলের আংশিক বিপরীতগুলি করার চেষ্টা করুন, তারপরে নতুন পরিবর্তনগুলি পিছনে রাখুন।

দ্রষ্টব্য: এই মুহূর্তে আমি এই প্রকল্পে কাজ করা একমাত্র প্রোগ্রামার; কমপক্ষে আরও বেশি প্রোগ্রামার নিয়োগ না করা পর্যন্ত কেবলমাত্র এই ব্যক্তি যিনি এই প্রতিশ্রুতিবদ্ধ মন্তব্যগুলির কোনওটিতেই নজর রাখবেন me

যাইহোক: আমি এসভিএন এবং সাবক্লিপ ব্যবহার করছি। আমি এই পরিবর্তনগুলি করার আগে একটি নতুন শাখা তৈরি করেছি।

আরও তথ্য : আমি কীভাবে এই পরিস্থিতিতে প্রথম অবস্থানে এসেছি সম্পর্কিত সম্পর্কিত একটি পৃথক প্রশ্ন জিজ্ঞাসা করেছি: অ্যাপ্লিকেশনটির আঠার পুনর্লিখনের জন্য কীভাবে প্রস্তুতি নেওয়া যায়

Comments

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

— Alexis

অন্তত শাখায় এটি পরীক্ষা করে দেখুন, যাতে আপনি আপনার পরিবর্তনগুলি হারাবেন না।

— ররি হান্টার

আপনি নিজেকে প্রশ্ন জিজ্ঞাসা করেই যেতে পারেন এবং আরও অপেক্ষা করতে পারেন, বা বাস্তবে প্রতিশ্রুতিবদ্ধ এবং যে কোনও গণ্ডগোল সৃষ্টি করে তা মোকাবেলা করুন ... এবং তারপরে ... এটি আবার করবেন না!

— হাইলেম

# 1, ক্ষমার জন্য প্রার্থনা করুন, এবং তারপরে এগিয়ে যান এবং আর পাপ করবেন না :)

— পিটারিস

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

— ডক ব্রাউন

Answer 1

উত্তর দেওয়ার জন্য, আপনাকে নিজেকে জিজ্ঞাসা করতে হবে যে আপনি ভবিষ্যতে এই প্রতিশ্রুতিগুলির ফলাফল কীভাবে ব্যবহার করবেন বলে আশা করছেন। সর্বাধিক সাধারণ কারণগুলি হ'ল:

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

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

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

আপনার পরিস্থিতি সম্পর্কে আমার বোধগম্যতা থেকে আপনি এটি বর্ণনা করেছেন বলে মনে হচ্ছে, এই মুহুর্তে আপনার প্রতিশ্রুতি বিভক্ত করার কোনও লাভ নেই।

Comments

দুর্দান্ত উত্তর! যদিও ছোট ছোট অঙ্গীকারগুলি না করায় আমি কোনও কম অনুশোচনা বোধ করি না, তবুও যতটা সম্ভব উত্পাদনশীলভাবে ভাল আচরণে ফিরে আসার জন্য আমার কী করা উচিত সে সম্পর্কে আমি আরও অনেক ভাল বোধ করি।

— durron597

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

— স্টিভ জেসোপ

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

— হান্স-পিটার স্টার

@hstoerr - আপনি যদি 1.5 বা তার পরে সাবভার্সনে থাকেন তবে আপনি মার্জ করার পরে --reintegrate বিকল্পের সাহায্যে ইতিহাস সংরক্ষণ করতে পারেন।

— ডাস্টিন কেন্ডল

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

— স্পাইডি

Answer 2

আমি মনে করি আপনি যা করেন না কেন কোড চেক করা এড়ানোর চেষ্টা করুন যা আপনি জানেন যে সংকলন করবে না।

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

Comments

বিকল্প তিনটি সম্ভব তবে এটি অত্যন্ত সময়সাপেক্ষ হবে। আমি মনে করি আমি কেবল 1 বিকল্পটি করতে যাচ্ছি

— durron597

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

— কেনি এভিট

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

— স্টিফেন সি

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

— ম্যাকিয়েজ পাইচোটকা

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

— স্টিফেন সি

Answer 3

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

বিকল্প 1 আপনার করা পরিবর্তনগুলির ইতিহাসকে অস্পষ্ট করে, তবে অন্যথায় এটি কোনও সমস্যা তৈরি করে না।

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

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

আপনার প্রদত্ত তথ্যের ভিত্তিতে আমি 1 বিকল্পটি বেছে নেব?

প্রোটোটাইপিং এবং পুনর্লিখন

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

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

আপনি যখন কোনও নির্দিষ্ট অনুমান বা নকশাকে বৈধতা দিয়েছেন, আপনার মূল প্রকল্পে এটি আদর্শভাবে একটি শাখায় পুনর্লিখন করুন এবং ছোট, অর্থবহ অঙ্গীকারগুলি করুন যা পরিবর্তনের প্রকৃতি হিসাবে অন্যদের (ভবিষ্যতে আপনি সহ) বুঝতে সাহায্য করবে আপনি তৈরি করছেন

Comments

ভাল উত্তর; প্রোটোটাইপিং সম্পর্কে আরও সুনির্দিষ্ট বিবরণের সাথে লিঙ্ক করার জন্য কেন আপনার কাছে কোনও ভাল নিবন্ধ বা অন্যান্য জ্ঞানের ভিত্তি রয়েছে? আমার প্রোটোটাইপিংয়ের সংস্করণটি হ'ল "নোটবুক বা হোয়াইটবোর্ডে স্কেচ"

— durron597

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

— কেনি ইভিট

Answer 4

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

অতএব, আমি বিকল্প 1 এ যাব যদি সম্ভব না হয় তবে অপশন 2।

বিকল্প 3 এর জন্য অনেক প্রচেষ্টা প্রয়োজন, এবং এটি কেবল এটির পক্ষে উপযুক্ত নয়।

Comments

বা সংকলনবিহীন সংস্করণগুলিকে "কমপ্লিট না করা" হিসাবে ট্যাগ করুন

— ফ্রিক

@ratchetfreak: আমার ধারণা, এসভিএন-তে একটি "ট্যাগ" বেশি সাহায্য করবে না, যেহেতু ট্যাগগুলি ট্রাঙ্কে "মন্তব্য" হিসাবে কাজ করে না।

— ডক ব্রাউন

@ ডকব্রাউন আমার অর্থ এটি প্রতিশ্রুতি বার্তায় যুক্ত করা ছিল

— ফ্রিক

: @ratchetfreak আমি "- স্বল্পতা কম্পাইল এবিসি চেক দশম ভাগ / এন" এটা করতে হবে

— BЈовић

বিকল্প 3 তেমন পরিশ্রমের প্রয়োজন নেই। আরেকটি উত্তর ব্যাখ্যা করে যে কীভাবে এটি দ্রুত এবং সহজে ব্যবহার করা যায় git add --patchএবং git stash। পুরানো উত্স নিয়ন্ত্রণ সরঞ্জাম এবং জ্ঞানের কারণে পরিস্থিতি কেবল কঠিন বলে মনে হয়।

— রন ম্যাকনিল

Answer 5

ফাইলগুলিতে একাধিক সংশোধন, পরিবর্তন, অতিরিক্ত পদ্ধতির নাম ইত্যাদি রয়েছে বলে এটি সম্ভবত ছোট ছোট কমিটে ভাঙ্গার চেষ্টা করুন likely

যখন আমি নিজেকে একইরকম পরিস্থিতিতে পেয়েছি তখন আমি নিম্নলিখিত কৌশলটি ব্যবহার করেছি:

1. একটি নির্দিষ্ট বৈশিষ্ট্যের সাথে প্রাসঙ্গিক কেবল কোডটি যুক্ত করুন: git add --patch
2. অন্যান্য সমস্ত পরিবর্তন সঞ্চিত: git stash save --keep-index
3. পরীক্ষা চালান / সংকলন চেষ্টা করুন
4. সবকিছু ঠিকঠাক থাকলে পরিবর্তনগুলি প্রতিশ্রুতি দিন, 1 এ যান না

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

Comments

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

— durron597

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

— জোয়েটউইডেল

গিটের সাহায্যে আপনি অঙ্গীকারের আগে ইন্টারেক্টিভ (যুক্ত -i) যোগ করতে পারেন এবং প্রতিশ্রুতি দেওয়ার পরে তার শাখাটি স্বাধীনভাবে কার্যকর করতে পারেন।

— রিয়েজবোসচ

Answer 6

বিকল্প 4 সম্পর্কে: আপনার অস্থায়ী স্থানে আপনার রেপোর বর্তমান অবস্থার ব্যাক আপ করুন, আপনার রেপোটিকে তার মূল অবস্থায় ফিরিয়ে দিন, আপনি যে সমস্ত পরিবর্তন করেছেন তার একটি তালিকা তৈরি করুন (আপনি এখনও অস্থায়ী ব্যাকআপটি দেখতে পারেন), তারপরে ম্যানুয়ালি রিম্পিমেন্ট করুন (এবং সংকলন করুন) এবং পরীক্ষা!) তাদের পৃথক কমিট হিসাবে।

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

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

Comments

এটি অপশন # 3 করার একটি উপায় মাত্র। সম্ভবত সবচেয়ে ভাল উপায়, সত্য, তবে এখনও বেশ সময় ব্যয়কারী।

— durron597

আমি যখন একটি বড় কমিট করেছিলাম তখন বার্তা যুক্ত / মোছার / পাঠানোর 149 লাইন ছিল। এটি করতে কমপক্ষে অর্ধেক দিন।

— durron597

@ durron597 আমি একমত নই, আমার কাছে মনে হয় এটি # 3 থেকে আলাদা। 149 লাইন সম্পর্কিত, আপনি একটি পরিষ্কার অঙ্গীকারের ইতিহাসকে কত মূল্য দেন? এটি অর্ধেক দিন ব্যয় মূল্য? যাইহোক, এটি অন্যান্য পদ্ধতির মতো নয় যে কোনও প্রতিশ্রুতিতে কোন রেখাটি হওয়া উচিত তা নির্ধারণের প্রয়োজন হবে না, সুতরাং আপনাকে কোনওভাবেই 149 লাইনটি অতিক্রম করতে হবে। সময়ের পার্থক্য কম হবে।

— সুপারবেস্ট

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

— durron597

আপনার পুরো রেপো ব্যাকআপ করতে হবে না । আপনি একটি "ব্যাকআপ" প্রতিশ্রুতিবদ্ধ করতে পারেন, তারপরে HEAD এর সাথে আবার রোল করুন git reset HEAD~। আপনি git reflogযদি সিদ্ধান্ত নেন যে আপনার এটি পরে প্রয়োজন হয় তবে আপনার প্রতিশ্রুতি এখনও থাকবে । আপনার "ব্যাকআপ" নাম দেওয়ার জন্য, রিসেটটি করার আগে আপনি একটি শাখাও কাঁটাচামচ করে (এবং তারপরে কার্যকারী শাখায় ফিরে যেতে পারেন) could আপনার যদি প্রয়োজন না হয় তবে পরে শাখাটি মুছুন। সম্পাদনা: দুঃখিত, বুঝতে পারেনি যে ওপেন এসএনএন-এ রয়েছে!

— জোয়েটউইল

Answer 7

আপনি একমাত্র প্রোগ্রামার; আপনি যা করেছেন তার গুরুত্বপূর্ণ বিটগুলি বিশদে বিশদে কেবলমাত্র একটি বৃহত্ চেকইন করুন।

আপনি যা করেছেন তার "অংশগুলি" পিছনে ফিরে যাওয়ার সম্ভাবনা আছে? যদি তা না হয় তবে অপশন 1 এর সাথে পুরোপুরি এগিয়ে যান।

সংস্করণ নিয়ন্ত্রণ সিস্টেমে কোড চেক করার কয়েকটি কারণ রয়েছে। এবং তাদের সমস্ত, যখন আপনি একমাত্র বিকাশকারী, নিরাপত্তার চারদিকে ঘোরে - যথা, আপনি যদি স্ক্রু আপ করেন তবে মেশিনটি মারা যায় বা যাই হোক না কেন, আপনি সর্বদা শেষ চেকপয়েন্টে ফিরে যেতে পারেন।

কোনও প্রোগ্রামার পরে এই প্রকল্পে আসবে তার সংকলন না করে এমন সংস্করণে ফিরে যেতে চাওয়ার সম্ভাবনা নেই। সুতরাং, আইএমএইচও, অপশন 2 হ'ল পাগলামি।

অপশন 3 টি এমন সময় ডুবির মত শোনাচ্ছে যে আমি যদি আপনার মনিব ছিলাম এবং আপনাকে এই সময়টি নষ্ট করতে দেখি তবে আপনার সময়ের মূল্যটি সম্পর্কে আমি আপনার সাথে একটু কথা বলব।

পুনরাবৃত্তি করতে: আপনার কোডটি পরীক্ষা করে আপনি আপনার মেশিনে ব্যর্থতার ক্ষেত্রে আপনার বাটটি আচ্ছাদন করছেন / সংরক্ষণ করছেন। এক-দলে দলে থাকা সমস্ত কিছুই উইন্ডো ড্রেসিং।

Comments

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

— অ্যারোনআট

ঘটনাক্রমে, এই কারণেই গিট ব্যবহারকারী দলগুলি সাধারণত মার্জ কমিটগুলি ঘৃণা করে এবং পরিবর্তে অনুরোধ / পুনর্বাসনের প্রয়োজন; সংশ্লেষ বিরতি bisectএবং অন্যান্য কৌশল সাধারণত সমস্যাগুলি বিচ্ছিন্ন করতে ব্যবহৃত হয়, কারণ অনেকগুলি পরিবর্তনকে একটি বিশাল প্রতিশ্রুতিবদ্ধ করে তোলা হয়।

— অ্যারোনআট

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

— 18

@ অ্যারনোথ আমি যুক্ত করব যে 3 মাস পরে আপনি নিজেই একটি 'অন্য প্রোগ্রামার' গঠন করতে পারেন।

— ম্যাকিয়েজ পাইচোটকা

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

— অ্যারোনআট

Answer 8

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

প্রত্যেকের সম্পূর্ণ অলঙ্ঘনীয় নিয়ম: কখনও এমন কোড যাচাই করবেন না যা এমনকি তৈরি করে না, এবং কোডটি কার্যকরভাবে কাজ করে না এমন চেক এড়াতে গুরুতরভাবে এড়াবেন না।

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

নিজের প্রোগ্রামিংয়ের ভাল অভ্যাসগুলি প্রশিক্ষণের এটিও একটি ভাল উপায়।

Comments

এটি যৌক্তিকভাবে উপরের গিট-ভিত্তিক উত্তর হিসাবে একই জিনিস ( git add --patchএবং git stash) এবং একটি দৃশ্যের একটি ভাল উদাহরণ যা আধুনিক ডিভিসিএস সহজেই পরিচালনা করতে পারে তবে পুরানো সিস্টেমগুলি পারে না।

— রন ম্যাকনিল

Answer 9

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

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

Comments

এই কি ইতিমধ্যে পূর্বে 12 উত্তর পোস্ট করা হয়েছে কিছুর উপর সারগর্ভ যোগ করার জন্য বলে মনে হচ্ছে না

— মশা

Answer 10

সমস্যাটি কমিটগুলির মধ্যে দীর্ঘ বিলম্বের মধ্যে নয় তবে আপনি কোডটি দীর্ঘ সময়ের তুলনায় আনপ্যাম্পেবল অবস্থায় রাখেন তা নয়। সবার আগে আপনার 'দীর্ঘ' সংজ্ঞাটি কী? কিছু লোকের জন্য ট্রানজিশনাল স্টেটের জন্য 5 মিনিট খুব বেশি তবে কিছু সংকলক চালানোর চেষ্টা না করে কয়েক দিনের জন্য তাদের কোডটি পোলিশ করতে পারে।

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

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

এর পরে আপনি দেখতে পাবেন যে পরবর্তী পরিবর্তন আপনাকে "খুব বেশি" লাগবে না (যার অর্থ যা বোঝায়)।

Comments

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

— ইদন আরে

@ ইডানআরি আসল প্রশ্ন থেকে ...Try to break it into smaller commits that likely won't compile...যদি আপনার কোডটি কমিটিকে কিছু করা থেকে বিরত রাখে তবে এটি ইতিমধ্যে ভাল sing "প্রতিশ্রুতিবদ্ধ" আপনার কাজ চালিয়ে যাওয়ার একমাত্র উপায়। আমরা আরও চরম মামলা সম্পর্কে ভাবতে পারি - "যদি কোনও কিছু আমাকে উত্স ফাইলটি সংরক্ষণ করতে বাধা দেয়"। সুতরাং এটা কি হতে পারে? আমার ধারণা এটি আপনার নিজের পরিবর্তনের ভয়। কেন হতে পারে? ... আমি মনে করি আপনি পয়েন্টটি পেয়েছেন

— আলেকসটি

আমার কাছে এটির মতো মনে হয় যা তাকে ঘৃণা করতে বাধা দেয় নিছক অলসতা।

— ইদান আরে

@ ইডানআরি আপনি সমস্ত বিষয় সঠিক আছেন। এটি প্লাস পর্যাপ্ত টিডিডি না করা, যা একটি পৃথক বিষয়।

— durron597

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

— durron597