ডকুমেন্টেশন এবং প্রকল্প পরিচালনার জন্য গিট ব্যবহার করা উচিত? কোডটি কি আলাদা ভাণ্ডারে থাকতে হবে?


68

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

এখানে আমার প্রশ্নের সংক্ষিপ্তসার রয়েছে:

  • কোড এবং দস্তাবেজ দুটি একই সংগ্রহস্থলে পরীক্ষা করা থাকলে কি গিট সংশোধন শৈলী বিভ্রান্ত হতে চলেছে ? এর সাথে অভিজ্ঞতা?

  • ডকুমেন্টেশন রিভিশন নিয়ন্ত্রণের জন্য কি গিট কি ভাল ফিট?

  • আমি জিজ্ঞাসা করছি না যে সাধারণভাবে একটি রিভিশন কন্ট্রোল সিস্টেম ডকুমেন্টেশনের জন্য ব্যবহার করা উচিত বা উচিত নয় - এটি হওয়া উচিত।

এখনও পর্যন্ত প্রতিক্রিয়া জন্য ধন্যবাদ!


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

1
বিষয়টি কীভাবে হয় তা আমি পুরোপুরি দেখতে পাই না। আপনি সফ্টওয়্যার ডকুমেন্টেশন এবং একটি ডিভিসিএস
টিম পোস্ট

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

যদি আপনার ডকুমেন্টেশনগুলি সরল পাঠ্যে থাকে - জরিমানা। যদি এটি একটি বাইনারি ফর্ম্যাট হয় তবে আপনার অবশ্যই একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থা দরকার যা বাইনারি ফর্ম্যাটটি বোঝে - এটি তার শুদ্ধতম আকারে বিক্রেতা লক-ইন is

উত্তর:


53

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

আমরা কিছু অ-পাঠ্য বিন্যাসিত ফাইল যেমন মাইক্রোসফ্ট অফিস। ডক ফাইল, স্প্রেড শিটস,। জিপ ফাইল, ইত্যাদি সংরক্ষণ করি যখন প্রয়োজন হয় ... তবে আপনি যখন ইনক্রিমেন্টাল দেখতে না পান তখন আরসিএসের কিছু সুবিধা হারাতে পারে diffs।

আপনার ডকুমেন্টেশনটি সুসংগতভাবে তৈরি হয়েছে তা নিশ্চিত করার জন্য কীটি হ'ল যাতে লোকেরা যখন প্রয়োজন হয় তখন ডকুমেন্টেশন (এবং উত্স) খুঁজে পেতে পারে can


11
আপনি যদি মাইক্রোসফ্টের দোকান হন তবে কচ্ছপ এসভিএন এমএস অফিসের লাইন বাই লাইন বিবিধ সমর্থন করে।
ফিল

2
বাইনারি ডক ফর্ম্যাটগুলি ফেলে দেওয়া বিশ্বকে আরও ভাল জায়গা করে তুলবে। o দস্তাবেজগুলি সরল-পাঠ্য হিসাবে প্রদত্ত, কোনও ডিভিসিএসের সাথে কোনও আসল সমস্যা হওয়া উচিত নয়।
কাই ইনকিনেন

ওহ, এবং প্রথমবার আমি কচ্ছপ এসভিএন এবং ডক ফাইলগুলির কথা শুনেছি, সুতরাং এটির জন্য +1। ভবিষ্যতে যে কোনও সময় কচ্ছপ [যেকোনও ডিভিসিএস] এ শেষ হয়ে গেলে অবাক হন।
কাই ইনকিনেন

@ ফিল: কচ্ছপ এসভিএন কীভাবে এটি সম্পাদন করে? ডক-ডিসেফ ভিউয়ার কি এসভিএন ক্লায়েন্টের সাথে একীভূত হয়েছে, বা এটি স্বাধীনভাবে ব্যবহার করা যেতে পারে?
ঝাঁকুনি

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

22

ভাল আপনি ডকুমেন্টেশনের জন্য কোন ফর্ম্যাটটি ব্যবহার করেন তা নির্ভর করে। এটি যদি কিছু পাঠ্য ভিত্তিক হয় তবে এটি সব ভাল।

গিট বাইনারি সামগ্রীও সঞ্চয় করতে পারে এবং আপনি পুনর্বিবেচনাগুলি ট্র্যাক করতে পারেন, তবে ভিন্ন আউটপুটটি কোনও অর্থ দেবে না।

পার্লডোক পডের মতো কোডেই ডকুমেন্টেশন সংরক্ষণ করা সম্ভব, জাভাতেও এর জন্য কিছু ফর্ম্যাট / টিকা আছে।


আমি সম্মতি জানাই, নন-টেক্সট ডকুমেন্টেশনগুলি সংরক্ষণ করা সম্ভব হলেও আপনি যদি পরিবর্তে পাঠ্য সঞ্চয় করেন তবে গিটটি আরও অনেক ভাল করবে। একটি ভিন্ন ড্রাইভারের কথা হয়েছে যা কীভাবে শব্দ (বা অনুরূপ) নথিগুলিকে পৃথক করতে পারে তা জানে, তবে আমি এটি নিশ্চিত না যে এটি বাস্তবায়িত হয়েছিল কি না
Sverre Rabbelier

আমি যদিও ওয়ার্ড তাদের বিন্যাসটি বাইনারি থেকে XML এ সরিয়ে নিয়েছে।
cledoux

3
@ karategeek6 শব্দের 'এক্সএমএল' ফর্ম্যাটটি মানব পাঠযোগ্য নয়। এবং পাঠ্যের একটি লাইন ওয়ার্ডের এক্সএমএল এর এক লাইনের সাথে সামঞ্জস্য নয়, এমনকি আনুমানিকও। সুতরাং এটি পাশাপাশি বাইনারি হতে পারে।

আপনার আউটপুটটি সঙ্কুচিত এক্সএমএলে সংরক্ষণের জন্য আপনি ওয়ার্ডকে নির্দেশ দিতে পারেন। চয়ন করুন Save As, তারপরে Word XML Document (*.xml)ডিফল্টের পরিবর্তে নির্বাচন করুন Word Document (*.docx)। এক্সএমএল বেশ জটিল, সুতরাং পরিবর্তনগুলি সহজেই পঠনযোগ্য হবে এর কোনও গ্যারান্টি নেই, তবে কমপক্ষে এটি বাইনারি হবে না।
ক্যারলেস

> তবে ভিন্ন আউটপুটটি বোঝা যাবে না। পার্থক্য না থাকলে, আমরা পাশাপাশি একটি দস্তাবেজের 2 টি পুনর্বিবেচনা খুলতে পারি এবং আমাদের চোখের দ্বারা তুলনা করতে পারি :)
লুক

14

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


6
ডকুমেন্টেশনটি যদি কোনও পাঠ্য আকারে থাকে। বাইনারি ব্লবগুলি সম্পূর্ণরূপে সংস্করণ নিয়ন্ত্রণ থেকে উপকৃত হয় না।

2
@ থোরজ্বার্নআরভানএন্ডারসন: তবুও, আপনার কাছে যদি বাইনারি-নির্দিষ্ট সংস্করণ ব্যবস্থা না থাকে তবে গিটে এমনকি বাইনারি ফাইলগুলি নিজের না করে রাখাই ভাল।
টিখন জেলভিস

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

@ ইউজার 1249: আপনি ডেস্কটপে 2 সংশোধন "রফতানি" করতে পারেন, আমার_ডোকস_রেভ 15.ডোক্স এবং মাই_ডোকস_রেভ ১৪.ডোকস তারপরে পাশাপাশি খুলুন এবং আপনার চোখ এবং মস্তিষ্কের সাথে তুলনা করুন, এটি তেমন শক্ত নয় :)
লূক

14

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


3
হ্যাঁ, "একই অবস্থান" দিকটি এই প্রশ্নের অন্যতম মূল অঙ্গ!

আপনি যদি এটি পরিচালনা করতে পারেন তবে একই অবস্থানটি ভাল, কারণ এটি হয় উপজাতির জ্ঞান (কোথায় দেখতে হবে তা জেনে রাখা) বা স্টাফটি কোথায় রয়েছে তা অনুসন্ধান করার প্রয়োজনীয়তা এড়িয়ে চলে।
দ্রুত_ এখন

তাদের কোডটিতে অ্যাক্সেসের প্রয়োজন নাও হতে পারে তবে তাদের অ্যাক্সেসটি দেওয়া উচিত নয়। তাদের এটি দেখার দরকার নেই। গোপনীয়তা সাধারণত সংস্করণ নিয়ন্ত্রণে হওয়া উচিত নয়।
বিডএসএল

9

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

প্রথমে এটি ট্র্যাক ছিল, তার পরে মিডিয়াউইকি স্থানান্তরিত হওয়ার কারণে এটি ব্যবহার করা সহজতর ছিল ...

এসভিএনের সাথে প্রধান সমস্যাটি ছিল শেয়ারিং কারণ যা এসভিএন এর জন্য আমাদের অনুমোদনের ব্যবস্থা ছিল।


2
আপনি উইকিপিডিয়া যে উইকি ইঞ্জিনটি মিডিয়াউইকি ব্যবহার করেন তা বোঝাতে চাইছেন না?

@ মার্তিজন, আমি ধরে নিই
তেও ক্লেস্টরপ রিজিজন

@ মার্তিজন: হ্যাঁ, সম্পাদিত
কনফিকার

আমি বরং অনেকগুলি ফাইল যা এসসিএমের কোর্স নয়, পাঠানোর চেয়ে উইকির সাথে লেগে থাকি, তবে ব্যক্তিগত পছন্দের সাথে আরও বেশি কিছু করতে চাই। এটির সাথে আরও অনেক কিছু করতে পারেন। আমি বিশেষত ফসউইকি এবং তাদের ওয়েবসাইট ভিত্তিক / প্রকল্প ভিত্তিক টেম্পলেট পছন্দ করি। সমস্যার কারণে কেউ উইকি ব্যবহার করার সিদ্ধান্ত নিয়েছে বলে খুশি হলেন :) +1 1
Oeufcoque Penteano

9
  • একটি সংগ্রহস্থলে কেবল উত্স কোডের বেশি থাকা খুব ভাল জিনিস।

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

    আপনি জিনিসগুলিকে সংগঠিত রাখতে চাইবেন। পৃথক একটি ব্যবস্থা আছে srcথেকে imagesথেকে docs.gitignoreসংগ্রহস্থল এবং ইতিহাস পরিষ্কার রাখার জন্য আপনি সর্বদা ডিরেক্টরিতে একটি যুক্ত করতে পারেন । যেহেতু গিট কমিটগুলি ফাইল-ভিত্তিক, * আপনি ডকুমেন্টেশন পরিবর্তনগুলি থেকে উত্স পরিবর্তনগুলি আপনার পছন্দ মতো দৃ strongly়ভাবে ডিকুয়াল করতে পারেন।

  • অন্যরা যেমন বলেছে, গীতটি যতক্ষণ না এটি পাঠ্য-ভিত্তিক ডকুমেন্টেশন সংস্করণের জন্য দুর্দান্ত।

  • আমি পুরোপুরি একমত; ডকুমেন্টেশন ঠিক কোডের পাশাপাশি সংস্করণ করা উচিত।

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


* এটি পুরোপুরি সঠিক নয়, কারণ প্রতিশ্রুতিবদ্ধ হওয়ার জন্য কোনও ফাইলের অংশগুলি নির্দিষ্ট করার উপায় রয়েছে ( এখানে একটি উদাহরণ রয়েছে )।


4

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

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


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

প্যাকেজ বিতরণ করার সময়, আমি .deb শৈলীর আংশিক যা আমাকে সমস্ত সার্ভারে এক্সিকিউটেবলগুলি ডাউনলোড করতে দেয়, যখন আমার বিকাশ বাক্সেও ডকুমেন্টেশন প্যাকেজ রয়েছে।
tbc0

1

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


-1

কোডে, চিন্তাগুলি সাধারণত লাইন বাই লাইনে আলাদা করা হয়। আমি নরম লাইন মোড়ক দিয়ে ডকুমেন্টেশন লিখতে ঝোঁক। আমি যখন এই ফাইলগুলি প্রতিশ্রুতিবদ্ধ করি তখন লাইনগুলি পুরো অনুচ্ছেদ দীর্ঘ হয়। এটি পড়তে খুব কার্যকর নয় git diff। এই পৃষ্ঠাটি গুগল করে এই পৃষ্ঠাটি খুঁজে পাওয়ার সময় আমি সেই সমস্যাটি সমাধান করার চেষ্টা করছি। আমার সাথে পরিচয় করিয়ে দেওয়ার জন্য অ্যান হার্টার্জকে ধন্যবাদ জানাইgit diff --word-diff । আপনি git diff --color-wordsআরও ভাল পছন্দ করতে পারেন ।

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