Каковы общие антипаттерны использования Git?
Как новичок Git, я понял, что использовал его, как если бы это была Subversion. например всегда работая над мастером, а не локально, прежде чем вытаскивать изменения и т.д. Это часто приводит к предотвращению ситуаций ручного слияния. Какие еще общие антипаттерны использования Git?
Ответы
Ответ 1
Большой шар изменений
Когда вы пишете сообщение фиксации, и вы не знаете, что вводить в однострочное резюме изменений, это, вероятно, означает, что вы ставите слишком много независимых вещей в одном коммите. Лучше разделить фиксацию на меньшее, используя "git rebase --interactive
" и/или "git add --interactive
" и друзей (например, "git stash --keep-index
", чтобы протестировать спрятанные изменения).
Если проблема с одной ошибкой на фиксацию будет чрезвычайно полезной при попытке найти ошибку, используя "git bisect
".
Ответ 2
Это более общий, чем git -специфичный, но я видел много проектов с сообщениями фиксации, такими как "bugfix" или "fix foo" или "stuff". Не делайте этого, вместо этого используйте значимые сообщения фиксации, такие как "компонент fiz: Fix foo bug [\n\nExtra info]" и "Очистка пробелов". Вы будете благодарить себя, когда вы неизбежно посмотрите на свою историю совершения позже, и не нужно говорить "Что, черт возьми, я имел в виду, когда я совершил" вещи "?"
Ответ 3
Не использовать git stash
Сценарий: вы работаете над функцией A. Это заняло у вас около 2 дней, и вы закончили день. Вы получили хороший код, но есть еще что делать. Ваш босс появляется и говорит: "Эй, мне нужна функция B. прямо сейчас. Должно занять 10 секунд".
Конечно - 10 секунд, чтобы написать, 2 дня работы потеряны. Или 2 часа пытаются прокомментировать и взломать весь код, который вы написали за последние 2 дня, чтобы вернуть все в рабочее состояние.
git stash
здесь, чтобы сохранить день. Просто введите git stash
в командной строке, в корне вашего проекта, и все ваши последние изменения перейдут в "stash", который представляет собой стек изменений. Теперь вы вернулись туда, где вы были 2 дня назад, но ваша работа не потеряна. Вы делаете 10-секундное изменение, проверяете его, затем введите git stash pop
, чтобы вернуть свои изменения (и удалить их из стека).
Как может показаться, если у вас есть ТЕРРИБЛЕЙНЫЙ день, вы можете забивать несколько раз, хотя, очевидно, чем больше вы это делаете, тем менее веселое слияние может быть, когда вы, наконец, git stash всплывают все. Если вам удастся накопить много задержек за месяцы работы, у вас есть git stash list
, чтобы просмотреть их, git stash pop
и git stash drop
, чтобы выбрать, какие из них стоит вернуть, и которые лучше всего просто бросить, и git stash clear
если вы только засунули ужасные идеи.
Ответ 4
Восстановить ветвь, которая уже была опубликована или объединена (а затем повторно опубликована эта ветка). Это заставит вас ненавидеть вас, так как это вызовет ужасные проблемы, так как вы только что перезаписали историю и потребовали, чтобы те люди, которые слились с веткой pre-rebase, исправили проблемы, возникшие в вашей rebase вручную.
Подробнее см. http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/.
Ответ 5
Как и кто-то, кто раньше использовал SVN, и начал использовать Git все больше и больше, я могу сказать, что моя худшая привычка делает git commit
, git push
, git commit
, git push
, git commit
, git push
...
Другими словами, всегда нажимать после каждого фиксации, например, я все еще использую SVN.
После первоначального обучения, необходимого для снижения этой привычки, мой рабочий процесс быстрее загружается. Один из встроенных благ Git заключается в том, что локальная фиксация намного быстрее, чем удаленная фиксация. Другое преимущество заключается в том, что неспособность делать почти постоянные удаленные коммиты, вероятно, не собирается снимать вашу ногу позже (особенно если это небольшая команда, даже если это большая команда).
Для меня здесь нет никакой реальной аналогии в SVN (которая не вызывает Jakub Narębski "большой шар изменений" против шаблона).
Ответ 6
Перенос одного большого репозитория из SVN и т.д. в один большой репозиторий git является определенным анти-шаблоном. Способ git разработан, вы не можете выполнять частичную проверку, и даже фиксации могут быть медленными. Лучше модулировать и использовать репо для каждого компонента. По крайней мере, репо за команду. Определенно не репо на организацию.