আমি কি জন্য গিট-ওয়ার্ক্রিট্রি ব্যবহার করব?


211

আমি গিট-ওয়ার্কট্রি-তে গিথুবের পোস্টটি পড়েছি । তারা লিখে:

মনে করুন আপনি featureযখন একটি উচ্চ-তাত্পর্যপূর্ণ বাগটি রিপোর্ট করেছেন তখন ডাকা একটি শাখায় একটি গিট সংগ্রহস্থলে কাজ করছেন master। প্রথমে আপনি একটি নতুন শাখা দিয়ে একটি লিঙ্কযুক্ত কার্যকারী গাছ তৈরি করুন, hotfixমাস্টারের তুলনায় চেক আউট […] আপনি বাগটি ঠিক করতে পারেন, হটফিক্স পুশ করতে পারেন এবং একটি টানার অনুরোধ তৈরি করতে পারেন।

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

অন্যদিকে, গিট-ওয়ার্ক্রিট্রি ব্যবহারের নিজস্ব সীমাবদ্ধতা রয়েছে:

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

ইতিমধ্যে সমস্যার সমাধানের জন্য কেন আমি আরও জটিল ওয়ার্কফ্লো বেছে নেব?

এর আগে এমন কিছু করা যায় না git-worktreeযা পুরো নতুন, জটিল বৈশিষ্ট্যটিকে ন্যায়সঙ্গত করে?


12
আপনি যে জিনিস আটকে রাখতে পারবেন না তা হ'ল নিমজ্জিত পাথগুলি, সংশ্লেষের সাথে একত্রীকরণ বা পুনর্বাসনের পরে।
চিরলু

11
আপনি যদি একটি সংকলিত ভাষা নিয়ে কাজ করেন তবে স্ট্যাশিংয়ের অর্থ আপনি যখন স্টেস্টেস্ট করছেন না তখন আপনাকে সমস্ত কিছু পুনরায় কম্পাইল করতে হবে।
এমবি 14

আমাদের একই (300 এমবি) উত্স কোডের উপর ভিত্তি করে বিভিন্ন পণ্য রয়েছে এবং আমি এগুলি সমস্ত এক বৃহত রেপোতে একত্রিত করার পরিকল্পনা করছি এবং প্রতিটি পণ্যকে বিশাল একগুচ্ছের চেয়ে আলাদা ফোল্ডারে চেক আউট রাখতে ওয়ার্কট্রি ব্যবহার করব planning যে ক্লোনগুলি সিঙ্কে থাকে না
এন্ডোলিথ

উত্তর:


196

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

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

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


4
আপনাকে বেশ কয়েকবার রেপো থেকে একই পরিবর্তন আনতে হবে না। আপনি প্রথম ক্লোনটির .git ডিরেক্টরিটি অনুলিপি করতে পারতেন।
Misiu_mp

1
@ jdk1.0 বিভ্রান্তির জন্য দুঃখিত, মন্তব্যটি মিসআই_এমপি
এমএসটিটি

2
যে কেউ কেউ ৩-৪ টি উচ্চ প্রতিলিপিযুক্ত রেপ ব্যবহার করেছেন যাতে আমি অন্যের বিকাশের সময় একটি বৈশিষ্ট্য শাখা তৈরি করতে পারি, আমার প্রতিটি স্থানীয় রেপো অন্যের রিমোট হিসাবে ছিল এবং আমি সেবি'র ডাউনসাইডের বৈশিষ্ট্যগুলির সাথে সম্পূর্ণ সম্মত (প্রচুর আনয়ন এবং ঠেলাঠেলি! ) এছাড়াও, একবার আমি ওয়ার্কট্রিতে স্যুইচ করলে আমি জড় করি যে আমাকে স্থানীয়, একই নামযুক্ত শাখাগুলি ডাইভারিংয়ের বিষয়ে আর চিন্তা করতে হবে না (যা প্রতি 6-10-10 মাস পরে একবারে একাধিকবার বাধা হয়ে যাওয়ার পরে এবং কয়েক দিন ধরে শেষ হয়ে যায়) happens একাধিক Repos বাইরে একই বৈশিষ্ট্য শাখা কাজ, কিন্তু তাদের ব্যাক আপ সিঙ্ক করতে ভুলবেন ...)
ঋষি

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

5
@ iheanyi - (২) সময়ের সাথে সাথে, কোনও নির্দিষ্ট সময়ে কাজের গাছের ফাইলগুলির চেয়ে সমস্ত কিছুর ইতিহাস আরও বড় হবে। সমস্ত কিছুর ইতিহাস == .gitডিরেক্টরি। প্রবাহ থেকে অনেক স্থানীয় ক্লোন সহ, আপনার কাছে একই ডাটাবেসের অনেকগুলি স্থানীয় অনুলিপি রয়েছে, যেহেতু প্রতিটি ক্লোনটির নিজস্ব .gitডাটাবেস রয়েছে। অনেক স্থানীয় কাজের গাছের সাথে প্রতিটি গাছ একই .gitডাটাবেস ব্যবহার করে। হ্যাঁ, যদি আপনার স্থানীয় ওয়ার্কট্রি এর স্থানীয় ক্লোন থাকে তবে গিট অনেকগুলি .git বিষয়বস্তুকে হার্ড-লিঙ্ক করবে, তবে উইন্ডোজে নয়।
স্টিভ হলশ

70

আমি এর জন্য কিছু ব্যবহার দেখতে পাচ্ছি।

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

সুতরাং git-worktreeআমি সেখানে একটি দ্বিতীয় শাখা কাজ করার জন্য অন্য একটি ধারণা চালু করতে পারে।

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

তৃতীয় ব্যবহারের ক্ষেত্রে দুটি সরঞ্জামের পরিবর্তে দুটি ডিরেক্টরিতে দুটি ডিরেক্টরিতে git-diffস্বাভাবিকের চেয়ে অন্যান্য সরঞ্জাম ব্যবহার করে ফাইল তুলনা করা diff


6
git cloneএই সমস্ত জন্য ঠিক ঠিক কাজ করবে না ?
জেথিল

12
এটি কিন্তু রিমোট থেকে একটি বড় সংগ্রহস্থলের ক্লোনিং করতে অনেক সময় নিতে পারে। আমি এমন একটি সংগ্রহস্থলের বিরুদ্ধে কাজ করছি যা ক্লোন করতে কয়েক মিনিট সময় নেয়। আমার ধারণা আপনি এটি দিয়ে করতে পারতেন git clone --reference। এছাড়াও, অন্যান্য সমস্ত শাখার পরিচালনা প্রতি কার্য ডিরেক্টরি একবারের পরিবর্তে একবার করা হবে।
আন্দ্রেয়াস বিদারব্রান্ড

6
দূরবর্তী থেকে ক্লোন করবেন না, আপনার স্থানীয় থেকে ক্লোন করুন। আমি শাখা-পরিচালনার বিষয়টি বুঝতে পারছি না, আপনি কি পরিষ্কার করতে পারবেন?
jthill

14
আমি ক্লোন ব্যবহার করার চেষ্টা করেছি, এবং সত্যিই একটি ব্যবস্থাপনা সমস্যা আছে। একক শাখার পরিবর্তে আমার কাছে ক্লোনগুলির একটি সেট রয়েছে, যা আমি একত্রে ইউআইতে একসাথে দেখতে পাচ্ছি না। যদি আমাকে চেরি-বাছাই করতে হয় তবে এগুলি চারপাশে আনতে বা ধাক্কা দিতে হবে। এটি সমস্ত ক্রিয়াকলাপে অতিরিক্ত পদক্ষেপ যুক্ত করে। সবকিছু করণীয়, তবে সবসময় কিছুটা ঘর্ষণ থাকে।
সর্বাধিক 630

2
এবং যখন ব্যাকআপ সেটআপ করার বিষয়টি আসে তখন একক সংগ্রহস্থলটি এত সহজ।
সর্বাধিক 630

64

একটি সুস্পষ্ট ব্যবহার হ'ল একই সাথে বিভিন্ন সংস্করণের আচরণের (উত্স নয়) তুলনা করা - উদাহরণস্বরূপ কোনও ওয়েব সাইটের বিভিন্ন সংস্করণ বা কেবল একটি ওয়েব পৃষ্ঠার।

আমি স্থানীয়ভাবে এটি চেষ্টা করেছিলাম।

  • একটি ডিরেক্টরি তৈরি করুন page1

  • ভিতরে ডিরেক্টরি srcএবং git initএটি তৈরি করুন ।

  • মধ্যে srcতৈরি page1.htmlএকটু কন্টেন্ট সঙ্গে এবং এটি কমিট।

  • $ git branch ver0

  • $ git worktree add ../V0 ver0

  • মধ্যে srcমাস্টার আরো টেক্সট যোগ page1.htmlএবং এটি কমিট।

  • $ git branch sty1

  • সম্পাদন করা page1.htmlমধ্যে sty1শাখা (কিছু স্বাতন্ত্র্যসূচক CSS স্টাইল যোগ করুন) এবং এটি কমিট যোগ করুন।

  • $ git worktree add ../S1 sty1

আপনি এখন একসাথে এই 3 টি সংস্করণ খুলতে এবং দেখতে একটি ওয়েব ব্রাউজার ব্যবহার করতে পারেন:

  • ..\page1\src\page1.html // গিটের বর্তমান হিসাবে যা আছে

  • ..\page1\V0\page1.html // প্রাথমিক সংস্করণ

  • ..\page1\S1\page1.html // পরীক্ষামূলকভাবে স্টাইল করা সংস্করণ


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

@ iheanyi আপনি একই সম্পর্কে বলতে পারেন branch; উত্তরটিও একই: এটি হালকা ওজন এবং কাজের জন্য তৈরি।
ওজেফোর্ড

1
@ ওজেফোর্ড যে বিন্দু বিন্দু। এই উত্তরটি আমাকে বোঝায় না যে ওয়ার্ক্রিট্রি কী আলাদা। এটি সম্ভবত শাখা বা ক্লোনটির জন্য একটি উপনাম নয় তবে আমি যে প্রভাবটি এখানে দেখছি তা একই বলে মনে হচ্ছে। আমি দেখতে পাচ্ছি না যে এটি কেবল শাখা বা ক্লোন ব্যবহারের চেয়ে কোনও হালকা ওজন।
ইহানেই

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

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

29
  1. আপনি বৈধ কারণগুলিতে একবারে ফাইল সিস্টেমে একাধিক ওয়ার্কটিচারের প্রয়োজন / চান করতে পারেন।

    • অন্য কোথাও পরিবর্তন করার প্রয়োজনের সময় পরীক্ষিত ফাইলগুলিতে হেরফের করা (যেমন সংকলন / পরীক্ষা)

    • সাধারণ ডিফ সরঞ্জামগুলির মাধ্যমে ফাইলগুলি পৃথক করা

    • মার্জ সংঘাত চলাকালীন, আমি প্রায়শই ফাইলগুলিতে দ্বন্দ্বগুলি সমাধান করার সময় উত্সের কোড হিসাবে উত্স কোডের মাধ্যমে নেভিগেট করতে চাই ।

    • আপনার যদি অনেক পিছনে পিছনে স্যুইচ করার দরকার হয় তবে সময় নষ্ট করে চেক আউট করা এবং একাধিক ওয়ার্কট্রিগুলির সাথে আপনার কী করার দরকার নেই তা পরীক্ষা করে দেখুন।

    • গিট স্ট্যাশিংয়ের মাধ্যমে শাখাগুলির মধ্যে মানসিক প্রসঙ্গের স্যুইচিংয়ের মানসিক ব্যয়টি আসলে পরিমাপযোগ্য নয়। কিছু লোক দেখতে পান যে স্ট্যাশিংয়ের মানসিক ব্যয় রয়েছে যা কেবল কোনও ভিন্ন ডিরেক্টরি থেকে ফাইল খোলার মাধ্যমে নেই।

  2. কিছু লোক "একাধিক স্থানীয় ক্লোন কেন করবেন না" জিজ্ঞাসা করে। এটি সত্য যে "--local" পতাকাটি দিয়ে আপনাকে অতিরিক্ত ডিস্ক স্থান ব্যবহারের জন্য চিন্তা করতে হবে না। এটি (বা অনুরূপ ধারণাগুলি) আমি এখন পর্যন্ত এই কাজটি করেছি। স্থানীয় ক্লোনগুলির উপর লিঙ্কযুক্ত ওয়ার্ক্ট্রিগুলির কার্যকরী সুবিধা:

    1. স্থানীয় ক্লোনগুলির সাহায্যে আপনার অতিরিক্ত ওয়ার্করিজগুলি (যা স্থানীয় ক্লোনগুলিতে থাকে) কেবল উত্স বা উজানের শাখায় অ্যাক্সেস পায় না। ক্লোনটির 'উত্স' প্রথম ক্লোনটিতে 'উত্স' এর মতো হবে না।

      • দৌড়ানো git log @{u}..বা git diff origin/feature/other-featureখুব সহায়ক হতে পারে এবং এগুলি হয় আর সম্ভব নয় বা আরও বেশি কঠিন। এই ধারণাগুলি workarouns একটি ভাণ্ডার মাধ্যমে স্থানীয় ক্লোনগুলির সাথে প্রযুক্তিগতভাবে সম্ভব, তবে আপনি যে প্রতিটি কাজকর্ম করতে পারেন তা সংযুক্ত ওয়ার্কট্রিগুলির মাধ্যমে আরও ভাল এবং / অথবা সহজভাবে সম্পন্ন করা যেতে পারে।
    2. আপনি ওয়ার্কট্রিগুলির মধ্যে রেফারগুলি ভাগ করতে পারেন। আপনি যদি অন্য স্থানীয় শাখা থেকে তুলনা করতে বা bণ নিতে চান তবে এখনই পারেন।


11
এছাড়াও আপনি নিজের ওয়ার্ক্ট্রিগুলিকে একটি একক কমান্ডের সাথে তালিকা করতে পারেন, এমন ক্লোনগুলির সাহায্যে আপনার নিজের নজর রাখতে হবে।
আয়ান রিংরোজ 10

হুম। 2.7.0 গিট হিসাবে এটি মনে হয়। জেনে ভালো লাগল.
আলেকজান্ডার বার্ড

9

tl; dr: যে কোনও কারণে আপনি যে কোনও কারণেই একই সময়ে দুটি কাজের গাছ যাচাই করতে চান, git-worktreeএটি করার একটি দ্রুত এবং স্থান-দক্ষ উপায়।

আপনি যদি অন্য একটি ওয়ার্কট্রি তৈরি করেন তবে রেপোর বেশিরভাগ অংশ .gitভাগ করা হবে (অর্থাত্ ) আপনি যদি কোনও কাজ গাছের মধ্যে থাকা অবস্থায় একটি শাখা তৈরি করেন বা ডেটা আনেন তবে এটি আপনার অন্য কোনও কার্য গাছের থেকেও অ্যাক্সেসযোগ্য হবে। বলুন যে আপনি নিজের পরীক্ষার স্যুটটি ক্লোন করতে কোথাও ঠেলাঠেলি না করেই শাখা ফু-তে চালাতে চান এবং আপনি স্থানীয়ভাবে আপনার রেপো ক্লোনিংয়ের ঝামেলা এড়াতে চান, এটি ব্যবহার করে git-worktreeকোনও রাজ্যের মাত্র একটি নতুন চেকআউট তৈরি করার একটি দুর্দান্ত উপায় using অস্থায়ীভাবে বা স্থায়ীভাবে পৃথক স্থান। ঠিক যেমন কোনও ক্লোন দিয়ে কাজ করার পরে আপনাকে যা করতে হবে তা হ'ল এটি মুছে ফেলা হবে এবং এর উল্লেখটি কিছু সময়ের পরে আবর্জনা সংগ্রহ করা হবে।


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

অবশ্যই আপনি পারেন। ম্যান পেজটি কীভাবে বলে; সন্ধান --force। তবে আপনি অসুবিধাগ্রস্থ হন যদি আপনি এক জায়গায় শাখাটি আপডেট করেন এবং অন্যদিকে এটিতে কাজ করার প্রত্যাশা করেন, যেহেতু ওয়ার্ক্ট্রি আপডেট করা হয়নি।
jsageryd

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

একটি ওয়ার্ক্রিট্রি (যেমন নামটি বোঝা যাচ্ছে) কেবল একটি ওয়ার্কট্রি, কিছু অতিরিক্ত যুক্ত বৈশিষ্ট্য সহ; সংগ্রহস্থলটি সমস্ত ওয়ার্কট্রির মধ্যে ভাগ করা হয়। দুটি worktree মধ্যে পার্থক্য শুধুমাত্র এই যে চেক আউট শাখা (এবং বুদ্ধিমান কর্মপ্রবাহের জন্য,) আলাদা হতে পারে। একটি পৃথক ওয়ার্ক্ট্রিতে প্রতিশ্রুতিবদ্ধ হওয়া সম্ভব, সুতরাং সেই কাজটি করার জন্য এটির নিজস্ব সূচক (ওরফে স্টেজিং এরিয়া) রয়েছে। .gitপৃথক worktree ফাইল একটি টেক্সট তার কনফিগারেশন, মূল সংগ্রহস্থলের মধ্যে থাকা পাথ ধারণকারী ফাইল।
jsageryd

2
@ উইলসনএফ: git checkout --ignore-other-worktrees <branch> git-scm.com/docs/git-checkout/…
jsageryd

7

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

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

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


4

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

সমস্যাটি হ'ল লিনাক্স এবং উইন্ডোজ একই ডিরেক্টরিতে ব্যবহার করার সময় একে অপরের সাথে ক্র্যাশ তৈরি করে; লাইব্রেরি ইত্যাদি ডাউনলোড করার জন্য কয়েকটি জটিল বিল্ড স্টেপস রয়েছে যা একই ডিরেক্টরি নাম ব্যবহার করে। বিল্ড সিস্টেমের উইন্ডোজ সংস্করণটি উইন্ডোজ-নির্দিষ্ট গ্রন্থাগারগুলি ডাউনলোড করে এবং বিল্ড সিস্টেমের লিনাক্স সংস্করণটি লিনাক্স-নির্দিষ্ট গ্রন্থাগারগুলি ডাউনলোড করে।

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

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


+1 এটি প্রতি-কনফিগারেশন বিল্ড আউটপুট ডিরেক্টরিগুলি না করে তৈরি করার পক্ষে খুব কার্যকরী কাজের মতো বলে মনে হয়। উবুন্টু এবং ম্যাকোএস অতিথিদের সাথে আমার অনুরূপ ভিএমওয়্যার ওয়ার্কস্টেশন সেটআপ রয়েছে।
তানজ 87

1

আমার জন্য নতুন প্রকল্পে, আমি একটি বৈশিষ্ট্য তৈরি করেছি। তবে কিছু চশমা ব্যর্থ হয়েছে। ফলাফলগুলির সাথে তুলনা করতে masterআমি একটি work-treeরেপো তৈরি করেছি । আমি রান কোডে ধাপে ধাপে ফলাফলগুলি তুলনা করেছি, যতক্ষণ না বুঝতে পেরেছি কী ভুল হয়েছে।


যদিও একটি ওয়ার্ক্রিট্রি ক্লোনর চেয়ে এটি আরও কীভাবে সহজ করে? প্রশ্নটি ব্যক্তিগত পছন্দকে জিজ্ঞাসা করছে না, তবে দৃ concrete় পার্থক্য রয়েছে।
IInspectable

1

আমি git worktreeমেশিন লার্নিং ডেভলপমেন্টের জন্য ব্যবহার করছি ।

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

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