আমার দলটি উত্স নিয়ন্ত্রণের জন্য টিম ফাউন্ডেশন সার্ভার ব্যবহার করে এবং আজ আমি এটি পরীক্ষা করে নেওয়ার আগে আমি কিছু বাগ এবং ধোঁয়া পরীক্ষা অ্যাপ্লিকেশন স্থির করেছিলাম তবে আমি কিছু কোড মন্তব্য করতে ভুলে গেছি। (এই কোডটি ইউআইকে কিছুটা অদ্ভুত করে তুলেছে))
কোড চেক করার আগে কী কী ভাল অভ্যাস রয়েছে তা জানতে চাই - আমি আর এই ধরণের ভুল করতে চাই না।
উত্তর:
আমি যা করার অভ্যাসটি পেয়েছি তার মধ্যে আমি যা যাচাই করতে যাচ্ছি তার প্রতিটি ফাইলের মধ্যে আগে যাচাই করা ঠিক আছে, তা আগে যাচাই করার আগে looking
আপনার মন্তব্য-আউট কোড কখনও চেক ইন করা উচিত নয়। যদি আপনার এমন কোড থাকে যা চেক-ইনগুলির আগে মন্তব্য করার দরকার পড়ে তবে আপনি এটি ভুল করছেন।
বিধি হিসাবে:
বিল্ড
3.1 বিল্ড ত্রুটিগুলি ঠিক করুন
পরীক্ষা চালান
৪.১ ভাঙ্গা পরীক্ষা ঠিক করুন
1 এ যান (যতক্ষণ না নতুন কিছু পাওয়া যায়)
সমস্ত পদক্ষেপ সম্পূর্ণ হলে কেবল চেক ইন করুন।
দেখুন চেক-ইন নাচ ।
অন্যান্য ভাল অভ্যাস:
rebase -iএবং আপনার স্থানীয় ইতিহাস সাফ করুন, স্কোয়াশিং কমিটস-ইন-প্রগ্রেস কমিটস নেই so
আমি এখানে খুব বেশি প্যান্টওয়েজেল হওয়ার চেষ্টা করছি না, তবে এই প্রশ্নের অনুমান (এবং উত্তরগুলির মধ্যে একটি ছাড়া) বেশিরভাগই সেন্ট্রালাইজড ভিসিএস, যেমন টিএফএস, এসভিএন, পারফোর্স ইত্যাদিতে প্রযোজ্য
Fair ওপি ব্যবহার করছে।
অন্যদিকে, ডিভিসিএস ব্যবহার করার সময় (যেমন মার্চুরিয়াল এবং গিট) আপনার সাধারণত চেক ইন করার জন্য অপেক্ষা করা উচিত নয় এবং উত্তরগুলিতে উল্লিখিত বেশিরভাগ জিনিস যেমন - ডিফস, সর্বশেষ পাওয়া, মার্জ করা ইত্যাদি ইত্যাদি প্রয়োজনীয় নয় necessary । এমনকি কোড রিভিউ এবং পরীক্ষাগুলির মতো জিনিসগুলি চেকিনের পরে করণীয় ভাল (যদিও সম্ভবত ধাক্কা দেওয়ার আগে, নির্ভর করে ...)
আমি এখানে দেখলাম যে একটি ব্যতিক্রম (এখনও অবধি) একটি কাজের আইটেমের সাথে জড়িত। অবশ্যই, চেকিনে মন্তব্য করাও ভাল ...
তিনটি জিনিস যা আমি অন্য উত্তরে দেখিনি:
নতুন ফাইল অন্তর্ভুক্ত করুন
অপরিবর্তিত ফাইলগুলি ফিরুন
আপনার জমা দেওয়া প্রতিশ্রুতি পরীক্ষা করুন
আমি যখন গিট ব্যবহার করি তখন দুটি জিনিস:
পারমাণবিক অঙ্গীকার:
git add --patchআমার পরিবর্তনগুলি একাধিক অংশে বিভক্ত করতে ব্যবহার করি ।সংক্ষিপ্তসারের সময় বিভিন্নগুলি দেখুন
git commit --verboseকরি যাতে আমার প্রতিশ্রুতি বার্তাটি টাইপ করার সময় আমি আমার পরিবর্তনের একটি ভিন্নতা দেখতে পাচ্ছি। (বা আমি পৃথক দেখানোর জন্য আমার প্যাচড গিট-ভিম ব্যবহার করি ))আমার দলের সার্ভারগুলিতে প্রয়োগ করা 'ভাল অনুশীলন' এর কয়েকটি আইটেমগুলি বেশ সোজা এগিয়ে are প্রথমে, আপনি যাচাই করার আগে আপনার সর্বদা সর্বশেষতম হওয়া উচিত এবং একটি স্থানীয় বিল্ড চালানো উচিত, যাতে আপনার কোডটি যে সংঘর্ষের সাথে সংঘর্ষে চলেছে তা অন্য কেউ পরীক্ষা করে নি ensure অতিরিক্তভাবে, সার্ভারের পরিবর্তে আপনার স্থানীয় মেশিনে কোনও কোডের বিরোধের যত্ন নিন take আপনার কোডটি ডাউনলোড করার সাথে সাথে সর্বশেষ কোডটি ডাউনলোড হয়ে গেছে এবং সঠিকভাবে কাজ করার জন্য নিশ্চিত হয়ে গেছে আপনি পরবর্তী পদক্ষেপের জন্য প্রস্তুত। যে কোনও অটোমেটেড পরীক্ষা চালান তারপরে আপনার চেক ইনটি শুরু করুন যাতে তারা এখনও সঠিকভাবে কাজ করে তা নিশ্চিত করে। তারপরে, কেবল নিশ্চিত হতে, আবার সর্বশেষ get
টিএফএস প্রশাসক হিসাবে সমস্ত চেক ইনগুলিতে মন্তব্য প্রয়োগ করা সম্ভব। আপনার কাজের জন্য সর্বদা চেক-ইন মন্তব্যগুলি প্রয়োগ করা হয় কিনা তা নির্বিশেষে আমি সুপারিশ করব। যদি আপনার কাছে এটি করার বিকল্প থাকে তবে এটি প্রয়োগ করুন। সর্বশেষে আপনার কোডটি যাচাই করার সময় থেকে আপনি কী পরিবর্তন করেছেন তার একটি সাধারণ সারসংক্ষেপ কমপক্ষে তা নিশ্চিত করুন That এইভাবে, যদি কিছু ভুল হয়ে যায়, আপনি চেক-ইনগুলি দেখে এবং দেখতে পারেন, মোটামুটি কী ছিল যে চেক ইন পরিবর্তন। এটি একটি ভাঙ্গা বিল্ড ডিবাগিংকে আরও সহজ করে তোলে।
তদুপরি, আপনার যদি টিএফএস প্রশাসনের সুবিধাগুলি থাকে তবে চেক-ইনগুলিতে রোলিং বিল্ডগুলি প্রয়োগ করুন (চেক-ইন কিছু ভেঙে ফেলেছে তা প্রত্যেকেই এখনই জানেন কিনা তা নিশ্চিত করার জন্য), এবং আপনি একটি গেটেড চেক-ইন সম্পাদন করতে সার্ভার সেট আপ করতে পারেন ( যদি চেক ইন কোডটি বিল্ডটি ভেঙে দেয়, সার্ভার এটি প্রত্যাখ্যান করে), বা আপনি কেবল এটি একটি বাগ তৈরি করতে এবং বিল্ডটি যে ভেঙেছে তাকে এটাকে নিয়োগ করতে পারেন।
আরও কিছু অপশন রয়েছে যা আপনি সবকিছু ভালভাবে রাখার জন্য চালু বা বন্ধ করতে পারেন বা জিনিসগুলি সুন্দর এবং পরিষ্কার রাখতে আপনার টিএফএস-অ্যাডমিনকে পরামর্শ দিতে পারেন ... তবে সেগুলি বেশিরভাগ ক্ষেত্রেই পছন্দ
অভিশপ্ত শব্দগুলি অনুসন্ধান এবং প্রতিস্থাপন করুন ;-)
আপনি যদি উইন্ডোজ থেকে চেক ইন করেন, আপনার কোডটিতে সেই অদৃশ্য ^ এম অক্ষর নেই কিনা তা পরীক্ষা করুন - ইউনিক্সের সম্পাদকরা প্রায়শই ত্রুটি / সতর্কতার কারণ দেয়।
ট্যাবগুলিও প্রতিস্থাপন করুন এবং প্রতিস্থাপন করুন - বিভিন্ন ব্যবহারকারী 4 টি স্পেস, কিছু 8 এবং কোড পঠনযোগ্যতার জন্য ভাল নয় এমন আলাদাভাবে ট্যাবস্টপগুলি দেখবেন।
সেরা পদ্ধতির আইএমএইচও হ'ল একটি পূর্বনির্ধারিত স্ক্রিপ্ট আপনার সংস্থার কোডিং গাইডলাইনগুলির বিরুদ্ধে আপনার কোড পরীক্ষা করা। উত্স নিয়ন্ত্রণ সিস্টেমের লোডগুলির এই কার্যকারিতা রয়েছে।
আমার সংস্থায় আমরা চেক-ইন পর্যালোচনা ব্যবহার করি। এগুলি বিশদ করার দরকার নেই, তবে কাউকে আপনার চেঞ্জলিস্টে ভিন্নতা দেখানো এবং সেগুলির মাধ্যমে কথা বলাই কখনও কখনও টেস্টে আপনি যে অদ্ভুত টাইপটি মিস করেছেন তা হাইলাইট করবে।
আমাদের সোর্স কন্ট্রোল সার্ভার আপনাকে মন্তব্যগুলিতে পর্যালোচনাকারীর নাম উল্লেখ না করে (ফর্ম! আদ্যক্ষর, উদাহরণস্বরূপ! ব্রুস ওয়েইন যদি আপনার পর্যালোচনাটি করে থাকে তবে বিডাব্লু) আপনার চেক ইন করার অনুমতি দেবে না। পর্যালোচক একটি ইমেল পেয়েছে যে তারা পর্যালোচনা করতে সহায়তা করেছে। এটি সুস্পষ্ট শোষণের জন্য উন্মুক্ত তবে এটি বেশ ভালভাবে কাজ করছে বলে মনে হচ্ছে।
যখনই সম্ভব, আমি কাজের আইটেমের সাথে চেক-ইন যুক্ত করতে চাই। এটি আপনাকে WHAT পরিবর্তিত করা হয়েছিল তা নয়, কেন এটি পরিবর্তন করা হয়েছিল সে সম্পর্কে কিছু প্রাসঙ্গিক তথ্য দেয়। টিএফএসের একটি মোটামুটি শালীন কাজের আইটেম ট্র্যাকিং সিস্টেম রয়েছে, তাই এটি চেক-ইন করার সময় করা তুচ্ছ।
(এটি আমার পরিবর্তনের বিভিন্নতা পর্যালোচনা করা ছাড়াও)
একটি ছোট কাজ আমি করি যা আসলে ফাইলগুলি যাচাই করে না check এই ফাইলগুলি অযাচিতভাবে সংশোধন করা হয়েছে, বা রিফ্যাক্টরিংগুলিতে জড়িত থাকতে পারে যা হয় আবার ঘুরিয়ে দেওয়া হয়েছে বা অন্যথায় মোটা করা হয়েছে।
এইভাবে, আপনার পরিবর্তনটি (কোনও কাজের আইটেমের সাথে যুক্ত) কাজের আইটেমটি সন্তুষ্ট করার জন্য প্রয়োজনীয় ফাইলগুলি অন্তর্ভুক্ত করে।
সমস্ত উত্তর এখানে একত্রিত এবং একটি সম্পূর্ণ চেকলিস্ট দিতে
[চেক ইন / চেক আউট] আপনার অন্য যে স্ট্রিমটি কাজ করছে সেটিতে সরাসরি যাচাই করা উচিত নয় You আপনার একটি স্ট্রিম কৌশল থাকা উচিত: উদাহরণস্বরূপ বিকাশকারী প্রতি এমন একটি স্ট্রিম যাতে আপনি অন্যকে বিরক্ত না করে স্বাধীনভাবে চেক ইন করতে পারেন এবং চেক আউট করতে পারেন: আপনার কাজ করবে নিরাপদে থাকুন তবে আপনার নিজস্ব বিকাশ প্রবাহে তাই [কেবলমাত্র আপনার নিজের বিকাশ প্রবাহে]। আপনার প্রতিটি পরীক্ষার সাথে এটি একটি পরিবর্তনের রেকর্ডের সাথে যুক্ত করে রাখুন যাতে আপনার পরিবর্তনগুলি পরিবর্তিত সেট হিসাবে পরিবর্তিত পরিবর্তনের বিরুদ্ধে পারমাণবিক হয় (যাতে আপনি পৃথক আরএফসি / বাগ ইত্যাদি বিতরণ করতে পারেন ... 'সবকিছু সরবরাহ না করে)'।
[তারপরে আপনার টিম স্ট্রিমের সাথে পুনর্বাসনা করুন] এর অর্থ আপনি নিজের স্ট্রিমে অন্যের কাছ থেকে পরিবর্তন পেয়েছেন। অপারেশন চলাকালীন আপনি মার্জ সংলাপে সমস্ত "ডিফস" দেখতে পাবেন এবং সেগুলির মধ্য দিয়ে যেতে পারেন বা যদি সেখানে হাজার হাজার এবং / অথবা আপনি কোড না ব্যবহার করছেন তবে উদাহরণস্বরূপ ডেটা মডেল / সিবেল প্রকল্প ইত্যাদি ... উভয়ের উপর নির্ভর করুন নন তুচ্ছ সংশ্লেষ, তুচ্ছ-স্বয়ংক্রিয় এবং তুচ্ছ ম্যানুয়াল মার্জ, শেষ বিভাগে কঠিন রয়েছে। মনে রাখবেন আপনি এখনও নিজের স্ট্রিমে কাজ করছেন।
[সম্পূর্ণ প্রত্যাবর্তন] যদি সবকিছু ঠিক থাকে তবে আপনি টিম স্ট্রিম থেকে সবেমাত্র যে পরিবর্তনগুলি পেয়েছেন তা পরীক্ষা করে দেখুন: আপনার নিজস্ব স্ট্রিমটি এখন আপ টু ডেট is
[বিতরণ] এখন আপনার কাজ টিম স্ট্রিমে পৌঁছে দিন। যদি আপনি সবকিছু সরবরাহ করতে না চান তবে আপনি উদাহরণস্বরূপ 1 টি নির্দিষ্ট আরএফসির ফাইলগুলির নির্দিষ্ট সংস্করণ বা আরএফসি / সেটগুলির ত্রুটি সমাধানের একটি সেট সহ নির্বাচন করতে পারেন।
[পরীক্ষার বিতরণ] এটি ঠিকঠাক হওয়া উচিত তবে যেহেতু সুযোগটি উপস্থিত রয়েছে যে ইতিমধ্যে বিতরণ করা পরিবর্তনগুলিও রয়েছে: আপনার কাজটি টিম স্ট্রিমের সর্বশেষ পরিবর্তনগুলির সাথে কাজ করে কিনা তা পরীক্ষা করতে পারেন। একই মার্জ সংলাপগুলির সাথে পার্থক্য দেখায়।
[সম্পূর্ণ বিতরণ] আপনার বিতরণ সম্পূর্ণ করুন এবং আপনার কাজ এখন টিম স্ট্রিমে।
এটিকে আরও জটিল করার জন্য: যে কাজটি আপনার বিতরণ করা হয়েছে ঠিক আছে এখনও ঠিক আছে তবে আপনি ইতিমধ্যে আরও একটি সংস্করণে কাজ করছেন আপনার বিতরণ করার পরে সবসময় বেসলাইন করা উচিত এবং এটি চিহ্নিত করুন যে কোন বেসলাইনটি অন্য ব্যবহারকারীদের থেকে পুনর্বাসনের জন্য পছন্দনীয় is । এটি নিশ্চিত করে যে অন্যান্য বিকাশকারীরা প্রস্তাবিত একটি পান এবং স্রোতের সর্বশেষতম সংস্করণটি পাবেন না (যদি আপনি সেই দৃশ্যে কাজ করছেন)। এটিও একটি ট্রিপল চেক যাতে টিম স্ট্রিমের সর্বশেষ সংস্করণগুলি "খারাপ" হলেও তারা অন্যরা যেগুলি পুনঃনির্মাণ করে বা তত্ক্ষণাতিত হয় তা নয় এবং আপনার কনফিগারেশন ব্যবস্থাপকটি পূর্ববর্তী সংস্করণটিকে পূর্ববর্তী সংস্করণটিকে পূর্বাবস্থায় মার্জ করতে পারে না আপনার প্রসব
আপনার উদাহরণে আপনি দিতে পারেন যে আপনি কোড মন্তব্য করতে ভুলে গেছেন। ভুল হয়। চারপাশের কনফিগারেশন ম্যানেজমেন্ট সিস্টেমকে এটির যত্ন নেওয়া উচিত। এটি সত্যিই এক হতে পারে যেমন হাজার হাজার পরিবর্তন আসে এবং সময়মতো বেঁধে রাখা এবং প্রক্রিয়াজাত করা বিভিন্ন সার্ভারের স্ট্রিমগুলির হায়ারার্কিতে "বিল্ড" এবং "সংহতকরণ" ঘটে। এমনকি যদি 5 মাস পরে আপনার মন্তব্যযুক্ত আউট কোডটি একটি ইন্টিগ্রেশন সার্ভারে পরীক্ষা করা হয় কারণ আপনার কোডটি অন্য কোড এবং সিস্টেমের সাথে একীকরণের প্রয়োজন তবে এটি এখনও আপনার পরিবর্তন সেটটি পরমাণুভাবে গ্রহণ করা এবং এখনও চালিয়ে যাওয়া সম্ভব হওয়া উচিত। সুতরাং সেরা অনুশীলনটি কম বেশি বা একটি উচ্চ স্তরের। কনফিগারেশন পরিচালনার স্ট্রিমগুলির সামগ্রিক নকশাকে এটির যত্ন নেওয়া উচিত। পৃথক বিকাশকারীদের জন্য সেরা অনুশীলনটি বৈধতা / ইউনিট পরীক্ষার কোর্স। তবে বড় ছবি থেকে "
নীচের কিছুগুলি আপনার এসসিএমের উপর নির্ভর করে অন্যের চেয়ে বেশি (বা বিভিন্ন আকারে) প্রয়োগ করে, তাই এখানে তারা যায়:
দ্রষ্টব্য : উপরের কিছু আইটেমগুলি বরং সুস্পষ্ট বলে মনে হচ্ছে, তবে আপনি বিশ্বাস করবেন না যে প্রকৃতপক্ষে কত লোক মূল শাখায় কাজ করে বা প্রথমে উত্পাদনে পরিবর্তন করে এবং তারপর ম্যানুয়ালি সংস্করণ নিয়ন্ত্রণে যেতে ডেল্টাস তৈরি করে ... সরাসরি মূল শাখায়। .. এবং লেবেল সহ। ধুয়ে ফেলা পিত্তের মতো মিষ্টি ধোয়া বগলের রসের সাথে মিশে ... হ্যাঁ, এরকমই।
একটি ব্যক্তিগত চেক তালিকা আছে। কোনও এন্ট্রিতে আপনি গণ্ডগোল করার পরে এটি খালি শুরু করুন। এটি দ্বিতীয় প্রকৃতি হয়ে গেলে এটিকে তালিকা থেকে সরান।
পরীক্ষা চালান। যদি তারা উত্তীর্ণ হয় তবে এটি পরীক্ষা করে দেখুন you
আমরা নিম্নলিখিতটি করি ...
পরীক্ষা - আমরা এটি নিশ্চিত হয় তা নিশ্চিত করতে চাই। খুব কমপক্ষে, আমরা জানতে চাই যে এটি কোনও কিছুই ভাঙেনি।
কোড পর্যালোচনা, বা কমপক্ষে একটি বন্ধু পরীক্ষা - জ্ঞানটি চারদিকে ছড়িয়ে পড়ে এবং লোকেরা আপ টু ডেট থাকে তা নিশ্চিত করার এই দুর্দান্ত উপায়। এটি জিনিসগুলি পরীক্ষা করার আগে বাগগুলি ধরতে সহায়তা করে।
অগ্রিম নোটিশ পাঠান - চেকইনের আগে গ্রুপে একটি অগ্রিম নোটিশ পাঠানো হয়। উদ্দেশ্যটি কেবল অন্যদেরকে জানানো নয় যে কোন ফাইল বা ক্ষেত্রগুলি পরিবর্তন হচ্ছে তা নয়, তবে এই পরিবর্তনগুলি প্রভাবিত হওয়ার আশঙ্কা করা হলে এটি তাদের মাথা উঁচু করে (তারা কি নোটিশ গ্রহণ করা বেছে নেওয়া উচিত)।
অগ্রিম নোটিশ পাঠানোর কয়েক ঘন্টা পরে, চেক ইন সম্পন্ন হয় এবং গোষ্ঠীটি ইমেলের মাধ্যমে জানানো হয়। দলের ত্রুটি বা বৈশিষ্ট্যটির নির্দিষ্ট কাজটি কখন করা হবে তা গ্রুপের সবাই জানতে পারে।
চেকিন নোটিশের একটি অনুলিপি বাগ বা বৈশিষ্ট্যের সাথে যুক্ত ফিক্স রেকর্ডে আটকানো হয়। রেকর্ডগুলির মাধ্যমে অনুসন্ধান করার সময়, আমরা দেখতে পেলাম যে ফিক্স / বৈশিষ্ট্যটি কী লিখেছে তা সম্পর্কে ধারণা রাখা খুব সহজ।
আপনার ইউনিট পরীক্ষা চালান আপনি এত পরিশ্রমের সাথে কাজ করছেন। সবুজ ভাল।
সর্বদা, সর্বদা, সর্বদা , আপনি যা কিছু পরিবর্তন করেছেন তা বিল্ডটি ভেঙে না তা পরীক্ষা করুন। বিশেষত ছোটখাটো পরিবর্তন যা তুচ্ছ মনে হতে পারে।
একবার আমি খুব ছোটখাট পরিবর্তন করেছি যা আমি মনে করি না যে আমি উইকএন্ডে কাজ ছাড়ার আগেই কোনও সমস্যা তৈরি করব। নিশ্চিতভাবেই, এই সামান্য পরিবর্তনটি বিল্ডটি ভেঙে দিয়েছে এবং আমাদের প্রকল্পের জন্য কোনও রাতের টেস্ট রান চালানো হয়নি। প্রশ্নোত্তর প্রধান এটি সম্পর্কে খুব খুশি ছিলেন না, এবং ঠিক তাইও।
আপনার পরিবর্তনগুলির অংশগুলি সন্ধান করুন যা একক ইউনিট হিসাবে যেতে পারে।
প্রায়শই, আমার কোডে ওয়ার্কিং ফিক্স বা বর্ধনের সময়, বেশ কয়েকটি পরিবর্তন রয়েছে। তাদের মধ্যে কিছু আচরণের পরিবর্তনের জন্য নির্দিষ্ট যা আমি যাচ্ছি; অন্যরা হ'ল সেই পরিবর্তনকে আরও পরিষ্কার করতে আমি যা করেছি।
আমি প্রতিটি রিফ্যাক্টরিং এর নিজস্ব পরিবর্তনের বর্ণনা সহ পৃথকভাবে চেক করতে পছন্দ করি:
প্রতিক্রিয়া: এক্স থেকে Y এর নাম পরিবর্তন করুন
এক্স এর আগে বোঝা গেল কারণ ... তবে এখন এটি ওয়াই হওয়া উচিত This এটি # 9 ইস্যুটির সাথে সম্পর্কিত।
তারপরে, প্রতিটি ভাল রিফ্যাক্টরিং একবার চেক ইন করা হলে চূড়ান্ত আচরণ পরিবর্তনটি প্রায়শই তুচ্ছ।
এছাড়াও, কিছু পরিবর্তন কোডের অনেকগুলি লাইনকে প্রভাবিত করে তবে খুব আকর্ষণীয় নয়, অন্য পরিবর্তনগুলি খুব স্থানীয় হয় তবে একটি গুরুত্বপূর্ণ প্রভাব থাকে। যদি এই পরিবর্তনগুলি একসাথে চেক করা হয়, তবে ভিন্নতাগুলি পড়া খুব কঠিন। সুতরাং, আমি তাদের আলাদা রাখি।
পরবর্তীতে, কেউ যখন পরিবর্তনের ইতিহাসটি পড়ছেন, তখন বিষয়গুলি কীভাবে বর্তমান অবস্থার কাছে পৌঁছেছে এবং কেন তারা এইভাবে রয়েছে তা স্পষ্ট। এটি আমার আচরণের পরিবর্তনটিকে পূর্বাবস্থায় ফিরিয়ে আনার ক্ষেত্রেও তুচ্ছ কারণ এটি অনেকগুলি অন্যান্য সম্পাদনার সাথে জড়িত নয়।
কারও কাছ থেকে ধার করা কিছু ফেরত দেওয়ার সময় আপনি যা করবেন তা করুন। এটি পরিষ্কার এবং ভাল আকারে আছে তা নিশ্চিত করুন। আপনি যদি কোনও গোলযোগ করেছেন তবে কোডটিকে তার মালিকের কাছে ফিরিয়ে দেওয়ার আগে অবশ্যই পরিষ্কার করবেন (বেশিরভাগ ক্ষেত্রে, আপনার নিয়োগকর্তা)।
আমি আমার কাজের জন্য একটি স্থানীয় এইচজি রেপো রাখি।
আমি দাবি করি না যে এগুলি সেরা, তবে তারা আমার পক্ষে কাজ করে।
আপনি যুক্ত বা পরিবর্তিত সমস্ত কিছু ভালভাবে পরীক্ষা করুন। চেষ্টা করার মতো প্রতিটি ক্ষেত্রেই চেষ্টা করে দেখুন। পরীক্ষার প্রশ্নোত্তর ছেড়ে যাবেন না। আমি যদি প্রতিবারের জন্য স্যান্ডউইচটি রাখি তবে আমি কিছুটা ছোটখাটো পরিবর্তন করেছি, এবং তারপরে নিরাপদ দিকে থাকার জন্য কিছু পরীক্ষার কেস চেষ্টা করেছি এবং তাত্ক্ষণিকভাবে সমস্যাগুলি দেখেছি, আমার প্রচুর স্যান্ডউইচ হবে। আমি সাধারণত নিজেকে উচ্চস্বরে বলে থাকি "আমি সত্যিই খুশি যে চেষ্টা করেছিলাম ..."
আপনি বলেছেন যে ইউআই আপনার পরিবর্তনের পরে অদ্ভুত হয়ে উঠল। আপনি যদি কেবল প্রোগ্রামটি চালিয়ে যান এবং চেক ইন করার আগে ইউআইয়ের দিকে তাকান, আপনি কি সমস্যাটি লক্ষ্য করবেন?