Каковы общие антипаттерны использования Git?

Большой шар изменений

Когда вы пишете сообщение о фиксации и не знаете, что поместить в однострочную сводку изменений, это, вероятно, означает, что вы поместили слишком много независимых вещей в одну фиксацию. Лучше разбить коммит на меньшие, используя «git rebase --interactive» и / или «git add --interactive» и друзей (например, «git stash --keep-index» для проверки сохраненных изменений).

Наличие единственной проблемы на коммит очень поможет при поиске ошибки с помощью "git bisect".

Перебазирование ветки, которая уже была опубликована или слита из (а затем повторная публикация этой ветки). Это заставит всех вас ненавидеть, так как это приведет к ужасным проблемам, поскольку вы только что переписали историю и потребуете, чтобы те люди, которые слились из вашей ветки до перебазирования, вручную исправили проблемы, вызванные вашей перебазированием.

См. Также http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/, чтобы узнать подробнее.

Это более общий характер, чем специфичный для git, но я видел много проектов с сообщениями о фиксации, такими как «bugfix», «fix foo» или «stuff». Не делайте этого, вместо этого используйте содержательные сообщения о фиксации, такие как «component fiz: Fix foo bug [\ n \ nExtra info]» и «Очистка пробелов». Вы будете благодарить себя, когда неизбежно посмотрите на историю своих коммитов позже, и вам не нужно будет говорить: «Что, черт возьми, я имел в виду, когда совершал« вещи »?»

Не используется git stash

Сценарий: вы работаете над функцией A. На это у вас ушло около 2 дней, и у вас около суток до ее завершения. У вас есть хороший код, но есть еще кое-что, что нужно сделать. Появляется ваш босс и говорит: «Эй, мне нужна функция Б прямо сейчас. Это займет 10 секунд».

Конечно - 10 секунд на запись, 2 дня работы потеряно. Или 2 часа, пытаясь закомментировать и взломать весь код, который вы написали за последние 2 дня, чтобы вернуть все в рабочее состояние.

git stash здесь, чтобы спасти положение. Просто введите git stash в командной строке в корне вашего проекта, и все ваши недавние изменения попадут в «тайник», который представляет собой стек изменений. Теперь вы вернулись туда, где были 2 дня назад, но ваша работа не потеряна. Вы вносите 10-секундное изменение, регистрируете его, затем набираете git stash pop, чтобы вернуть изменения (и удалить их из стека).

Как может быть очевидно, если у вас УЖАСНЫЙ день, вы можете спрятать его несколько раз, хотя очевидно, что чем больше вы это делаете, тем менее увлекательным может быть слияние, когда вы, наконец, git stash вытолкните их все. Если вам удастся накопить много денег за месяцы работы, у вас есть git stash list, чтобы просмотреть их, git stash pop и git stash drop, чтобы выбрать, какие из них стоит вернуть, а какие лучше просто выбросить, и git stash clear, если вы прячете только ужасные идеи .

Как человек, который много использовал SVN до того, как в последнее время начал все больше и больше использовать Git, я могу сказать, что моя худшая привычка - это делать git commit, git push, git commit, git push, git commit, _6 _...

Другими словами, всегда нажимать после каждой фиксации, как будто я все еще использую SVN.

После начального обучения, необходимого для отказа от этой привычки, мой рабочий процесс загружается быстрее. Одно из встроенных преимуществ Git - то, что локальная фиксация выполняется намного быстрее, чем удаленная фиксация. Еще одним преимуществом является то, что неспособность выполнять почти постоянные удаленные коммиты, вероятно, не убьет вас в будущем (особенно, если это небольшая команда, даже если это большая команда).

Для меня здесь нет реальной аналогии в SVN (который не вызывает " большой шар перемен " Якуба Наребски).

Перенос одного большого репозитория из SVN и т. Д. В одно большое репозиторий git - это явный антишаблон. Git спроектирован так, что вы не можете выполнять частичные проверки, и даже коммиты могут быть медленными. Лучше разбить на модули и использовать репо для каждого компонента. По крайней мере, репо на команду. Определенно не репо на организацию.