Здравствуйте, Константин, Вы писали:
К>В своё время наша компания переезжала на git, и я занимался переносом истории и консультацией коллег. та же фигня.
К>Ожидалось, что первые несколько недель будут достаточно напряженными. На практике этого не случилось. Много вопросов было в первые пару дней, и сейчас возникают с периодичностью 1-2 раза в квартал.
О, завидую.
Я был несколько удивлён некоторыми особенностями гита при работе 10 людей одновременно.
Особенно когда касается правки чужих косяков — запушили в центральный репозиторий "не то".
Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
При этом те, кто успел сделать pull, находятся в странном положении — push от них приводит к возврату "косяка" — у них develop указывает уже на ошибочный коммит, и гит это разруливает как новые коммиты в develop, несмотря на то, что на ориджине они уже унесены вбок.
Здравствуйте, Dair, Вы писали:
D> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.
Здравствуйте, ., Вы писали:
D>> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции. .>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.
Всё так, когда история прямая.
А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно.
Здравствуйте, Dair, Вы писали:
D> .>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force. D> Всё так, когда история прямая. D> А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно.
Да он же самый. Просто надо -m указывать, до которого родителя откатываться.
А если ошибочных коммитов у вас многовато в команде, то попробуйте Gerrit.
Здравствуйте, ., Вы писали:
D>> А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно. .>Да он же самый. Просто надо -m указывать, до которого родителя откатываться. .>А если ошибочных коммитов у вас многовато в команде, то попробуйте Gerrit.
Ошибочных коммитов случается примерно один пуш (может быть из трёх коммитов) в два-три месяца, не катастрофа.
Спасибо, попробую.
Здравствуйте, ., Вы писали:
.>Здравствуйте, Dair, Вы писали:
D>> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции. .>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.
+1 У нас право разработчики не могут делать "force push" в центральный репозиторий. Обычно используется revert.
Как-то было, переписывали историю из-за коммита с лишними бинарниками. Добавили hook с ограничением на объём коммита
Обычно проблемы у людей возникают при merge кофликте во время rebase — приходилось иногда искать "потерянные" коммиты.
Ещё приходилось помогать с переименованием серии не запушенных коммитов, у нас есть ограничение на формат сообщения, и сервер не пускает коммиты без отсылок к bug tracking system.
Здравствуйте, dmitry_npi, Вы писали:
_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.
Это очередной топик из разряда "убедите меня".
CVS — первое поколение, SVN — второе поколение, GIT — третье поколение репозиториев.
1. В гите можно делать коммиты без связи с неким общим сервером.
2. Каждый репозиторий это сервер, не так критично, если какие-то из них будут уничтожены.
3. Некоторые люди таскают SVN репозитории на флешке, для других программистов это не лучше, чем если бы они его совсем не вели.
4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
5. Можно долго говорить, но мне за это не заплатят.
Здравствуйте, velkin, Вы писали:
V>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!
Здравствуйте, Sergey J. A., Вы писали:
V>>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений. SJA>Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!
Кстати, автор топика пошёл лёгким путём. А я поставил gitolite на свой сервер в интернете. Причём мне нужно было чтобы это работало совместно с chiliproject и jenkins, которые тоже крутятся на том сервере. И вот этот самый gitolite с его хаками действительно надо уметь готовить. Мне очень долго не удавалось настроить ничего, кроме парольного доступа по логинам юзеров. И только потом я дошёл до идентификации по ключу с парольной фразой для него.
Недостатки всегда можно придумать. Можно ещё преимущества выдавать за недостатки. Плюс удобным обычно кажется не то, что удобнее при параллельном изучении, а то, чем пользуешься несколько лет, а другое только начал изучать. В новых процессах часто срабатывает инерционность мышления. К примеру, тем кто не ведёт репозиторий это удобнее, чем пользоваться репозиторием. Но если научиться, то всё оказывается наоборот.
Здравствуйте, velkin, Вы писали:
_>>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.
V>Это очередной топик из разряда "убедите меня". V>CVS — первое поколение, SVN — второе поколение, GIT — третье поколение репозиториев. V>1. В гите можно делать коммиты без связи с неким общим сервером.
Не работать пока лежит сервер святое. Именно SVN кстати очень редко недоступен есть еще 100500 серверов без которых не поработаешь.
V>2. Каждый репозиторий это сервер, не так критично, если какие-то из них будут уничтожены.
Да, тут пробегала ссылка как это все на практике происходит. Делайте бекапы господа.
V>3. Некоторые люди таскают SVN репозитории на флешке, для других программистов это не лучше, чем если бы они его совсем не вели.
Не распарсил.
V>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
SVN намного проще. Причем как как CVSа так и GITа.
V>5. Можно долго говорить, но мне за это не заплатят.
Черт, и мне тоже.
Здравствуйте, velkin, Вы писали:
V>>>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений. SJA>>Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!
V>Недостатки всегда можно придумать. Можно ещё преимущества выдавать за недостатки. Плюс удобным обычно кажется не то, что удобнее при параллельном изучении, а то, чем пользуешься несколько лет, а другое только начал изучать. В новых процессах часто срабатывает инерционность мышления. К примеру, тем кто не ведёт репозиторий это удобнее, чем пользоваться репозиторием. Но если научиться, то всё оказывается наоборот.
Преимущества и недостатки — они возникают применительно к конкретной ситуации. Для сантехника у git нет никаких преимуществ перед svn-ом и наоборот.
Если нужно работать с картинками (или другими немержащимеся сущностями) то возможность локов в SVN вполне себе будет преимуществом перед GIT-ом.
Здравствуйте, Sergey J. A., Вы писали:
SJA> Преимущества и недостатки — они возникают применительно к конкретной ситуации. Для сантехника у git нет никаких преимуществ перед svn-ом и наоборот.
SJA> Если нужно работать с картинками (или другими немержащимеся сущностями) то возможность локов в SVN вполне себе будет преимуществом перед GIT-ом.
Локи — типичный антипаттерн. Это если проект тривиальный и всего один trunk-бранч. А когда проект усложнится чуток, и появятся release бранчи, поддержка пользователей чуть более старых версий, или feature-бранчи, то без мержей будет не обойтись, а мержи и локи не совместимы принципиально.
Т.е. это "преимущество" с локами лишь позволяет отложить проблему с бинарниками на потом, но не решает её. Хотя если рассчитвыать на то, что проект сдохнет быстрее, чем разрастётся, тогда использование локов может быть оправдано.
та же фигня.
