Даже старшие разработчики иногда допускают эти ошибки
Снова и снова я замечал, что в руководствах люди делают «ошибки» при использовании Git. Удивительно, но вы можете ожидать от них понимания того, что они делают. Я также иногда замечал, что это делают и старшие разработчики.
Эти «ошибки» не критичны, поскольку они ничего не ломают, но они показывают, что некоторые разработчики, даже опытные, неправильно понимают правила использования Git. Вероятно, потому, что они привыкли это делать с годами, а теперь стали привычкой. Поэтому важно с самого начала избегать их, чтобы это не вошло для вас в привычку.
В этой статье я покажу вам типичные ошибки, которые делают некоторые старшие разработчики при использовании Git, которые вы не должны начинать делать, а также покажу вам лучший подход.
1. Использование точки с запятой при связывании нескольких команд Git
Когда люди выполняют несколько команд Git, они иногда используют ;, чтобы объединить их в одну строку, например git add .;git commit -m "some stuff"; git push. В большинстве случаев это работает. Но почему так плохо?
Проблема с использованием ; заключается в том, что после сбоя одной из команд Git все последующие команды будут выполнены несмотря ни на что. Как вы понимаете, это может привести к нежелательным эффектам, если команда Git полагается на правильные результаты предыдущих команд Git.
Более безопасный способ - выполнить каждую команду Git одну за другой. Но лучше было бы использовать && вместо ;. Что делает &&, так это то, что он выполняет следующую команду Git только в том случае, если предыдущая выполняется правильно. Это также известно как короткое замыкание и в основном работает как if-case: если и только если команда Git выполняется правильно, будет выполнена следующая команда Git. В противном случае он полностью пропустит все последующие команды Git.
2. Использование git push -f
Использование git push -f или git push --force довольно распространено в некоторых компаниях. Иногда даже требуется force нажать фиксацию, например после git commit --amend или после git rebase. Итак, если он требуется, то чем он плох?
Прежде всего, лучше всего использовать git push -f соотв. git push --force только на ветке только с вами как единственным автором. В противном случае это может привести к проблемам с синхронизацией. Потому что принудительный толчок означает, что вы толкаете что бы то ни было - даже если вы перезаписываете чью-то фиксацию.
В большинстве случаев лучшим выбором будет git push --force-with-lease. Это гарантирует, что фиксация будет отправлена только тогда, когда вы сделаете фиксацию последним.
Единственный вариант, когда git push --force предпочтительнее git push --force-with-lease, - это когда вы намеренно хотите перезаписать фиксацию другого человека.
3. Слишком частое использование псевдонимов
Я не советую использовать псевдонимы. Я сам использую псевдонимы, чтобы сэкономить время. Я видел много пожилых людей, которые постоянно используют псевдонимы и работают очень продуктивно. Престижность им. Так почему это так плохо?
Проблема в том, что псевдонимы только локальные. Как только вы перейдете в другую рабочую среду, например вы получаете другой компьютер, ваш текущий компьютер сломан, и вам нужно использовать новый компьютер, или вы меняете работодателя, вы больше не можете использовать псевдонимы, потому что они хранятся на вашем локальном компьютере.
Некоторые разработчики запоминают только псевдонимы мышечной памятью и не понимают, как только их машина сломается, и им приходится работать на новой машине, на которой нет псевдонимов Git. Как будто они снова стали младшими разработчиками без псевдонимов.
Самый безопасный способ - использовать оригинальные команды Git. Если вы все еще хотите использовать псевдонимы, я бы порекомендовал вам создать шпаргалку Git в онлайн-репозитории Git, таком как GitHub, GitLab, BitBucket и т. Д. Таким образом, вы можете извлечь из этого, когда вам нужно переключить свой компьютер.
Вы сами использовали эти ошибки? При каких обстоятельствах? После прочтения этой статьи вы бы изменили свой рабочий процесс? Знаете ли вы больше распространенных ошибок или заблуждений, которые допускают даже опытные разработчики? Поделитесь ими ниже в разделе комментариев. Мне интересно знать. Может, я и сам делаю эти ошибки. Прокомментируйте, пожалуйста, ниже. Я был бы рад изменить свой образ жизни к лучшему.
