Вот что мне не нравится в git:
Прежде всего, я считаю, что распространенная идея противоречит реальности. Все, кто на самом деле использует git, делают это централизованно, даже Линус Торвальдс. Если бы ядро управлялось распределенным образом, это означало бы, что я не мог фактически загрузить "официальные" исходные коды ядра - их не было бы - мне пришлось бы решать, хочу ли я версию Линуса или версию Джо, или версия Билла. Это, очевидно, было бы нелепо, и поэтому существует официальное определение, которое Линус контролирует с помощью централизованного рабочего процесса.
Если вы согласитесь с тем, что вам нужно централизованное определение своего материала, тогда станет ясно, что роли сервера и клиента совершенно разные, поэтому догма о том, что клиентское и серверное программное обеспечение должно быть одинаковым, становится чисто ограничивающим. Догма о том , что клиент и сервер данные должны быть таким же , становится очевидно смешно, особенно в кодовом , что получило пятнадцать лет истории , что никто не заботится о , но все бы клон.
Что мы на самом деле хотим делать со всем этим старым хламом, так это закидывать его в шкаф и забывать о нем, как и любой другой VCS. Тот факт, что git каждый день перемещает все это туда-сюда по сети, очень опасен, потому что заставляет вас обрезать его. Такая обрезка требует принятия множества утомительных решений и может пойти не так. Таким образом, люди, вероятно, будут хранить целую серию репозиториев моментальных снимков с разных моментов истории, но разве не для этого изначально был нужен контроль версий? Эта проблема не существовала, пока кто-то не изобрел распределенную модель.
Git активно поощряет людей переписывать историю, и это, вероятно, одна из причин этого. Каждый нормальный VCS делает переписывание истории невозможным для всех, кроме администраторов, и гарантирует, что у админов нет причин рассматривать это. Поправьте меня, если я ошибаюсь, но, насколько я знаю, git не дает возможности предоставить обычным пользователям доступ на запись, но запрещает им переписывать историю. Это означает, что любой разработчик с недовольством (или все еще испытывающий трудности с кривой обучения) может выбросить всю кодовую базу на мусор. Как нам это затянуть? Что ж, либо вы делаете регулярные резервные копии всей истории, то есть сохраняете ее в квадрате, либо вы запрещаете доступ на запись всем, кроме какого-то бедняги, который получит все различия по электронной почте и объединит их вручную.
Давайте возьмем пример хорошо финансируемого большого проекта и посмотрим, как git для них работает: Android. Однажды я решил поиграться с самой системой андроид. Я узнал, что должен был использовать кучу скриптов под названием repo, чтобы добраться до их git. Некоторые из репозиториев работают на клиенте, а некоторые на сервере, но и то, и другое самим своим существованием иллюстрирует тот факт, что git неполон в любой из этих возможностей. Случилось так, что я не мог получить исходники около недели, а затем полностью сдался. Мне пришлось бы вытаскивать действительно огромный объем данных из нескольких разных репозиториев, но сервер был полностью перегружен такими людьми, как я. Время репо истекло, и его не удалось возобновить с того места, где он истек. Если git настолько распространен, можно подумать, что они Я сделал что-то вроде одноранговой сети, чтобы уменьшить нагрузку на этот сервер. Git распространяется, но это не сервер. Git + repo - это сервер, но репо не распространяется, потому что это просто специальная коллекция хаков.
Аналогичным примером неадекватности git является gitolite (и его предок, который, по-видимому, не работал так хорошо). Gitolite описывает свою работу как упрощение развертывания сервера git. Опять же, само существование этой штуки доказывает, что git не сервер, ни больше, чем клиент. Более того, этого никогда не будет, потому что, если бы он перерос в любой из них, это было бы предательством своих основополагающих принципов.
Даже если бы вы действительно верили в распределенную вещь, git все равно был бы беспорядком. Что, например, такое ветка? Они говорят, что вы неявно создаете ветвь каждый раз, когда клонируете репозиторий, но это не может быть то же самое, что ветка в одном репозитории. Так что это как минимум две разные вещи, называемые ветвями. Но тогда вы также можете перемотать репо и просто начать редактирование. Это похоже на второй тип ветки или опять что-то другое? Может быть, это зависит от того, какой тип репо у вас есть - о да - очевидно, репо тоже не очень ясная концепция. Есть нормальные и голые. Вы не можете перейти к обычному, потому что голая часть может не синхронизироваться с исходным деревом. Но вы не можете cvsimport на голый, потому что они не думали об этом. Так что вам нужно cvsimport на нормальный, клонируйте это в голую копию, которую ударили разработчики, и cvsexport это в рабочую копию cvs, которую еще нужно зарегистрировать в cvs. Кого можно беспокоить? Откуда все эти сложности? Из самой распространенной идеи. В конце концов, я отказался от гитолита, потому что он накладывал на меня еще больше ограничений.
Git говорит, что ветвление должно быть легким, но у многих компаний уже есть серьезная проблема с мошенническими ветвями, поэтому я подумал, что ветвление должно быть важным решением при строгом контроле. Вот где по-настоящему светит неволей ...
По желанию вам редко нужны ветки, потому что вы можете очень быстро манипулировать наборами изменений. Например, обычный рабочий процесс заключается в том, что вы синхронизируете с последней удачной версией в основной сети, а затем пишете свою функцию. Всякий раз, когда вы пытаетесь изменить файл, разница этого файла добавляется в ваш «набор изменений по умолчанию». Когда вы пытаетесь проверить набор изменений, он автоматически пытается объединить новости из основной ветки с вашим набором изменений (фактически перебазируя его), а затем фиксируется. Этот рабочий процесс осуществляется принудительно, вам даже не нужно его понимать. Таким образом, Mainline собирает историю изменений, которую вы можете легко исправить позже. Например, предположим, что вы хотите восстановить старую, скажем, предшествующую предпоследней. Вы выполняете синхронизацию с моментом перед нарушением изменений, помечаете затронутые файлы как часть набора изменений, синхронизировать с моментом после и объединиться с «всегда моим». (Там было кое-что очень интересное: синхронизация не означает наличия того же самого - если файл доступен для редактирования (то есть в активном наборе изменений), он не будет затираться синхронизацией, но будет помечен как подлежащий разрешению.) Теперь у вас есть список изменений, который отменяет нарушение. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю.
Теперь, предположим, что на полпути к вам подбегает кто-то и говорит вам бросить все и исправить какую-то ошибку. Вы просто даете своему списку изменений по умолчанию имя (на самом деле число), затем «приостанавливаете» его, исправляете ошибку в теперь пустом списке изменений по умолчанию, фиксируете его и возобновляете именованный список изменений. Типично, когда несколько списков изменений приостанавливаются одновременно, когда вы пробуете разные вещи. Это просто и конфиденциально. Вы получаете то, что действительно хотите, от режима ветвей, без соблазна откладывать дела на потом или отказываться от слияния с основной ветвью.
Я полагаю, что теоретически можно было бы сделать что-то подобное в git, но git делает возможным практически все, вместо того, чтобы утверждать рабочий процесс, который мы одобряем. Централизованная модель - это набор допустимых упрощений по сравнению с распределенной моделью, что является недопустимым обобщением. Он настолько чрезмерно обобщен, что в основном ожидает, что вы внедрите контроль версий поверх него, как это делает репо.
Другое дело - репликация. В git возможно все, так что вам нужно выяснить это самостоятельно. По желанию вы получаете эффективный кеш без сохранения состояния. Единственная конфигурация, которую ему нужно знать, - это где находится мастер, и клиенты могут указывать либо на мастер, либо на кеш по своему усмотрению. Это пятиминутная работа, и она не может пойти не так, как надо.
У вас также есть триггеры и настраиваемые формы для утверждения обзоров кода, ссылок на bugzilla и т. Д., И, конечно же, у вас есть ветки, когда они вам действительно нужны. Это непонятный случай, но он близок к тому, что его очень легко настроить и поддерживать.
В общем, я думаю, что если вы знаете, что собираетесь работать централизованно, как это делают все, вы могли бы также использовать инструмент, который был разработан с учетом этого. Git переоценивают из-за устрашающего остроумия Линуса и склонности людей следовать друг за другом, как овцы, но его основной смысл существования на самом деле не соответствует здравому смыслу, и, следуя ему, git связывает себе руки с две огромные догмы, что (а) программное обеспечение и (б) данные должны быть одинаковыми как на клиенте, так и на сервере, и это всегда будет усложнять централизованную работу.