В отличие от SVN, Git является распределенной системой управления версиями.
Это значит, что пользователи полностью копируют основной репозиторий с сервера (или ПК) на свой компьютер, то есть, у каждого из них есть буквально полный бэкап, с которым они могут работать даже без подключения к Сети. При этом, как и в случае с SVN, чтобы залить изменения на сервер необходимо синхронизировать данные (если с момента загрузки копии репозитория в него были внесены изменения). Рабочие репозитории могут быть разветвленными и содержать свою иерархию.
Преимуществ Git несколько:
Несмотря на огромную популярность системы, не в последнюю очередь благодаря GitHub, многие пользователи не до конца понимают все возможности Git в командной строке и насколько она способна облегчить жизнь разработчика.
Задание псевдонимов может существенно ускорить работу, сэкономить кучу времени и упростить выполнение многих операций.
Алиас задаются при помощи основного файла конфигурации Git в виде:
git config --global alias.co checkout
git config –global alias.br branch
git config –global alias.ci commit
git config –global alias.st status
## Вместо главной команды будет достаточно ввести сокращение
Интересно, что таким образом можно создавать собственные команды, которых по умолчанию нет в системе, например:
git config --global alias.l "log --oneline --graph"
## Вывод лога в строчку и в графическом виде командой git l
Можно пойти еще дальше и воспользоваться алиас Bash, добавив нужные псевдонимы в файл конфигурации .bashrc:
alias g='git'
## g вместо git – идеально для ленивых
Если нужно, при помощи Git можно создать архив репозитория, чтобы, к примеру, отправить его, или выложить на файлообменник:
git archive master --format=zip --output=../project-18-04-2016.zip
## Также можно создать архив в формате tar
Примечательно, что таким образом сохраняются все рабочие файлы, но исключается папка .git. Так что для сохранения версионирования можно создать бандл всего проекта:
git bundle create ../repo.bundle master
## Будет создан бандл мастер-ветки
При необходимости Git умеет собирать неподтвержденные изменения, к которым можно вернуться немного позже. Делается это при помощи простой комманды:
git stash
## Временное скрытие изменений
Таким образом можно быстро “откатиться” до рабочей версии репозитория. При помощи этой функции даже можно перебрасывать изменения между ветками.
Для продолжения работы и модификации файлов нужно возвратить изменения из “тайника”:
git stash apply
## Извлечение несохраненных изменений
Git поддерживает множество (очень много) опций для настройки вывода журнала изменений. Данные можно вывести в расширенном, коротком и даже сжатом виде. К примеру, для вывода лога в одну линию со всеми сносками, тэгами и т.д нужно выполнить:
git log --oneline --decorate
## Удобный вывод лога со сносками
В этом случае журнал будет отформатирован так:
0e25143 (HEAD, master) Merge branch 'feature'
ad8621a (feature) Fix a bug in the feature
16b36c6 Add a new feature
23ad9ad (tag: v0.9) Add the initial code base
## Сноски, теги и вся доп. информация взята в скобки
А включение опции –graph обеспечит такое форматирование:
* 0e25143 (HEAD, master) Merge branch 'feature'
|
| * 16b36c6 Fix a bug in the new feature
| * 23ad9ad Start a new feature
* | ad8621a Fix a critical security issue
|/
* 400e4b7 Fix typos in the documentation
* 160e224 Add the initial code base
## Добавление ASCII графика
Но и это далеко не все возможности. Git поддерживает кастомное форматирование:
git log --pretty=format:"%cn committed %h on %cd"
## Выведет имя коммитера, хэш и дату коммита
А размещение %C(auto) перед исполнителем раскрасит результат выдачи (если это возможно).
Кстати, Git поддерживает цветную выдачу команд (опять же, если это возможно). Для этого нужно включить конфигурацию:
git config --global color.ui auto
## Раскраска команд в автоматическом режиме
Бывают ситуации, когда оказывается, что определенная функция приложения или проекта не работает, но невозможно сказать точно, когда появилась ошибка. Особенно, если было произведено большое количество изменений и коммитов.
В системе присутствует бинарный поиск git bisect. Для его работы необходимо задать последний коммит, в котором нужная функция работала (не обязательно точно знать какой именно, достаточно приближенного коммита) и последний нерабочий коммит. Важно понимать, что чем больше этот диапазон, тем дольше будет проходить поиск бага.
Весь процесс поиска будет примерно таким:
git bisect start
git bisect bad # Последняя нерабочая версия
git bisect good v2.6.13-rc2 # Известно, что в v2.6.13-rc2 функция работает
## Также можно использовать хэш вместо версий
Затем git проверит средний коммит в диапазоне, после чего его нужно скомпилировать и проверить работоспособность. Затем выполнить:
git bisect good # Если в этой ревизии функция работает
# или
git bisect bad # Если в этой ревизии функция не работает
## Здесь не нужно задавать номер ревизии или хэш
Затем весь процесс повторится необходимое количество раз, пока bisect не выявит первый плохой коммит, в котором и будет находиться баг.
После чего необходимо запустить git bisect reset для возврата к начальной точке всего процесса, чтобы уже в нормальном режиме исправить баг.
Весь функционал Git настолько обширен, что все его возможности просто невозможно выучить. А эти пять простых советов помогут упростить жизнь разработчика и весь процесс версионирования.
Прокси (proxy), или прокси-сервер — это программа-посредник, которая обеспечивает соединение между пользователем и интернет-ресурсом. Принцип…
Согласитесь, было бы неплохо соединить в одно сайт и приложение для смартфона. Если вы еще…
Повсеместное распространение смартфонов привело к огромному спросу на мобильные игры и приложения. Миллиарды пользователей гаджетов…
В перечне популярных чат-ботов с искусственным интеллектом Google Bard (Gemini) еще не пользуется такой популярностью…
Скрипт (англ. — сценарий), — это небольшая программа, как правило, для веб-интерфейса, выполняющая определенную задачу.…
Дедлайн (от англ. deadline — «крайний срок») — это конечная дата стачи проекта или задачи…