ما هو الفرق بين ميركوريال وجيت؟
https://stackoverflow.com/questions/35837
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أستخدم git منذ بعض الوقت على Windows (مع msysGit) وأحب فكرة التحكم بالمصادر الموزعة.لقد نظرت مؤخرًا إلى Mercurial (hg) ويبدو مثيرًا للاهتمام.ومع ذلك، لا أستطيع أن أستوعب الاختلافات بين hg وgit.
هل قام أي شخص بإجراء مقارنة جنبًا إلى جنب بين git و hg؟أنا مهتم بمعرفة ما هو الفرق بين hg وgit دون الحاجة إلى القفز إلى مناقشة المعجبين.
المحلول
قد تساعد هذه المقالات:
- بوابة مقابل.زئبقي:اهدأ رجاء (Git هو MacGyver و Mercurial هو جيمس بوند)
- الاختلافات بين Mercurial و Git
يحرر:يبدو أن مقارنة Git و Mercurial بالمشاهير هو الاتجاه السائد.وهنا واحد آخر:
نصائح أخرى
أنا أعمل على Mercurial، ولكن في الأساس أعتقد أن كلا النظامين متساويان.كلاهما يعملان بنفس التجريدات:سلسلة من اللقطات (مجموعات التغييرات) التي تشكل التاريخ.تعرف كل مجموعة تغييرات مصدرها (مجموعة التغييرات الأصلية) ويمكن أن تحتوي على العديد من مجموعات التغييرات الفرعية.في الآونة الأخيرة hg-git يوفر الامتداد جسرًا ثنائي الاتجاه بين Mercurial وGit ويظهر نوعًا ما هذه النقطة.
يركز Git بشدة على تغيير هذا الرسم البياني للتاريخ (مع كل ما يترتب على ذلك من عواقب)، في حين أن Mercurial لا يشجع على إعادة كتابة التاريخ، ولكن من السهل القيام به على أي حال والعواقب المترتبة على القيام بذلك هي بالضبط ما يجب أن تتوقعه (أي، إذا قمت بتعديل مجموعة التغييرات الموجودة لديك بالفعل، فسوف يراها عميلك على أنها جديدة إذا سحبتها مني).لذا فإن Mercurial لديه تحيز نحو الأوامر غير المدمرة.
أما بالنسبة للفروع خفيفة الوزن، فقد دعمت Mercurial المستودعات بها فروع متعددة منذ...، أعتقد دائما.مستودعات Git ذات الفروع المتعددة هي بالضبط ما يلي:عدة فروع متباينة من التطوير في مستودع واحد.يقوم Git بعد ذلك بإضافة أسماء إلى هذه الخيوط ويسمح لك بالاستعلام عن هذه الأسماء عن بعد.ال إشارات مرجعية يضيف ملحق Mercurial أسماء محلية، ومع Mercurial 1.6، يمكنك نقل هذه الإشارات المرجعية عند الدفع/السحب.
أنا أستخدم Linux، ولكن من الواضح أن TortoiseHg أسرع وأفضل من مكافئ Git على Windows (بسبب الاستخدام الأفضل لنظام ملفات Windows الضعيف).كلاهما http://github.com و http://bitbucket.org توفير استضافة عبر الإنترنت، الخدمة في Bitbucket رائعة وسريعة الاستجابة (لم أجرب github).
لقد اخترت Mercurial لأنه يبدو نظيفًا وأنيقًا - لقد أزعجتني نصوص shell/Perl/Ruby التي حصلت عليها مع Git.حاول إلقاء نظرة خاطفة على git-instaweb.sh ملف إذا كنت تريد أن تعرف ما أعنيه:إنها صدَفَة البرنامج النصي الذي يولد ملف روبي البرنامج النصي، الذي أعتقد أنه يدير خادم ويب.يقوم برنامج Shell النصي بإنشاء برنامج نصي Shell آخر لبدء تشغيل برنامج Ruby النصي الأول.هناك أيضا القليل من بيرل, ، للقياس الجيد.
انا احب ال مشاركة مدونة الذي يقارن Mercurial وGit مع جيمس بوند وMacGyver - Mercurial هو إلى حد ما أكثر انخفاضًا من Git.يبدو لي أن الأشخاص الذين يستخدمون Mercurial لا يعجبون بسهولة.وينعكس هذا في كيفية قيام كل نظام بما وصفه لينوس "أروع دمج على الإطلاق!".في Git، يمكنك الدمج مع مستودع غير ذي صلة عن طريق القيام بما يلي:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
تبدو تلك الأوامر غامضة جدًا في نظري.في ميركوريال نقوم بما يلي:
hg pull --force <project-to-union-merge>
hg merge
hg commit
لاحظ كيف أن أوامر Mercurial واضحة وليست خاصة على الإطلاق - الشيء الوحيد غير المعتاد هو --force العلم ل hg pull, ، وهو أمر ضروري نظرًا لأن Mercurial سيتم إحباطه بطريقة أخرى عند السحب من مستودع غير ذي صلة.إن مثل هذه الاختلافات هي التي تجعل Mercurial يبدو أكثر أناقة بالنسبة لي.
Git عبارة عن منصة، أما Mercurial فهو مجرد تطبيق.Git عبارة عن نظام أساسي لنظام ملفات تم إصداره ويأتي مع تطبيق DVCS في العلبة، ولكن كالمعتاد بالنسبة لتطبيقات النظام الأساسي، فهو أكثر تعقيدًا وله حواف أكثر خشونة من التطبيقات المركزة.ولكن هذا يعني أيضًا أن نظام VCS الخاص بـ git مرن للغاية، وهناك قدر كبير من الأشياء التي لا تتعلق بالتحكم في المصدر والتي يمكنك القيام بها باستخدام git.
وهذا هو جوهر الفرق.
من الأفضل فهم Git من الألف إلى الياء – من تنسيق المستودع إلى الأعلى. سكوت تشاكون جيت توك هو تمهيدي ممتاز لهذا الغرض.إذا حاولت استخدام git دون معرفة ما يحدث تحت الغطاء، فسينتهي بك الأمر في حيرة من أمرك في مرحلة ما (إلا إذا التزمت بالوظائف الأساسية فقط).قد يبدو هذا غبيًا عندما يكون كل ما تريده هو DVCS لروتين البرمجة اليومي، ولكن عبقرية git تكمن في أن تنسيق المستودع في الواقع بسيط جدًا ويمكنك يستطيع فهم عملية git بأكملها بسهولة تامة.
بالنسبة لبعض المقارنات ذات التوجه الفني، فإن أفضل المقالات التي رأيتها شخصيًا هي مقالات داستن سالينجز:
- الاختلافات بين Mercurial و Git
- موضوع Reddit حيث يجيب داستن ذو الخبرة في مجال git على أسئلته الخاصة بالمبتدئين في مجال git
لقد استخدم بالفعل كلا نظامي DVCS على نطاق واسع ويفهمهما جيدًا - وانتهى به الأمر بتفضيل git.
الفرق الكبير هو على ويندوز.يتم دعم Mercurial محليًا، بينما Git ليس كذلك.يمكنك الحصول على استضافة مشابهة جدًا لـ github.com مع bitbucket.org (في الواقع أفضل عندما تحصل على مستودع خاص مجاني).كنت أستخدم msysGit لفترة من الوقت ولكنني انتقلت إلى Mercurial وكنت سعيدًا جدًا به.
إذا كنت أحد مطوري Windows وتبحث عن التحكم الأساسي في المراجعة غير المتصلة، فانتقل إلى Hg.لقد وجدت أن Git غير مفهوم بينما كان Hg بسيطًا ومتكاملًا بشكل جيد مع غلاف Windows.لقد قمت بتنزيل Hg وتابعته هذا البرنامج التعليمي (hginit.com) - بعد عشر دقائق حصلت على مستودع محلي وعدت للعمل في مشروعي.
أعتقد أن أفضل وصف حول "Mercurial vs.جيت" هو:
إنهم متطابقون تقريبًا.الفرق الأكثر أهمية من وجهة نظري (أعني السبب الذي جعلني أختار أحد برامج DVCS على الآخر) هو كيفية إدارة البرنامجين للفروع.
لبدء فرع جديد، باستخدام Mercurial، ما عليك سوى استنساخ المستودع إلى دليل آخر والبدء في التطوير.ثم، يمكنك سحب ودمج.باستخدام git، عليك أن تعطي اسمًا صريحًا لفرع الموضوع الجديد الذي تريد استخدامه، ثم تبدأ في البرمجة باستخدام نفس الدليل.
باختصار، كل فرع في Mercurial يحتاج إلى دليل خاص به؛في git تعمل عادةً في دليل واحد.تبديل الفروع في Mercurial يعني تغيير الدلائل؛في git، يعني ذلك مطالبة git بتغيير محتوى الدليل باستخدام git checkout.
أنا صادق:لا أعرف ما إذا كان من الممكن فعل الشيء نفسه مع Mercurial، ولكن نظرًا لأنني عادةً ما أعمل على مشاريع الويب، فإن استخدام نفس الدليل دائمًا مع git يبدو مريحًا جدًا بالنسبة لي، حيث لا يتعين علي إعادة تكوين Apache وإعادة التشغيل ولا أفسد نظام الملفات الخاص بي في كل مرة أقوم فيها بالتفرع.
يحرر:كما أشار ديستان، فقد فعل الزئبق فروع مسماة, والتي يمكن تخزينها في مستودع واحد وتسمح للمطور بتبديل الفروع داخل نفس نسخة العمل.فروع git ليست تمامًا مثل فروع Mercurial المسماة، على أي حال:فهي دائمة ولا تتخلص من الفروع، كما هو الحال في git.وهذا يعني أنه إذا كنت تستخدم فرعًا مسمىًا للمهام التجريبية، حتى لو قررت عدم دمجه مطلقًا، فسيتم تخزينه في المستودع.هذا هو السبب وراء تشجيع Hg على استخدام النسخ للمهام التجريبية قصيرة المدى والفروع المسماة للمهام طويلة المدى، مثل فروع الإصدار.
السبب الذي يجعل الكثير من مستخدمي Hg يفضلون النسخ على الفرع المسمى هو سبب اجتماعي أو ثقافي أكثر منه تقني.على سبيل المثال، مع الإصدارات الأخيرة من Hg، من الممكن أيضًا إغلاق فرع مسمى وإزالة البيانات الوصفية بشكل متكرر من مجموعات التغييرات.
على الجانب الآخر، يدعو git لاستخدام "الفروع المسماة" التي ليست دائمة ولا يتم تخزينها كبيانات وصفية في كل مجموعة تغييرات.
من وجهة نظري الشخصية، يرتبط نموذج git ارتباطًا وثيقًا بمفهوم الفروع المسماة والتبديل بين فرع وآخر داخل نفس الدليل؛يمكن لـ hg أن يفعل الشيء نفسه مع الفروع المسماة، ولكنه مع ذلك يشجع على استخدام النسخ، وهو ما لا أحبه شخصيًا كثيرًا.
هناك واحد ضخم الفرق بين شخص سخيف و زئبقي;طريقة تمثيل كل التزام. شخص سخيف يمثل الالتزامات كلقطات، بينما زئبقي يمثلهم على أنهم فرق.
ماذا يعني هذا في الممارسة العملية؟حسنًا، العديد من العمليات تكون أسرع في git، مثل التبديل إلى التزام آخر، ومقارنة الالتزامات، وما إلى ذلك.خاصة إذا كانت هذه الالتزامات بعيدة.
AFAIK ليس هناك فائدة من نهج الزئبقي.
لا شئ.كلاهما يفعلان الشيء نفسه، وكلاهما يؤديان نفس الأداء تقريبًا.السبب الوحيد الذي يجعلك تختار واحدًا على الآخر هو إذا كنت تساعد في مشروع يستخدم واحدًا بالفعل.
السبب الآخر المحتمل لاختيار أحدهما هو تطبيق أو خدمة تدعم نظامًا واحدًا فقط.على سبيل المثال، اخترت إلى حد كبير أن أتعلم git بسبب جيثب..
أيضًا مقارنة جوجل (رغم أنها قديمة بعض الشيء، تم إجراؤها في عام 2008)
إذا فهمتهم بشكل صحيح (وأنا لست خبيرًا في كل منها) فإن كل منهم لديه فلسفة مختلفة.لقد استخدمت الزئبق لأول مرة لمدة 9 أشهر.لقد استخدمت الآن git لـ 6.
hg هو برنامج للتحكم في الإصدار.هدفها الرئيسي هو تتبع إصدارات أحد البرامج.
git هو نظام ملفات يعتمد على الوقت.الهدف هو إضافة بعد آخر لنظام الملفات.يحتوي معظمها على ملفات ومجلدات، ويضيف git الوقت.إن العمل بشكل رائع لأن VCS هو نتيجة ثانوية لتصميمه.
في hg، هناك تاريخ للمشروع بأكمله الذي يحاول دائمًا الحفاظ عليه.افتراضيًا، أعتقد أن hg يريد إجراء جميع التغييرات على جميع الكائنات بواسطة جميع المستخدمين عند الدفع والسحب.
يوجد في git فقط مجموعة من الكائنات وملفات التتبع هذه (الفروع/الرؤوس) التي تحدد أي مجموعة من تلك الكائنات تمثل شجرة الملفات في حالة معينة.عند الدفع أو السحب، يرسل git فقط الكائنات المطلوبة للفروع المحددة التي تدفعها أو تسحبها، وهي مجموعة فرعية صغيرة من جميع الكائنات.
بقدر ما يتعلق الأمر بـ git، لا يوجد "مشروع واحد".يمكن أن يكون لديك 50 مشروعًا كلها في نفس الريبو ولن يهتم git.يمكن إدارة كل واحد على حدة في نفس الريبو والعيش بشكل جيد.
مفهوم Hg للفروع هو فروع خارج المشروع الرئيسي أو فروع خارج الفروع وما إلى ذلك.Git ليس لديه مثل هذا المفهوم.الفرع في git هو مجرد حالة الشجرة، كل شيء هو فرع في git.أي فرع رسمي أو حالي أو أحدث ليس له معنى في git.
لا أعرف إذا كان ذلك منطقيًا.إذا كان بإمكاني رسم صور، فقد يبدو hg هكذا حيث يكون كل التزام بمثابة o
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
شجرة ذات جذر واحد وأغصان تخرج منها.في حين أن git يمكنه فعل ذلك وغالبًا ما يستخدمه الأشخاص بهذه الطريقة، إلا أن ذلك لا يتم فرضه.صورة git، إذا كان هناك شيء من هذا القبيل، يمكن أن تبدو بسهولة مثل هذا
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
في الواقع، في بعض النواحي، ليس من المنطقي إظهار الفروع في git.
الشيء الوحيد المربك جدًا للمناقشة هو أن كل من git و Mercurial لهما ما يسمى "فرع" لكنهما ليسا نفس الأشياء عن بعد.يحدث الفرع في الزئبقي عندما يكون هناك تعارض بين اتفاقيات إعادة الشراء المختلفة.من الواضح أن الفرع في git يشبه الاستنساخ في hg.لكن الاستنساخ، على الرغم من أنه قد يعطي سلوكًا مشابهًا، إلا أنه بالتأكيد ليس هو نفسه.اعتبرني أجرب هذه الأشياء في git vs hg باستخدام chromium repo وهو كبير إلى حد ما.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
والآن في زئبق باستخدام الاستنساخ
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
كلاهما ساخنان.أي لقد قمت بتشغيلهم مرتين وهذه هي الجولة الثانية.hg clone هو في الواقع نفس git-new-workdir.يقوم كلاهما بإنشاء مسار عمل جديد تمامًا كما لو كنت قد كتبته cp -r project project-clone.هذا ليس مثل إنشاء فرع جديد في git.إنه وزن أثقل بكثير.إذا كان هناك ما يعادل حقيقيًا لتفرع git بـ hg، فلا أعرف ما هو.
أنا أفهم على مستوى ما hg وgit قد تكون قادرة على القيام بأشياء مماثلة.إذا كان الأمر كذلك، فلا يزال هناك فرق كبير في سير العمل الذي يقودونك إليه.في git، يتمثل سير العمل النموذجي في إنشاء فرع لكل ميزة.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
أدى ذلك إلى إنشاء 3 فروع، كل منها يعتمد على فرع يسمى الرئيسي.(أنا متأكد من أن هناك طريقة ما في git لإنشاء سطر واحد بدلاً من 2)
الآن للعمل على واحد أفعله فقط
git checkout fix-game-save-bug
وابدأ العمل.ارتكاب الأشياء وما إلى ذلك.يعد التبديل بين الفروع حتى في مشروع كبير مثل Chrome أمرًا فوريًا تقريبًا.أنا في الواقع لا أعرف كيفية القيام بذلك في زئبق.إنها ليست جزءًا من أي برامج تعليمية قرأتها.
فرق كبير آخر.مرحلة جيت.
لدى Git فكرة المرحلة.يمكنك التفكير فيه كمجلد مخفي.عندما تلتزم فإنك تلتزم فقط بما هو موجود على المسرح، وليس التغييرات في شجرة العمل الخاصة بك.قد يبدو ذلك غريبا.إذا كنت تريد تنفيذ جميع التغييرات في شجرة العمل الخاصة بك، فستفعل git commit -a الذي يضيف جميع الملفات المعدلة إلى المرحلة ثم يلتزم بها.
ما فائدة المرحلة إذن؟يمكنك بسهولة فصل التزاماتك.تخيل أنك قمت بتحرير Joypad.cpp وgamesave.cpp وتريد الالتزام بهما بشكل منفصل
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
لدى Git أيضًا أوامر لتحديد الأسطر المحددة في نفس الملف التي تريد نسخها إلى المنصة حتى تتمكن من تقسيم تلك الالتزامات بشكل منفصل أيضًا.لماذا تريد أن تفعل ذلك؟لأنه في حالة الالتزامات المنفصلة، يمكن للآخرين سحب الالتزامات التي يريدونها فقط أو إذا كانت هناك مشكلة، فيمكنهم التراجع عن الالتزام الذي كان به المشكلة فقط.
يوجد مخطط مقارنة ديناميكي في versioncontrolblog حيث يمكنك مقارنة العديد من أنظمة التحكم في الإصدار المختلفة.
هناك اختلافات كبيرة جدًا عندما يتعلق الأمر بالعمل مع الفروع (خاصة الفروع قصيرة المدى).
تم شرحه في هذه المقالة (شرح متفرع) الذي يقارن Mercurial مع Git.
هل هناك أي متعاونين يعتمدون على Windows في مشروعك؟
لأنه في حالة وجودها، فإن واجهة المستخدم الرسومية لـ Git-for-Windows تبدو غريبة وصعبة وغير ودية.
وعلى النقيض من ذلك، فإن Mercurial-on-Windows هو أمر لا يحتاج إلى تفكير.
شيء واحد يجب ملاحظته بين Mercurial of bitbucket.org وgit of github هو أن Mercurial يمكن أن يحتوي على العديد من المستودعات الخاصة كما تريد، ولكن github يجب عليك الترقية إلى حساب مدفوع.ولهذا السبب اخترت bitbucket الذي يستخدم الزئبقي.
في وقت ما من العام الماضي، قمت بتقييم كل من git وhg لاستخدامي الخاص، وقررت استخدام hg.شعرت أنه يبدو وكأنه حل أنظف، وعمل بشكل أفضل على المزيد من المنصات في ذلك الوقت.لقد كان الأمر في الغالب مجرد رمي.
في الآونة الأخيرة، بدأت في استخدام git بسبب git-svn والقدرة على العمل كعميل Subversion.لقد أذهلتني هذه الفكرة وتحولت الآن بالكامل إلى git.أعتقد أن لديه منحنى تعليمي أعلى قليلاً (خاصة إذا كنت بحاجة إلى البحث في الدواخل)، ولكنه نظام رائع حقًا.سأذهب لقراءة مقالتي المقارنة اللذين نشرهما جون الآن.
أنا حاليًا بصدد الانتقال من SVN إلى DVCS (أثناء التدوين حول النتائج التي توصلت إليها، أول جهد حقيقي للتدوين...)، وقد أجريت القليل من البحث (= googling).بقدر ما أستطيع أن أرى أنه يمكنك القيام بمعظم الأشياء باستخدام كلتا الحزمتين.يبدو أن GIT لديه بعض الميزات المتقدمة التي تم تنفيذها بشكل أفضل ، أشعر أن التكامل مع Windows أفضل قليلاً بالنسبة للزئبق ، مع السلحفاة.أعلم أن هناك Git Cheetah أيضًا (لقد جربت كليهما)، لكن الحل الزئبقي يبدو أكثر قوة.
نظرًا لأن كلاهما مفتوح المصدر (أليس كذلك؟) لا أعتقد أن أيًا منهما سيفتقر إلى ميزات مهمة.إذا كان هناك شيء مهم، فسيطلبه الناس، وسيقومون بتشفيره.
أعتقد أن Git و Mercurial أكثر من كافيين بالنسبة للممارسات الشائعة.كلاهما لديه مشاريع كبيرة تستخدمهما (Git -> linux kernel، Mercurial -> مشاريع مؤسسة Mozilla، وكلاهما من بين مشاريع أخرى بالطبع)، لذلك لا أعتقد أن أيًا منهما يفتقر حقًا إلى شيء ما.
ومع ذلك، أنا مهتم بما يقوله الآخرون حول هذا الموضوع، لأنه سيكون مصدرًا رائعًا لجهودي في التدوين؛-)
هناك جداول ورسوم بيانية رائعة وشاملة للمقارنة على git و Mercurial و Bazaar دليل InfoQ حول DVCS.
أدرك أن هذا ليس جزءًا من الإجابة، ولكن في هذه الملاحظة، أعتقد أيضًا أن توفر المكونات الإضافية الثابتة لمنصات مثل NetBeans وEclipse يلعب دورًا في تحديد الأداة الأكثر ملاءمة للمهمة، أو بالأحرى، أي أداة هو الأنسب لـ "أنت".وهذا هو، إلا إذا كنت حقًا تريد أن تفعل ذلك بطريقة CLI.
يواجه كل من Eclipse (وكل شيء يعتمد عليه) وNetBeans أحيانًا مشكلات مع أنظمة الملفات البعيدة (مثل SSH) والتحديثات الخارجية للملفات؛وهذا سبب آخر وراء رغبتك في أن يعمل كل ما تختاره "بسلاسة".
أحاول الإجابة على هذا السؤال لنفسي الآن أيضًا..ولقد اختصرت المرشحين إلى Git أو Mercurial ..أشكركم جميعًا على تقديم مدخلات مفيدة حول هذا الموضوع دون التدين.
مقارنة أخرى مثيرة للاهتمام بين Mercurial و git: ميركوريال مقابل جيت.ينصب التركيز الرئيسي على العناصر الداخلية وتأثيرها على عملية التفرع.
إذا كنت مهتمًا بمقارنة أداء Mercurial وGit، فقم بإلقاء نظرة على هذا المقال.الاستنتاج هو:
يحقق كل من Git و Mercurial أرقامًا جيدة ولكنهما يقومان بمفاضلة مثيرة للاهتمام بين السرعة وحجم المستودع.Mercurial سريع في كل من الإضافات والتعديلات، ويحافظ على نمو المستودع تحت السيطرة في نفس الوقت.يعد Git سريعًا أيضًا، لكن مستودعه ينمو بسرعة كبيرة مع الملفات المعدلة حتى تقوم بإعادة حزمها - ويمكن أن تكون عمليات إعادة الحزم هذه بطيئة جدًا.لكن المستودع المعبأ أصغر بكثير من مستودع Mercurial.
يحتوي موقع Mercurial على وصف كبير لأوجه التشابه والاختلاف بين النظامين، موضحا الاختلافات في المفردات والمفاهيم الأساسية.باعتباري مستخدمًا لـ git منذ فترة طويلة، فقد ساعدني ذلك حقًا في فهم عقلية Mercurial.
إذا كنت تقوم بالترحيل من SVN، فاستخدم Mercurial لأن تركيبه أكثر قابلية للفهم لمستخدمي SVN.بخلاف ذلك، لا يمكنك أن تخطئ في أي منهما.لكن تحقق البرنامج التعليمي لجيت و HGinit قبل اختيار واحد منهم.
هذا الرابط قد يساعدك على فهم الفرقhttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
يعتقد بعض الناس أن أنظمة VCS يجب أن تكون معقدة.يشجعون على اختراع المصطلحات والمفاهيم في هذا المجال.ربما يعتقدون أن العديد من رسائل الدكتوراه حول هذا الموضوع ستكون مثيرة للاهتمام.من بين هؤلاء ربما هم الذين صمموا Git.
تم تصميم Mercurial بعقلية مختلفة.لا ينبغي للمطورين أن يهتموا كثيرًا بـ VCS، ويجب عليهم بدلًا من ذلك قضاء وقتهم في وظيفتهم الرئيسية:هندسة البرمجيات.يسمح Mercurial للمستخدمين باستخدام النظام وإساءة استخدامه بسعادة دون السماح لهم بارتكاب أي أخطاء غير قابلة للاسترداد.
يجب أن تأتي أي أداة احترافية مزودة بـ CLI مصممة بشكل واضح وبديهي.يمكن لمستخدمي Mercurial القيام بمعظم العمل من خلال إصدار أوامر بسيطة دون أي خيارات غريبة.في Git double Dash، الخيارات المجنونة هي القاعدة.يتمتع Mercurial بميزة كبيرة إذا كنت من مستخدمي CLI (ولأكون صادقًا، يجب أن يكون أي مهندس برمجيات يحترم نفسه كذلك).
على سبيل المثال، لنفترض أنك ارتكبت خطأً.لقد نسيت تعديل بعض الملفات.للتراجع عن الإجراء الذي قمت به في Mercurial، ما عليك سوى كتابة:
$ hg rollback
ستصلك بعد ذلك رسالة تفيد بأن النظام قد قام بإلغاء معاملتك الأخيرة.
في Git عليك أن تكتب:
$ git reset --soft HEAD^
حسنًا، لنفترض أن لديك فكرة عن موضوع إعادة التعيين.ولكن بالإضافة إلى ذلك، عليك أن تعرف ما هي عمليات إعادة التعيين "--soft" و"-hard" (أي تخمينات بديهية؟).أوه وبالطبع لا تنسَ الحرف "^" في النهاية!(الآن ما هو اسم ريتشي هو ذلك...)
يعد تكامل Mercurial مع أدوات الطرف الثالث مثل kdiff3 وmeld أفضل بكثير أيضًا.قم بإنشاء تصحيحاتك ودمج فروعك دون الكثير من الضجة.يشتمل Mercurial أيضًا على خادم http بسيط يمكنك تنشيطه عن طريق الكتابة
hg serve
ودع الآخرين يتصفحون مستودعك.
خلاصة القول هي أن Git يفعل ما يفعله Mercurial، بطريقة أكثر تعقيدًا وباستخدام CLI أدنى بكثير.استخدم Git إذا كنت تريد تحويل VCS لمشروعك إلى مجال بحث علمي.استخدم Mercurial إذا كنت تريد إنجاز مهمة VCS دون الاهتمام بها كثيرًا، والتركيز على مهامك الحقيقية.
