[Git, Системы управления версиями] 15 базовых советов по Git для эффективной работы каждый день
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).
Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.
Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.
1. Используй свежее
Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.
> git --version
git version 2.27.0
2. Настрой инструмент
Настройте себе публичный email не аффилированный с текущей компанией. Это позволит вам тонко настраивать идентификацию под разные репозитории и не задумываться о настройках по умолчанию, а GitHub будет показывать вашу активность, даже если вы смените место работы.
> git config --global user.email "gurugray@yandex.ru"
> cd company_project
> git config user.email "gurugray@manychat.com"
Если вы не пользуетесь консолью и vim'ом для редактирования, то вам стоит настроить и ваш редактор:
> git config --global core.editor "code --wait"
3. Настрой autocomplete
В моей практике не часто встречается разработчик, который не настраивал автокомплит если работал в консоли. Однако если вы переходите с другого инструмента, отсутствие этой функциональности сильно вас затормозит.
Git из коробки предоставляет набор скриптов для автокомплита, но если ваш shell, как у меня, более экзотичен — найдите и поставьте автокомплит именно для него.
4. Ускоряй часто используемое
Настройте себе псевдонимы (aliases) для быстрой работы. Для каждого человека удобство ощущается по-разному и я не рекомендую увлекаться однобуквенными псевдонимами, особенно если вы часто работаете на других рабочих станциях или используете ssh для удалённой работы на серверах — вам либо придётся тратить время на борьбу с различиями, либо растаскивать свой файл настроек по всем машинам (что не всегда плохо, конечно). Также не старайтесь заменить псевдонимами любое сочетание команд — половину вы забудете, а к половине привыкните более, чем оно того заслуживает.
Я перешёл на Git с SVN, потому для меня базовые псевдонимы перекочевали оттуда, а "b" — единственный однобуквенный псевдоним.
> git config --global alias.st "status -sb"
> git config --global alias.co "checkout"
> git config --global alias.ci "commit -a"
> git config --global alias.b "branch"
5. Обзорность помогает решать проблемы
Я часто работаю с историей проекта — нужно понять, что и когда влилось, и какие состояния проекта этому предшествовали. Часто важно знать последовательность комитов и топологию дерева истории. Git из коробки помогает показать дерево истории проекта:
> git log --oneline --graph --branches
Но для полноты картины хочется видеть и авторов, и даты и в удобной расцветке, потому мой псевдоним выглядит не так дружелюбно с параметром --pretty=format::
> git log --graph --date=short --branches --pretty=format:'%C(yellow)%h%C(reset) %ad | %C(75)%s%C(reset) %C(yellow)%d%C(reset) [%an]'
6. Следуй протоколу
Всегда клонируйте репозиторий, в который вносите правки по git+ssh протоколу, это работает быстрее чем по http и сэкономит время в процессе работы:
> git clone git@github.com:gurugray/gurugray
7. Разделяй источники
Если вы работаете с репозиториями по «форковой» модели (когда к основному репозиторию есть доступ только на чтение, а все pull-request'ы подаются из форка) называйте основной репозиторий upstream это поможет не путаться в командах отведения веток и push'а в свой origin. Не забывайте про протокол, если репозиторий открыт только для чтения, то его можно клонировать без ssh-слоя, что тоже даст экономию времени в процессе работы:
> git clone git://github.com/gurugray/gurugray -o upstream
8. Контролируй процесс
Не используйте команду pull, это составная команда и делает несколько действий сразу. Часто при работе с репозиторием новички допускают ошибку не понимая, как эта команда обновляет текущую ветку, и замусоривают свою историю или неправильно работают с дефолтной веткой. Я рекомендую явно обновлять репозиторий локально, затем явно обновлять свою ветку:
> git fetch --all
> git rebase my_feature upstram/master
9. Не вводи себя в заблуждение
Никогда не храните дефолтную ветку локально, всегда отводите ветку от актуальной удалённой, это позволит избежать путаницы и точно знать от чего и в какое время вы отвели ветку:
> git fetch --all
> git checkout -b my_feature upstream/master
> git branch -D master
10. Не бойся исправлять
Если вы следите за чистотой истории и хотите исправить состояние проекта зафиксированное несколько комитов назад, то достаточно закомититься с параметром --fixup= и передать нужный хэш комита для последующего причёсывания истории
> git commit -m "Feature A is done"
> ...
> git commit -m "Feature B is done"
> git commit --fixup=fe2f857
> git log --oneline
a5050e7 fixup! Feature A is done
633e33f Feature B is done
...
fe2f857 Feature A is done
cb5db88 Previous commit
11. Не бойся быстро исправлять
Один из полезных псевдонимов — замена последнего комита текущим состоянием, позволяет «подклеить» текущее состояние к последнему зафиксированному, при этом не включая режим редактирования сообщения:
> git config --global alias.fixlast "commit --all --amend --no-edit"
12. Перебазируй
Научитесь и пользуйтесь командой rebase в интерактивном режиме и с параметром --autosquash с которым использование --fixup будет ещё более удобным, а сам ребейз помогает причёсывать историю и аккуратно оформить комиты, например по принятым у вас guidline'ам, до подачи pull-request'а для успешного его принятия.
> git rebase -i --autosquash cb5db88
pick fe2f857 Feature A is done
fixup a5050e7 fixup! Feature A is done
pick 733e2ff Feature B is done
> git log --oneline
633e33f Feature B is done
...
5778cbb Feature A is done
cb5db88 Previous commit
13. Сбрасывай ненужное
Научитесь и пользуйтесь командой reset она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью:
> git reset @~4
> git commit --all
14. Контролируй деструктивный push
Если вы хотите запушить изменённую историю, советую использовать полный синаксис команды и не использовать ключ --force -f, это позволит не привыкать к настройкам по-умолчанию и не приведёт к случайным перетираниям истории на сервере:
> git push origin +feature
15. Помни про летописца
Не забывайте про reflog эта команда поможет разобраться с проблемами в локальном репозитории если что-то пошло не так — спасательный круг для новичков, к которому они редко подходят:
> git reflog
> ...
> git reset --hard FOUND_HASH
Все советы выше помогут быстрее работать с репозиторием и быстрее получать ответы об истории разработки поиска ошибок и выявления узких мест в регламенте работы, но эта тема для отдельной статьи.
Есть ещё много возможностей для тонкой настройки Git'а под себя и для решения более специфичных кейсов, но описанные выше возможности инструмента позволяют вам каждый день удобно работать не теряя в скорости.
===========
Источник:
habr.com
===========
Похожие новости:
- [GitHub, Python, Алгоритмы, Веб-аналитика] Как проанализировать рынок фотостудий с помощью Python (1/3). Парсинг данных
- [Резервное копирование, Хранение данных, Хранилища данных, Накопители] Практические кейсы по созданию IT-инфраструктуры на базе дисковых полок Western Digital Ultrastar
- [Интервью, Удалённая работа, Фриланс] Интервью с Дарреном Мерфом, руководителем удаленной работы в GitLab
- [Git, IT-компании, Open source] Microsoft выпустила утилиту ProcMon (Process Monitor) для Linux
- [Информационная безопасность, Управление разработкой] Вебинар «Secure SDLC: безопасность как фундаментальный аспект разработки»
- [Облачные вычисления, История IT, Исследования и прогнозы в IT] Бархатная перчатка Microsoft
- [GitHub, Open source, Хранилища данных] GitHub разместил свой архив в арктическом хранилище Arctic World Archive
- [GitHub, Open source] GitHub создал архив ПО с открытым исходным кодом в арктическом хранилище
- [IT-компании, Информационная безопасность, Управление разработкой] Вебинар «Secure SDLC: безопасность как фундаментальный аспект разработки»
- GitHub сохранил архив открытого кода в арктическом хранилище
Теги для поиска: #_git, #_sistemy_upravlenija_versijami (Системы управления версиями), #_git, #_tutorial, #_hints, #_blog_kompanii_manychat (
Блог компании ManyChat
), #_git, #_sistemy_upravlenija_versijami (
Системы управления версиями
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 04:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ). Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта. Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.  1. Используй свежее Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок. > git --version
git version 2.27.0 2. Настрой инструмент Настройте себе публичный email не аффилированный с текущей компанией. Это позволит вам тонко настраивать идентификацию под разные репозитории и не задумываться о настройках по умолчанию, а GitHub будет показывать вашу активность, даже если вы смените место работы. > git config --global user.email "gurugray@yandex.ru"
> cd company_project > git config user.email "gurugray@manychat.com" Если вы не пользуетесь консолью и vim'ом для редактирования, то вам стоит настроить и ваш редактор: > git config --global core.editor "code --wait"
3. Настрой autocomplete В моей практике не часто встречается разработчик, который не настраивал автокомплит если работал в консоли. Однако если вы переходите с другого инструмента, отсутствие этой функциональности сильно вас затормозит. Git из коробки предоставляет набор скриптов для автокомплита, но если ваш shell, как у меня, более экзотичен — найдите и поставьте автокомплит именно для него. 4. Ускоряй часто используемое Настройте себе псевдонимы (aliases) для быстрой работы. Для каждого человека удобство ощущается по-разному и я не рекомендую увлекаться однобуквенными псевдонимами, особенно если вы часто работаете на других рабочих станциях или используете ssh для удалённой работы на серверах — вам либо придётся тратить время на борьбу с различиями, либо растаскивать свой файл настроек по всем машинам (что не всегда плохо, конечно). Также не старайтесь заменить псевдонимами любое сочетание команд — половину вы забудете, а к половине привыкните более, чем оно того заслуживает. Я перешёл на Git с SVN, потому для меня базовые псевдонимы перекочевали оттуда, а "b" — единственный однобуквенный псевдоним. > git config --global alias.st "status -sb"
> git config --global alias.co "checkout" > git config --global alias.ci "commit -a" > git config --global alias.b "branch" 5. Обзорность помогает решать проблемы Я часто работаю с историей проекта — нужно понять, что и когда влилось, и какие состояния проекта этому предшествовали. Часто важно знать последовательность комитов и топологию дерева истории. Git из коробки помогает показать дерево истории проекта: > git log --oneline --graph --branches
Но для полноты картины хочется видеть и авторов, и даты и в удобной расцветке, потому мой псевдоним выглядит не так дружелюбно с параметром --pretty=format:: > git log --graph --date=short --branches --pretty=format:'%C(yellow)%h%C(reset) %ad | %C(75)%s%C(reset) %C(yellow)%d%C(reset) [%an]'
6. Следуй протоколу Всегда клонируйте репозиторий, в который вносите правки по git+ssh протоколу, это работает быстрее чем по http и сэкономит время в процессе работы: > git clone git@github.com:gurugray/gurugray
7. Разделяй источники Если вы работаете с репозиториями по «форковой» модели (когда к основному репозиторию есть доступ только на чтение, а все pull-request'ы подаются из форка) называйте основной репозиторий upstream это поможет не путаться в командах отведения веток и push'а в свой origin. Не забывайте про протокол, если репозиторий открыт только для чтения, то его можно клонировать без ssh-слоя, что тоже даст экономию времени в процессе работы: > git clone git://github.com/gurugray/gurugray -o upstream
8. Контролируй процесс Не используйте команду pull, это составная команда и делает несколько действий сразу. Часто при работе с репозиторием новички допускают ошибку не понимая, как эта команда обновляет текущую ветку, и замусоривают свою историю или неправильно работают с дефолтной веткой. Я рекомендую явно обновлять репозиторий локально, затем явно обновлять свою ветку: > git fetch --all
> git rebase my_feature upstram/master 9. Не вводи себя в заблуждение Никогда не храните дефолтную ветку локально, всегда отводите ветку от актуальной удалённой, это позволит избежать путаницы и точно знать от чего и в какое время вы отвели ветку: > git fetch --all
> git checkout -b my_feature upstream/master > git branch -D master 10. Не бойся исправлять Если вы следите за чистотой истории и хотите исправить состояние проекта зафиксированное несколько комитов назад, то достаточно закомититься с параметром --fixup= и передать нужный хэш комита для последующего причёсывания истории > git commit -m "Feature A is done"
> ... > git commit -m "Feature B is done" > git commit --fixup=fe2f857 > git log --oneline
a5050e7 fixup! Feature A is done 633e33f Feature B is done ... fe2f857 Feature A is done cb5db88 Previous commit 11. Не бойся быстро исправлять Один из полезных псевдонимов — замена последнего комита текущим состоянием, позволяет «подклеить» текущее состояние к последнему зафиксированному, при этом не включая режим редактирования сообщения: > git config --global alias.fixlast "commit --all --amend --no-edit"
12. Перебазируй Научитесь и пользуйтесь командой rebase в интерактивном режиме и с параметром --autosquash с которым использование --fixup будет ещё более удобным, а сам ребейз помогает причёсывать историю и аккуратно оформить комиты, например по принятым у вас guidline'ам, до подачи pull-request'а для успешного его принятия. > git rebase -i --autosquash cb5db88
pick fe2f857 Feature A is done fixup a5050e7 fixup! Feature A is done pick 733e2ff Feature B is done > git log --oneline
633e33f Feature B is done ... 5778cbb Feature A is done cb5db88 Previous commit 13. Сбрасывай ненужное Научитесь и пользуйтесь командой reset она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью: > git reset @~4
> git commit --all 14. Контролируй деструктивный push Если вы хотите запушить изменённую историю, советую использовать полный синаксис команды и не использовать ключ --force -f, это позволит не привыкать к настройкам по-умолчанию и не приведёт к случайным перетираниям истории на сервере: > git push origin +feature
15. Помни про летописца Не забывайте про reflog эта команда поможет разобраться с проблемами в локальном репозитории если что-то пошло не так — спасательный круг для новичков, к которому они редко подходят: > git reflog
> ... > git reset --hard FOUND_HASH Все советы выше помогут быстрее работать с репозиторием и быстрее получать ответы об истории разработки поиска ошибок и выявления узких мест в регламенте работы, но эта тема для отдельной статьи. Есть ещё много возможностей для тонкой настройки Git'а под себя и для решения более специфичных кейсов, но описанные выше возможности инструмента позволяют вам каждый день удобно работать не теряя в скорости. =========== Источник: habr.com =========== Похожие новости:
Блог компании ManyChat ), #_git, #_sistemy_upravlenija_versijami ( Системы управления версиями ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 04:09
Часовой пояс: UTC + 5