আমি কেন "রিমোট-ট্র্যাকিং শাখা 'উত্স / বিকাশ' বিকাশে পরিণত করছি?


125

আমি আমার সংস্থার একমাত্র ব্যক্তি যিনি নিম্নলিখিত বার্তাটি দিয়ে কমিট করছেন:

রিমোট-ট্র্যাকিং শাখা 'উত্স / বিকাশ' বিকাশে মার্জ করুন

এগুলি নিশ্চিত করার জন্য আমি কী করছি তা নিশ্চিত নয় তবে আমি থামতে চাই।

এই প্রতিশ্রুতি তৈরি করার জন্য আমি কোন আদেশ জারি করছি, এবং এটি তৈরি না করার জন্য আমার যথাযথ আদেশটি কী ব্যবহার করা উচিত?


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

আপনার git pull --autostash --rebaseজন্য কাজ করে? জোজনজাহান?
সোসিডেলিকা

উত্তর:


206

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

ভবিষ্যতে এই মার্জ কমিটগুলি কীভাবে এড়ানো যায়

আপনি git pull --rebaseভবিষ্যতে এটি থেকে রোধ করতে ব্যবহার করতে পারেন , তবে রিবাইজিংয়ের বিপদ রয়েছে এবং আমি pullপুরোপুরি এড়াতে পরামর্শ দিই

পরিবর্তে, আমি আপনাকে এই ব্যবহারের ধরণটি অনুসরণ করতে উত্সাহিত করি:

# download the latest commits
git remote update -p

# update the local branch
git merge --ff-only @{u}

# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}

ব্যাখ্যা

  • git remote update -pদূরবর্তী সংগ্রহস্থলের সমস্ত কমিট ডাউনলোড করে এবং রিমোট ট্র্যাকিং শাখাগুলি আপডেট করে (যেমন, origin/master)। এটি আপনার কার্যকারী ডিরেক্টরি, সূচক বা স্থানীয় শাখাগুলি স্পর্শ করে না।

    -pযুক্তি আলুবোখারা মূল প্রজেক্টের শাখা মোছা হয়েছে। সুতরাং, যদি fooশাখাটি originভাণ্ডারে মুছে ফেলা হয় তবে git remote update -pস্বয়ংক্রিয়ভাবে আপনার origin/fooরেফ মুছে যাবে ।

  • git merge --ff-only @{u}গিটকে প্রবাহিত শাখা ( @{u}যুক্তি) আপনার স্থানীয় শাখায় একীভূত করতে বলে তবে কেবল যদি আপনার স্থানীয় শাখাটি উজানের শাখায় "দ্রুত ফরোয়ার্ড" করা যায় (অন্য কথায়, যদি এটি ডাইভার্জ না করা থাকে)।

  • git rebase -p @{u}আপনার করা কমিটগুলি কার্যকরভাবে সরানো হয়েছে তবে এখনও পর্যন্ত উজানের শাখার শীর্ষে ঠেলে দেওয়া হয়নি, যা আপনি এড়াতে চাইছেন এমন নির্লিপ্ত মার্জ কমিট তৈরির প্রয়োজনীয়তা দূর করে। এটি বিকাশের ইতিহাসের রৈখিকতার উন্নতি করে, পর্যালোচনা করা আরও সহজ করে তোলে।

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

    সাবধানতা : git rebaseআপনি যা আশা করছেন তা নাও করতে পারে, তাই চাপ দেওয়ার আগে ফলাফলগুলি পর্যালোচনা করুন। উদাহরণ স্বরূপ:

    git log --graph --oneline --decorate --date-order --color --boundary @{u}..
    

আমি git pull --rebaseনিম্নলিখিত কারণে এই পদ্ধতির চেয়ে বেশি পছন্দ করি :

  • এটি আপনার ইতিহাস সংযুক্ত করার আগে আপনার আগত প্রবাহের কমিটগুলি দেখার অনুমতি দেয় its
  • এটি আপনাকে -p( --preserve-merges) বিকল্পটি পাস করার অনুমতি দেয় git rebaseযদি আপনি ইচ্ছাকৃতভাবে মার্জটি পুনরায় চালু করতে চান (উদাহরণস্বরূপ, ইতিমধ্যে ধাক্কা দেওয়া বৈশিষ্ট্য শাখায় মার্জ করা master)।

সংক্ষিপ্ত: git upপরিবর্তেgit pull

উপরের কাজটি করা সহজ করার জন্য, আমি একটি উপনাম নামকটি তৈরি করার পরামর্শ দিচ্ছি up:

git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

এখন আপনার শাখাটি আপ টু ডেট করার জন্য আপনার যা করা দরকার তা হ'ল:

git up

পরিবর্তে git pull। আপনার স্থানীয় শাখাটি উজানের শাখা থেকে সরে যাওয়ার কারণে যদি আপনি একটি ত্রুটি পান তবে এটি আপনার পুনর্বাসনের প্রতিশ্রুতি।

না কেন git pull --rebase?

দৌড়াদৌড়ি অনুসরণ git pull --rebaseকরা চলমান সমান । এটি নতুন প্রবাহের কমিটগুলিতে দ্রুত এগিয়ে যাওয়ার চেষ্টা করে, তবে যদি এটি সম্ভব না হয় তবে এটি আপনার স্থানীয় প্রতিশ্রুতিগুলি নতুন প্রবাহের কমিটগুলিতে প্রত্যাবর্তন করবে। এটি সাধারণত ঠিক থাকে তবে সতর্কতা অবলম্বন করুন:git fetchgit rebase

  • রিবেস একটি উন্নত বিষয়, এবং আপনার ছাড় দেওয়ার আগে এর অর্থগুলি বোঝা উচিত।
  • git pull --rebaseপ্রতিশ্রুতিগুলি অন্তর্ভুক্ত করার আগে আপনাকে তা পরীক্ষা করার সুযোগ দেয় না। কি মূল প্রজেক্টের পরিবর্তিত উপর নির্ভর করে, এটা বেশ সম্ভব যে রি-বেসের ফলে ভুল অপারেশন-একটি হল rebase --onto, merge, reset, অথবা push -fএকটি প্লেইন চেয়ে বেশি উপযুক্ত হতে পারে rebase
  • --preserve-mergesরিবেস অপারেশনে পাস করা (বর্তমানে) সম্ভব নয় , সুতরাং বৈশিষ্ট্য শাখার যে কোনও ইচ্ছাকৃতভাবে সংহতকরণ বৈশিষ্ট্যযুক্ত শাখার সমস্ত কমিটকে পুনরায় খেলানো (এবং এভাবে ডুপ্লিকেট করা) করা হবে।

দ্বারা নির্মিত একটি বিদ্যমান মার্জ কমিট "ফিক্সিং" git pull

যদি আপনি এখনও দ্বারা নির্মিত কোনও মার্জ কমিটিকে ধাক্কা না দিয়ে থাকেন তবে আপনি মার্জ git pullকমিটটি পুনরায় চালু করতে পারেন। ধরে নিই যে আপনি কোনও ইচ্ছাকৃত মার্জ করেন নি (যেমন, আপনার বর্তমান শাখায় ইতিমধ্যে ধাক্কা দেওয়া বৈশিষ্ট্য শাখাটি মার্জ করা), নিম্নলিখিতটি করা উচিত:

git rebase @{u}

উপরের কমান্ডটি গিটকে HEAD(বর্তমান প্রতিশ্রুতি) থেকে প্রাপ্ত অ-মার্জ কমিটগুলি সমস্ত নির্বাচন করতে বলেছে , যে সমস্ত কমিটগুলি @{u}"আপস্ট্রি শাখা" এর জন্য সংক্ষিপ্ত, অর্থাৎ origin/masterযদি HEADহয় master), পুনরায় খেলুন (চেরি-পিক) ) এগুলি উজানের শাখার শীর্ষে রাখুন এবং তারপরে বর্তমান শাখার রেফারেন্সটি কমিটগুলি পুনরায় খেলানোর ফলাফলের দিকে নির্দেশ করুন। এটি কার্যকরভাবে অ-মার্জ কমিটিকে সাম্প্রতিকতম প্রবাহের প্রতিশ্রুতিতে স্থানান্তরিত করে, যা দ্বারা নির্মিত মার্জটিকে দূর করে git pull

আপনার যদি ইচ্ছাকৃত মার্জ কমিট থাকে তবে আপনি দৌড়াতে চান না git rebase @{u}কারণ এটি অন্য শাখা থেকে সমস্ত কিছু রিপ্লে করবে। এই ক্ষেত্রে মোকাবেলা করা যথেষ্ট পরিমাণে জটিল, এ কারণেই এটি পুরোপুরি ব্যবহার করা git upএবং এড়ানো ভাল git pull। আপনার resetদ্বারা তৈরি করা মার্জটিকে পূর্বাবস্থায় ফেলার জন্য আপনাকে সম্ভবত ব্যবহার করতে হবে pullএবং তারপরেও করবেন git rebase -p @{u}। আমার -pপক্ষে git rebaseনির্ভরযোগ্যভাবে কাজ না করার যুক্তি , যাতে আপনি resetইচ্ছাকৃত মার্জটি পূর্বাবস্থায় ফেরাতে, আপনার স্থানীয় শাখায় আপডেট করতে @{u}এবং ইচ্ছাকৃত মার্জটি পুনরায় করতে চান (যা প্রচুর লোমশ একত্রিত হলে ব্যথা হয়) দ্বন্দ্ব)।


প্রিফারিজ-মার্জগুলি নিয়ে আলোচনার জন্য +1, আপনি যে কমান্ডে তাকে চালনার জন্য বলেছিলেন সেটিতে আপনি আসলে দলিল করেননি, সুতরাং এর জন্য -1।
শেঠ রবার্টসন

@ শেঠ: মন্তব্যের জন্য ধন্যবাদ; আমি সুপারিশ উত্তর উত্তর -p। আমি এর আগে এটি সুপারিশ করা এড়িয়ে গিয়েছিলাম কারণ এটি খুব বেশি প্রয়োজন হয় না এবং এর আচরণটি ভালভাবে নথিভুক্ত হয় না।
রিচার্ড হানসেন

3
কি আইডি মধ্যে পার্থক্য git remote update -pএবং git fetch?
12:53

3
@eckes: git remote update -pহিসাবে একই git fetch --all -pgit remote update -pযখন বিকল্প fetchছিল না তখন ফিরে ব্যবহার করার অভ্যাস পেয়েছিলাম -p
রিচার্ড হ্যানসেন

1
@ ব্যবহারকারী ১৯১14 69 2২: একবার মার্জ সম্পূর্ণ হয়ে গেলে গিট স্থানীয় শাখাকে নতুনভাবে তৈরি করা মার্জ কমিটকে নির্দেশ করবে, দূরবর্তী শাখার মতো একই প্রতিশ্রুতিতে নয়। এই নতুন মার্জ কমিট হ'ল সমস্যা, বিশেষত যখন ধাক্কা দেওয়া হয়।
রিচার্ড হ্যানসেন

18
git fetch
git rebase origin/master

যা করা উচিৎ. বা আপনি যদি টানা ব্যবহার চালিয়ে যেতে চান তবে

git pull --rebase

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

git pull

এই পৃষ্ঠার "মেশিনের পরিবর্তে রিবেসের সাথে টানুন" বিভাগে এটি আরও:

http://mislav.uniqpath.com/2010/07/git-tips/

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