Git - один из самых популярных инструментов контроля версий, используемых сегодня разработчиками. В этом посте я расскажу о некоторых полезных советах, приемах и приемах, которым нужно следовать при использовании git, которые я узнал во время работы с git и GitHub.
Управление несколькими удаленными репозиториями
Git позволяет вам управлять проектами, имеющими несколько удаленных репозиториев. Вы можете проверить существующие удаленные репозитории, выполнив следующую команду. Эта команда выводит список всех существующих пультов дистанционного управления и соответствующих URL-адресов.
git remote -v
Вы можете добавить новый пульт, указав идентификатор и URL-адрес репозитория следующим образом.
git remote add <identifier> <URL> example: git remote add public [email protected]:madawas/sample-project.git
Пульт также можно переименовать или удалить из следующих команд.
rename: git remote rename <old_identifier> <new_identifier> remove: git remote rm <identifier>
Просмотр и поиск в истории коммитов
Журнал Git отображает историю фиксации текущей ветки. Историю фиксации можно просто просмотреть с помощью команды git log. Помимо простого просмотра журналов в представлении по умолчанию, историю фиксации можно фильтровать и форматировать по-разному.
Журналы можно просмотреть в сводном режиме, выполнив одну из следующих команд. Команда shortlog суммирует историю фиксации и группирует каждую фиксацию по автору и заголовку. Если задана опция oneline, каждая фиксация будет отображаться в одной строке.
git shortlog git log --oneline
Флаг --decorate заставляет git log отображать все ссылки (например, ветки, теги и т. Д.), Относящиеся к каждой фиксации.
git log --decorate git log --oneline --decorate
Количество добавленных строк и количество удаленных строк для каждого файла можно просмотреть в журналах с помощью флага --stat, и вы сможете увидеть полную разницу, введенную из фиксации, используя -p
git log --stat git log -p
Если вы хотите просмотреть структуру ветвей с журналом, вы можете использовать опцию --graph. Это сгенерирует граф ASCII с описанием фиксации. Использование флага --graph с --oneline и --decorate улучшает читаемость графика.
git log --graph --oneline --decorate * e086ecf correct formatting issues | * 46d85a3 removing console logs | * cdff923 validation improvements * | 3bef943 Merge pull request #272 from alice/fix-261 |\ \ | * | 6651dbb Fixed a typo | * | b240957 Fixing #261 |/ / * | 4883a57 prepare for next development iteration * | 4546e32 (tag: v1.0.20) prepare release v1.0.20 * | a4d378f Merge pull request #266 from madawas/master |\ \ | * | 2ebd9e3 (origin/master, origin/HEAD) Adding build config * | | [Release 1.0.19] prepare for next development iteration * | | 6646a2f (tag: v1.0.19) prepare release v1.0.19 * | | a49cdd9 Merge pull request #271 from bob/master |
Помимо форматирования представления истории коммитов, вы также можете фильтровать историю коммитов, чтобы найти коммиты в истории. Вы можете ограничить количество коммитов, отображаемых в журнале, фильтровать по дате, автору, файлу и даже искать коммиты по сообщениям следующим образом.
Limiting number of commits git log -<number> example: git log -5 Filter commits by date git log --after="25-01-2018" git log --after="01-01-2018" --before="25-01-2018" Filter commits by author git log --author="Madawa" Filter commits by file git log -- Foo.java Bar.java Search for commits git log --grep="code formatting"
Написание лучшего сообщения о фиксации
Разница фиксации сообщит вам только, какие строки были изменены, но не почему эти строки были изменены. Хорошо написанное сообщение о фиксации - лучший способ сообщить, почему было внесено конкретное изменение; коллегам-разработчикам. Также, если вы используете продвинутые git log методы фильтрации для поиска коммитов, важно иметь содержательное и хорошо структурированное сообщение о фиксации.
Так как же написать сообщение о фиксации?
Сообщение фиксации должно содержать тему / заголовок, в котором резюмируется изменение. Длина темы фиксации не должна превышать 50 символов. Затем тело объясняет, что, почему и как в отношении изменения. Наконец, включите ссылку на проблемы, с которыми связано изменение.
Ниже приведены несколько примеров хорошо составленных сообщений о фиксации.
Если вы пишете сообщение фиксации из командной строки, вы можете использовать несколько флагов -m, чтобы организовать сообщение фиксации по разным абзацам. Git объединяет значения каждого -m флага в отдельный абзац.
git commit -m "Subject" -m "Body" -m "Related issues"
Однако, если это подробное объяснение, довольно сложно отформатировать сообщение фиксации в указанном выше методе. Поэтому рекомендуется использовать подходящий текстовый редактор для написания сообщения о фиксации. Git предложит текстовый редактор по умолчанию, когда вы попытаетесь выполнить фиксацию без предоставления сообщения фиксации.
Сохранение истории в чистоте
Git - это инструмент для совместной работы разработчиков. Обычно несколько разработчиков работают параллельно над одним и тем же проектом и часто совершают коммиты. Если вы пишете сложную функцию локально и часто извлекаете последние изменения из восходящей ветки, в ветке, с которой вы работаете, будет несколько коммитов слияния. Это испортит историю коммитов. Важно вести чистую и содержательную публичную историю коммитов. В этом контексте пригодится Git --rebase.
Когда доходит до повторного базирования истории коммитов, это дискуссионная тема, потому что изменение базы рассматривается как опасный и разрушительный процесс. Однако, если вы знаете, что делаете, и когда использовать --rebase, а когда не использовать, не возникнет проблем с изменением базы, чтобы проект оставался чистым.
Никогда не используйте git rebase в общедоступной ветке
Почему? Хорошо подумайте, что произойдет, если вы переустановите главную ветку в свою локальную ветку. Это затронет всех, кто работает с основной веткой, и их локальная история и история вилки больше не будут совпадать.
Когда следует использовать перебазирование?
Перебазирование Git можно использовать для очистки вашей локальной истории коммитов. Например, предположим, что вы работаете над функцией или исправлением самостоятельно и хотите регулярно синхронизироваться с последними изменениями в основной ветке. Если вы используете git pull каждый раз, когда хотите синхронизировать, ваша история коммитов будет загрязнена коммитами слияния. (Git pull извлечет контент и попытается выполнить слияние) Поэтому вместо извлечения вы можете выполнить перебазирование и извлечение, выполнив следующую команду.
git pull --rebase remote master
Сначала будет извлечено содержимое основной ветки и воспроизведены ваши коммиты поверх текущей HEAD основной ветки. В истории коммитов будет показано, как вы применили свои изменения как самые последние коммиты.
Инструмент rebase, предлагаемый git, очень мощный. Помимо очистки истории коммитов в локальной ветке, интерактивный режим инструмента rebase можно использовать для изменения ваших коммитов.
Делайте часто, лучше позже, публикуйте один раз
Вышеуказанное считается лучшим методом использования git. От вас не требуется писать идеальное сообщение о фиксации в начале или беспокоиться о том, действительно ли фиксация требуется. Когда вы делаете существенное изменение, просто сделайте коммит с сообщением, что вы можете понять, для чего этот коммит. Когда вы будете готовы к публикации, вы можете изменить коммиты и опубликовать.
git rebase -i HEAD~<number_of_commits> example: git rebase -i HEAD~5 git rebase -i <branch_you_want_to_rebase_against> example: git rebase -i origin/feature-1
Когда вы запускаете любую из команд, открывается редактор по умолчанию со следующими параметрами.
Как видно из приведенного выше изображения, git предоставил документацию вместе с доступными опциями для простоты их использования. Таким образом, вы можете улучшить свои коммиты, используя интерактивную перебазировку перед публикацией. Вы можете обратиться к документации git rebase за дополнительными объяснениями.
Временное сохранение вашей работы
Предположим, что вы хотите посетить что-то еще срочное. Что вы собираетесь делать с уже внесенными изменениями? Есть два варианта. Первый - просто зафиксируйте изменения и переключитесь на срочную работу. Если по какой-либо причине вы не хотите совершать никаких действий, вы можете просто использовать stash, чтобы временно сохранить свою работу.
Вы можете просто использовать команду git stash, чтобы временно сохранить все изменения в стеке, и git apply или git pop, чтобы извлечь самое последнее сохраненное изменение и применить его, когда вы снова будете готовы к работе, но есть много других параметров, поддерживаемых git для использования в сочетании с stash.
git stash list
Вышеупомянутая команда перечислит все тайники, которые вы сделали на данный момент. Если вы попробуете эту команду, вы заметите, что каждый тайник имеет идентификатор в формате: stash@{<id>} Вы можете обратиться к этим идентификаторам, если хотите применить конкретный тайник, как показано ниже. По умолчанию команда Apply применит stash@{0}
git stash apply stash@{2}
Когда вы используете pop, а не apply, чтобы повторно применить изменения, которые вы временно сохранили, он применит изменение и удалит тайник из списка тайников. Если вы специально хотите удалить тайник из списка, вы можете использовать любую из следующих команд.
git stash drop //drops the latest stash
git stash drop stash@{1} //drops a specific stash
Вы можете удалить весь список тайников один раз, используя следующую команду.
git stash clear
Если у вас в списке тайников много тайников, как их идентифицировать? Один из приемов - использовать сообщения тайника при создании тайника, как показано ниже.
git stash save "stash message"
Также вы можете просмотреть изменения, внесенные в каждый тайник, используя команду show. Команда show покажет вам количество добавлений и удалений в каждом файле и предоставив флаг -p, можно будет просмотреть полное различие. Подобно предыдущим командам, вы можете указать идентификатор тайника для просмотра различий в конкретном тайнике.
git stash show
git stash show -p
git stash show stash@{1}
git stash show -p stash@{1}
Передача только определенных изменений в другую ветку
Иногда, работая в ветке, вы можете захотеть выбрать только коммит или несколько коммитов и скопировать эти изменения в другую ветку. Например, предположим, что существует старая ветка выпуска, и вы хотите перенести конкретное исправление ошибки в эту ветку выпуска. Gitcherry-pick - это команда, которую вам нужно использовать в этой ситуации. Использовать эту команду довольно просто. Сначала проверьте git log и скопируйте хеш фиксации требуемой фиксации, которую нужно скопировать. Затем перейдите в соответствующую ветку и введите следующую команду.
git cherry-pick <commit_hash> example: git cherry-pick ba5f6273e0a01d6b397b4efb0ffe490a93a2d342
Вот так! Если вы просмотрите журнал текущей ветки, вы увидите новую фиксацию с изменениями, точно такими же, как и выбранная вами фиксация.
Поиск плохой фиксации
Допустим, вы внезапно замечаете сбой сборки в своем проекте, которого не было вчера. Вы обнаружили, что сегодня было отправлено около 10 коммитов, и вы хотите выяснить, какая фиксация вызвала сбой сборки. Git также предоставляет инструмент для этого… !! Это мерзавец bisect
Прежде чем запускать bisect, вам нужно найти фиксацию на графике истории, в которой проект построен идеально. Затем вы можете начать делить пополам и отметить хорошую фиксацию.
git bisect start git bisect good <hash_of_the_good_commit>
Затем вы должны отметить плохую фиксацию следующим образом.
git bisect bad <hash_of_the_bad_commit>
Затем биссектура запустится и укажет вам на фиксацию. Вы можете протестировать проект и отметить, хороший или плохой коммит.
git bisect good or git bisect bad
Вы можете отмечать коммиты как хорошие или плохие, пока git не обнаружит первый плохой коммит.
<commit_hash> is the first bad commit
Как только вы нашли фиксацию, вы можете сбросить рабочую копию в ее предыдущее состояние, как показано ниже.
git bisect reset
Это всего лишь несколько советов и практик, которые я усвоил, используя git для своих программных проектов. Git - очень мощный инструмент для управления исходным кодом и контроля версий. Надеюсь, вы все что-то узнали, и спасибо, что прочитали… !!!
