আমি কখন গিট টান --rebase ব্যবহার করব?


805

আমি এমন কিছু লোককে জানি যারা git pull --rebaseডিফল্টরূপে ব্যবহার করে এবং অন্যরা যারা কখনও এটি ব্যবহার না করার জন্য জোর দেয়। আমি বিশ্বাস করি যে আমি মার্জ এবং রিবেসিংয়ের মধ্যে পার্থক্য বুঝতে পেরেছি, তবে আমি এটিকে প্রসঙ্গে রাখার চেষ্টা করছি git pull। এটি কি কেবলমাত্র প্রচুর সংহত প্রতিশ্রুতিবদ্ধ বার্তাগুলি দেখার ইচ্ছে না বা অন্য কোনও সমস্যা রয়েছে?


1
গিট টান --rebase বিরুদ্ধে পরামর্শ লোকদের জন্য উত্স ? রিবেস বা গিট রিবেস গিট টান --rebase থেকে পৃথক ক্রিয়াকলাপ !
przemo_li

উত্তর:


583

আপনি git pull --rebaseযখন ব্যবহার করা উচিত

  • আপনার পরিবর্তনগুলি পৃথক শাখার প্রাপ্য নয়

আসলে - তাহলে কেন নয়? এটি আরও স্পষ্ট, এবং আপনার কমিটগুলিতে যৌক্তিক দলবদ্ধকরণ চাপায় না।


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

যাইহোক, কখনও কখনও - যে কোনও কারণেই - আপনি ভাবেন যে এই দুটি - দূরবর্তী এবং স্থানীয় - যদি একটি শাখা হত তবে এটি ভাল হত । এসভিএন-তে লাইক দিন। এটি এখানেই git pull --rebaseখেলতে আসে। আপনি আর মার্জ করবেন না - আপনি আসলে দূরবর্তী শাখার শীর্ষে প্রতিশ্রুতিবদ্ধ । এটি আসলে এটি সম্পর্কে।

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


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

11
টান দিয়ে স্বয়ংক্রিয়ভাবে পুনর্বাসনের জন্য গিট সেট আপ করা একটি দরকারী সেরা অনুশীলন git config --global pull.rebase preserve (স্থানীয়ভাবে স্থানীয়ভাবে কিছু করা থাকলে মার্জগুলি সংরক্ষণ করার চেষ্টা করার জন্য রিবেসিং সক্ষম করার পাশাপাশি সংরক্ষণ করুন)।
কলিন ডি বেনেট

2
আমি একমত নই যে আপনি কেবল একটি শাখায় কাজ করার সময় টান --rebase ব্যবহার করা উচিত। অন্য কোনও পরিস্থিতিতে অসম্ভব না হলে আপনার সর্বদা এটি ব্যবহার করা উচিত।
টোম ফেজেফার

@ পি শেভড ... 'তবে, কখনও কখনও - যে কোনও কারণেই - আপনি মনে করেন যে এই দুটি - প্রত্যন্ত এবং স্থানীয় - একটি শাখা থাকলে আসলে এটি আরও ভাল হত "... এটি করা যেতে পারে? স্থানীয় পরিবেশে, আমি আমার শাখা এবং উত্স / মাস্টার হিসাবে একটি দূরবর্তী শাখার আয়না পেতে পারি। আপনি কি এখানে ইনপুট সরবরাহ করতে পারেন?
ম্যান্ড্রয়েড

736

"গিট পুল --রেবাস" আসলে কী বোঝায় সে সম্পর্কে আমি একটি ভিন্ন দৃষ্টিভঙ্গি সরবরাহ করতে চাই, কারণ এটি কখনও কখনও হারিয়ে যায় বলে মনে হয়।

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

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

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

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

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

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


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

1
আপনি কি বলছেন যে এক না করা উচিত git config --global branch.autosetupmerge always?
মার্সেলো ক্যান্টোস

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

9
+1 @ এসকোড। রিবেস / মার্জ প্রশ্নটি নিয়ে বেশ কয়েক ঘন্টা বেদনাদায়ক ঝুঁকির পরে, অবশেষে এখানে একটি উত্তর এসেছে যা এটি নখ করে।
AgileYogi

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

211

সম্ভবত এটি ব্যাখ্যা করার সর্বোত্তম উপায়টি একটি উদাহরণ সহ:

  1. এলিস টপিক শাখা এ তৈরি করে এবং এতে কাজ করে
  2. বব সম্পর্কহীন বিষয় শাখা বি তৈরি করে এবং এতে কাজ করে
  3. অ্যালিস করে git checkout master && git pull। মাস্টার ইতিমধ্যে আপ টু ডেট।
  4. বব করেন git checkout master && git pull। মাস্টার ইতিমধ্যে আপ টু ডেট।
  5. অ্যালিস করে git merge topic-branch-A
  6. বব করেন git merge topic-branch-B
  7. git push origin masterঅ্যালিসের আগে বব করেন
  8. অ্যালিস করেন git push origin master, যা প্রত্যাখ্যান করা হয়েছে কারণ এটি দ্রুত-ফরোয়ার্ড মার্জ নয়।
  9. অ্যালিস উত্স / মাস্টারের লগটি দেখেন এবং দেখেন যে প্রতিশ্রুতি তার সাথে সম্পর্কিত নয়।
  10. অ্যালিস করে git pull --rebase origin master
  11. অ্যালিসের মার্জ কমিট অযৌক্তিক, ববের প্রতিশ্রুতি টানা হয় এবং অ্যালিসের কমিট ববয়ের প্রতিশ্রুতিবদ্ধতার পরে প্রয়োগ করা হয়।
  12. অ্যালিস তা করেন git push origin masterএবং সকলেই খুশি হন যখন তারা ভবিষ্যতে লগগুলিতে তাকান তখন তাদেরকে একটি অকেজো মার্জ কমিট পড়তে হবে না।

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


2
খুশী হলাম। আমি স্পষ্ট git co master && git pull; git checkout topic-branch-A; git rebase master; git checkout master; git merge topic-branch-A; git push origin masterহয়ে ওঠার প্রবণতা পোষণ করি যদি আমার আগে মাস্টারকে অন্যের ধাক্কা ঘটে। যদিও আমি আপনার রেসিপিটিতে সাসিনেক্ট সুবিধাগুলি দেখতে পাচ্ছি।
হ্যাঙ্ককা

সুন্দর ব্যাখ্যা @ কোডি পোল
রজনীকান্ত প্রধান

148

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

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

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

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


2
নিশ্চয়ই লগ থেকে মার্জ
কমিটগুলি


9
@ হাসেন জে হ্যাঁ, তবে এই
সংশ্লেষগুলির

এই উত্তরটি নির্বাচিত উত্তরের তুলনায় অস্পষ্ট এবং মতামতযুক্ত: "একই শাখা" বলতে কী বোঝায়? কিছু ভাল পয়েন্ট রয়েছে, যেগুলি নির্বাচিত উত্তরে নেই।
5'11

1
"শাখা" এর আশেপাশে অস্পষ্টতা বেশ ইচ্ছাকৃত, যেহেতু রেফ ব্যবহার করার অনেকগুলি উপায় রয়েছে; "কাজের লাইন" কেবল একটি বিকল্প।
ক্রোসনভোল্ড

49

আমি মনে করি না যে ব্যবহার না করার কোনও কারণ আছে pull --rebase- আমি গিটকে বিশেষভাবে কোড যুক্ত করেছি যাতে আমার git pullকমান্ডটি সর্বদা উজানের কমিটির বিরুদ্ধে পুনরায় শোধ করতে দেয় ।

ইতিহাসের সন্ধানের সময়, কখনই বৈশিষ্ট্যটিতে কাজ করা লোক / গাল সমন্বয়সাধন বন্ধ করে দেয় তা জানা কখনই আকর্ষণীয় হবে না। যখন সে / সে এটি করছে তখন এটি ছেলে / মেয়েটির পক্ষে কার্যকর হতে পারে তবে এটি তার reflogজন্য। এটি কেবল অন্য সবার জন্য শব্দ যোগ করছে।


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

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

4
যদি pull --rebaseসর্বদা ব্যবহার করা উচিত তবে pullএটি ডিফল্টরূপে কেন করে না ?
স্ট্র্যা

2
আমি ভীত আপনার নিজের মতামত তৈরি করতে হবে। .gitconfigঅপশনগুলির মধ্যে কিছু সঠিক জিনিস করানোর জন্য আমার বেশ কয়েকটি জিনিস রয়েছে। আমি মনে করি গিট রিবেসে ডিফল্টরূপে ভুল কাজ করে, যেমন গিট ট্যাগ ইত্যাদি ...
ডাস্টিন

8
এটি যদি আপনি "উজান" থেকে টানেন, তবে বলুন masterএবং আপনি যে শাখায় টানছেন সেগুলি সর্বজনীন হয়নি (এখনও) good আপনি যদি অন্যদিকে কোনও বৈশিষ্ট্য শাখা থেকে অন্য দিকে টানেন তবে masterএটি আরও অন্যান্য উপায়ে যেমন: ব্যবহারের কোনও কারণ --rebaseনেই, তাই না? এটি ডিফল্ট না হওয়ার কারণ হতে পারে। আমি খুঁজে পেয়েছি যে রিবেসগুলি হায়ারার্কির শীর্ষ থেকে নীচের দিকে যেতে হবে এবং মার্জগুলি কীভাবে তারা উপরের দিকে প্রবাহিত হবে। derekgourlay.com/blog/git-when-to-
নিম-

38

শুধু মনে রাখ:

  • টান = আনয়ন + মার্জ করুন
  • টান --rebase = আনতে + পুনরায়

সুতরাং, আপনি কীভাবে আপনার শাখা পরিচালনা করতে চান তা চয়ন করুন।

মার্জ এবং রিবেসের মধ্যে পার্থক্যটি আপনি আরও ভালভাবে জানতে চাইবেন :)


9

আমি মনে করি এটি ব্যক্তিগত পছন্দকে উসকে দেয়।

আপনি কি আপনার পরিবর্তনগুলি ঠেকানোর আগে নিজের নির্বোধ ভুলগুলি আড়াল করতে চান? যদি তাই হয়, git pull --rebaseনিখুঁত। এটি আপনাকে পরে আপনার কয়েকটি (বা এক) কমিটের স্কোয়াশ করতে দেয়। যদি আপনার (চাপানো) ইতিহাসে মার্জ হয়ে থাকে তবে পরবর্তী কোনও কাজ করা এত সহজ নয় git rebase

আমি ব্যক্তিগতভাবে আমার সমস্ত মূর্খ ভুল প্রকাশ করতে আপত্তি করি না, তাই আমি রিবেসের পরিবর্তে মার্জ হয়ে যাই tend


8
এই প্রশ্নটি প্রত্যেকে দেখার জন্য নোট করুন: এই উত্তরটি প্রশ্নের সাথে সম্পূর্ণ অপ্রাসঙ্গিক "আমি কখন গিট টান --rebase ব্যবহার করব?"
Therealklanni

3
@ থেরিয়ালক্লান্নি আমি উত্তরটি সম্পাদনা করেছি যাতে এটি প্রশ্নের সাথে কীভাবে প্রাসঙ্গিক হয় তা স্পষ্ট হয়ে যায় (আশা করি উদ্দেশ্যটি বিনষ্ট না করে)।
পাওলো ইবারম্যান

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

8

git pull --rebaseকোনও সহযোগীর কাছ থেকে পুনর্লিখনের ইতিহাস লুকিয়ে রাখতে পারে git push --force। আমি git pull --rebase কেবল তখনই ব্যবহার করার পরামর্শ দিচ্ছি যদি আপনি জানেন যে আপনি অন্য কারওরকম আচরণ করার আগে আপনি নিজের প্রতিশ্রুতিগুলি চাপতে ভুলে গেছেন।

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

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