Как открыть git bash в linux

Git. Краткое руководство по терминалу

Данное краткое руководство демонстрирует основные команды в терминале Bash:

Bash (Linux/Mac)
Git Bash (Windows)

Открытие терминала

Первая задача: открыть терминал сразу в нужном каталоге.

Linux

В Linux достаточно щёлкнуть правой кнопкой мыши на каталоге и выбрать пункт меню Open in Terminal или Открыть в терминале :

Mac

В Mac всё немного сложнее, необходимо настроить отображение этого пункта меню в Finder.

Для этого необходимо перейти в Системные настройки , затем пункт меню Клавиатура , в разделе Службы выбрать раздел Файлы и папки и поставить флажок напротив Новый терминал по адресу папки :

После чего при клике правой кнопкой мыши на каталоге появится необходимый пункт меню:

Windows (Git Bash)

В Windows всё достаточно просто — клик правой кнопкой мыши на каталоге и выбор Git Bash Here :

Первоначальная настройка Git

После установки Git первое, что мы сделаем — укажем наши имя и адрес электронной почты. Это важно, потому как этой информацией подписывается каждый коммит (кто сделал изменения и его электронная почта). Для настройки потребуется ввести команды:

$ git config --global user.name "Thorin Oakenshield" $ git config --global user.email ereborsons@stone.com

Если указана опция —global , настройки применятся глобально, то есть для всех ваших действий в системе Git. Без этой опции настройки применяются локально, для текущего репозитория, и не влияют на глобальные настройки.

Пути

Одно окно терминала подразумевает, что вы можете в один момент времени находиться только в одном каталоге, который называется Current Working Directory (текущий каталог), так же как и в одном открытом окне Nautilus , Finder или проводника Windows.

Вы можете выполнять команды относительно текущего каталога или относительно абсолютного пути.

Абсолютный путь — это путь, начинающийся от корня файловой системы. Корень файловой системы обозначается символом / .

Например, в Git Bash (Windows) абсолютный путь для каталога Program Files , будет чаще всего выглядеть следующим образом: /c/Program Files/ .

Для домашнего каталога в Ubuntu (Linux), абсолютный путь будет выглядеть следующим образом: /home/user/ , где user — имя пользователя.

Bash (Git Bash в том числе) используют символ / для разделения каталогов.

Ещё два специальных обозначения помимо корня файловой системы:

. — обозначает текущий каталог;
.. — обозначает родительский каталог.

Важно: в терминале символ ` ` (пробел) является символом, разделяющим команды и опции. Поэтому если в пути есть пробел, то варианта два:

заключать путь в кавычки, то есть «Program Files» ;
использовать символ backslash для экранирования пробела: Program\ Files .

Переменные окружения

Командная оболочка устанавливает ряд переменных, которые выполняют специфические функции. Так, переменная с именем PATH содержит список путей, в которых будет производиться поиск программы, если вы наберёте её название в терминале.

Для вывода содержимого конкретной переменной используется команда echo следующим образом:

$ echo $PATH

Команда printenv позволяет отобразить все переменные окружения:

$ printenv

Видно, что в переменных окружения содержится достаточно много информации о системе.

Автодополнение

В командных оболочках работает автодополнение по клавише Tab :

дополняются имена команд;
дополняются пути.

Используйте автодополнение, так как оно позволяет сократить время на набор команды.

Ключевые команды

В этом разделе будут описаны ключевые команды, необходимые нам для работы. Естественно, список этот далеко не полный.

Текущий рабочий каталог

pwd — сокращение от “Print Working Directory”.

Отображение текущего рабочего каталога:

Смена рабочего каталога

cd — сокращение от “Change Directory”.

Переход в определённый каталог:

path может быть как абсолютным, так и относительным путём.

Например, перейти на каталог выше:

Перейти в подкаталог src :

$ cd src

Если перед путём нет слеша — он трактуется как относительный (относительно текущего каталога).

Листинг каталога

ls — сокращение от “List”.

Отображает листинг (содержимое каталога):

По умолчанию, ls не отображает файлы, начинающиеся с . , например, .gitignore . Для отображения таких файлов нужно использовать флаг -a :

$ ls -a

Создание файлов

Для создания файлов используются специальные программы (например, для создания текстовых файлов — текстовые редакторы).

В рамках рассмотрения Bash мы рассмотрим два текстовых редактора, которые позволят вам создавать и редактировать файлы в псевдографическом режиме.

nano

nano — простой текстовый редактор.

Для того, чтобы создать файл достаточно ввести команду nano и имя файла:

$ nano README.md

Откроется редактор следующего вида:

Пункты меню в нижней части вызываются с помощью горячих клавиш, где символ ^ обозначает клавишу Ctrl .

То есть чтобы записать файл и выйти следует последовательно нажать Ctrl + O (запись) и Ctrl + X (выход).

Редактор nano установлен в большинстве Unix-подобных операционных системах и Git Bash.

Vim

Редактор Vim (a programmer’s text editor) — профессиональный редактор, позволяющий достичь максимальной производительности при работе с любыми текстовыми файлами. Настолько популярен, что для любой графической среды (IDE, текстовых редакторов вроде VS Code, Atom, Sublime) всегда есть плагин, включающий возможность редактирования кода в режиме “Vim Mode”.

На освоение работы в Vim нужно потратить достаточно много времени, для этого вы можете воспользоваться интерактивным учебником vimtutor :

$ vimtutor

Мы лишь скажем, что для выхода из этого редактора (если вы всё-таки осмелились его открыть) нужно нажать клавишу Esc , затем ввести команду :q! — это позволит вам закрыть открытый файл без сохранения изменений.

VS Code

В видео-лекциях используется VS Code. В Windows вы можете правой кнопкой открыть каталог сразу в VS Code.

В Mac OS и Linux вы можете открыть терминал по адресу папки и в терминале выполнить команду code . & , которая откроет выбранный вами каталог в этом редакторе.

Если ни то, ни другое у вас не получилось, то просто откройте VS Code и через File — Open откройте нужный каталог.

Создание каталогов

mkdir — сокращения от “Make Directory”.

Позволяет создавать каталоги (создаст каталог tmp в текущем каталоге):

$ mkdir tmp

Стоит обратить внимание на поведение при создании нового каталога в текущей директории. После команды mkdir name ваше текущее расположение в терминале не изменится. Для того, чтобы работать внутри созданного каталога, в него требуется перейти командой cd name . Это справедливо и при клонировании удалённого репозитория с помощью команды git clone . Полностью склонированный репозиторий создаст каталог в текущей директории с именем проекта, в который нужно перейти командой cd repo_name .

Перемещение файлов и каталогов

mv — сокращение от “Move”.

Перемещение (переименование) файлов и каталогов:

$ mv tmp temp

Удаление файлов и каталогов

rm — сокращение от “Remove”.

Алиасы в bash для быстрого набора команд Git

Командный интерпретатор bash позволяет задавать произвольные алиасы для разных команд и выражений. Алиасы не являются командами сами по себе, но им, как и командам, можно передавать аргументы. Алиасы позволяют сделать вызов громоздких команд очень простым, с легко запоминающимися названиями.

Использовать Git я привык исключительно из консоли, но на ввод длинных команд с разными аргументами тратится значительное количество времени. Поэтому я ввёл практику использования алиасов. Для безопасных команд я использовал короткие алиасы, которые по сути стали горячими клавишами, а для функциональных — простые короткие слова из состава команд Git. Если команда опасная, то можно сделать её в два слова, написанных через дефис, для исключения случайного ввода. На самом деле, использование алиасов для работы с Git широко практикуется, я решил лишь преподнести отдельный вариант подборки алиасов, которые для меня оказались очень удобными.

Формат задания алиаса имеет следующий вид:

alias name

Основной проблемой алиасов является то, что они не подхватываются автоматически механизмом автодополнения кода. Их написание отличается от тех команд, которые зарегистрированы в системе автодополнения, поэтому приходится дополнительно регистрировать алиасы, назначая им соответствующие спецификации автодополнения (compspec) через встроенную в bash команду complete . В случае с Git над complete существует обёртка __git_complete , в которую необходимо передавать предопределённые функции-обёртки, начинающиеся с префикса _git_ и оканчивающиеся названием подкоманды git. В Ubuntu весь связанный с этим код можно посмотреть в файле /usr/share/bash-completion/completions/git .

Алиас

Действие

Получить изменения с сервера

Просмотреть текущее состояние локального репозитория

Просмотреть текущее состояние локального репозитория и количество изменённых строк

Просмотреть изменения, сделанные в файлах и ожидающие подтверждения, в стандартном diff-формате

Просмотреть изменения, сделанные в файлах и ожидающие подтверждения, с выделением одним только цветом

Список последних коммитов в кратком формате.

Список последних коммитов с развёрнутой информацией о них.

Переход на другую ветку или коммит, создание новой ветки с опцией -b .

Получить изменения с сервера и влить их в текущую ветку.

Сделать коммит (зафиксировать изменения).

Добавить файлы или изменения в будущий коммит.

Отменить добавление изменений в будущий коммит.

Отправить новые коммиты на сервер.

Отправить коммиты на сервер с перезаписью их истории, если другие люди не успели отправить туда свои коммиты.

Влить заданную ветку в текущую.

Добавить изменения в уже сделанный коммит или изменить его комментарий.

Выполнить перезапись истории коммитов, например, переместив коммиты в конец другой ветки.

Переименовывание или удаление локальной ветки

Применить в текущей ветке отдельные существующие коммиты.

Сохранить свои текущие изменения во временное хранилище.

Применить свои текущие изменения из временного хранилища, но не удалять и оттуда.

Забрать свои изменения из временного хранилища и применить их.

Ниже приведено примерное содержимое файла ~/.bash_aliases с основными алиасами Git и кодом их автоматической регистрации в механизме автодополнения командой строки.

#!/bin/bash alias f="git fetch --tags" alias s="git status" alias ss="git status && git diff --shortstat" alias d="git diff" alias dd="git diff --word-diff=color" alias l="git log -n 20 --graph --pretty=format:'%Cred%h%Creset %an: %s / %Cgreen%cr%Creset %Creset %C(yellow)%d%Creset' --abbrev-commit --date=relative" alias ll="git log" alias go="git checkout" #или alias gg="git checkout" alias pull="git pull" alias commit="git commit" alias add="git add" alias reset="git reset" alias push="git push" alias push-fix="git push --force-with-lease" alias merge="git merge" alias amend="git commit --amend" alias rebase="git rebase" alias branch="git branch" alias pick="git cherry-pick" alias stash="git stash" alias apply="git stash apply" alias pop="git stash pop" # Регистрируем алиасы в системе автодополнения git_completions="/usr/share/bash-completion/completions/git" if [ -f "$" ]; then source "$" # Получаем массивы алиасов и соответствующих им команд git cmds=( $(alias | grep -v ss | grep -Po '(?; i++ )); do a="$" cmd="$" __git_complete "$" _git_"$" done fi

Для того, чтобы файл с алиасами применялся при входе в систему, необходимо добавить его подключение в файл ~/.bashrc с помощью команды source (или . ). Файл ~/.bashrc запускается на исполнение всегда при старте командного интерпретатора bash, поэтому если файл редактировался из консоли, потребуется её заново открыть или запустить вложенный командный интерпретатор bash.

if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi

Алиасы s , d и l простые, дают необходимый минимум информации. Задумка двухбуквенных в том, чтобы дать слегка больше информации, если это требуется. С помощью f можно получить последние изменения в репозитории и влить их в текущую ветку с помощью pull или pull -r . Через l можно посмотреть, что за новые коммиты прилетели в ветку, или что было последним из изменений, а через ll — подробно изучить коммиты. Переключиться на другую ветку можно через go , создать новую ветку можно через go -b . При создании коммита, в общем случае, сначала вводится s , проверяется на какой мы ветке, какие файлы требуется добавить, затем d , чтобы проверить свои изменения. Через add добавляются файлы (или add -i для выбора отдельных изменений в файлах), через commit -m создаётся новый коммит. Если вдруг в тексте сообщения коммита оказалась опечатка, можно быстро всё поправить через amend . Если в main-ветку успели прилететь новые коммиты, можно сделать rebase main . И потом сделать push . Если ветка своя собственная, то можно делать rebase -i с исправлениям прошлых коммитов и отправить модифицированные коммиты через push-fix .

Если шла работа, но срочно понадобилось переключиться на другую ветку, можно временно убрать свои изменения через stash , переключиться на другую ветку через go . Потом можно вернуть изменения с помощью apply или pop . Отдельные коммиты из других веток можно применять с помощью pick , также это может быть полезным, если случайно сделать изменения в отделённом HEAD (например, в подмодуле).

Алиасы могут совпадать с существующими командами. Если такие команды обычно не используются, то это проблемой не является. Если же команды понадобятся, то в случае исполняемых файлов всегда можно указать полный путь к файлу. Не будет проблем и с командами, которые запускаются от имени суперпользователя, поскольку алиасы прописаны лишь для непривилегированного пользователя. Если используется язык Go, то с использованием алиаса go могут возникнуть проблемы. В качестве решения можно изменить алиас на gg или gc , либо же сделать алиас golang для команды go . Здесь кому как удобнее.

В Ubuntu 21.10 при использовании алиаса над git checkout выводятся сообщения об ошибках. Происходит это из-за того, что одна из переменных в целочисленных сравнениях оказывается пустой. Вариантом подавления вывода ошибок является замена в файле /usr/share/bash-completion/completions/git сравнения через квадратные скобки на арифметическое сравнение через двойные скобки, например, (( var1 < var2 )) , в которых можно использовать названия переменных без предшествующего знака $ . Такое исправление работает и в zsh, на который автодополнение тоже рассчитано.

Патч, решающий проблему

--- /usr/share/bash-completion/completions/git 2021-08-09 15:29:27.000000000 +0300 +++ ./git 2022-04-08 23:32:38.501198226 +0300 @@ -1011,7 +1011,7 @@ if [ "$cmd" = "remote" ]; then ((c++)) fi - while [ $c -lt $cword ]; do + while (( c < cword )); do i="$" case "$i" in --mirror) [ "$cmd" = "push" ] && no_complete_refspec=1 ;; @@ -1187,7 +1187,7 @@ done local wordlist="$1" - while [ $c -lt $cword ]; do + while (( c < cword )); do for word in $wordlist; do if [ "$word" = "$" ]; then if [ -n "$" ]; then @@ -1221,7 +1221,7 @@ done local wordlist="$1" - while [ $c -gt "$__git_cmd_idx" ]; do + while (( c > __git_cmd_idx )); do ((c--)) for word in $wordlist; do if [ "$word" = "$" ]; then @@ -1283,7 +1283,7 @@ __git_has_doubledash () < local c=1 - while [ $c -lt $cword ]; do + while (( c < cword )); do if [ "--" = "$" ]; then return 0 fi @@ -1449,7 +1449,7 @@ < local i c="$__git_cmd_idx" only_local_ref="n" has_r="n" - while [ $c -lt $cword ]; do + while (( c < cword )); do i="$" case "$i" in -d|-D|--delete|-m|-M|--move|-c|-C|--copy) @@ -2479,7 +2479,7 @@ __git_config_get_set_variables () < local prevword word config_file= c=$cword - while [ $c -gt "$__git_cmd_idx" ]; do + while (( c >__git_cmd_idx )); do word="$" case "$word" in --system|--global|--local|--file=*) @@ -3213,7 +3213,7 @@ _git_tag () < local i c="$__git_cmd_idx" f=0 - while [ $c -lt $cword ]; do + while (( c < cword )); do i="$" case "$i" in -d|--delete|-v|--verify) @@ -3388,7 +3388,7 @@ local __git_C_args C_args_count=0 local __git_cmd_idx - while [ $c -lt $cword ]; do + while (( c < cword )); do i="$" case "$i" in --git-dir=*)

На практике я использую несколько меньший набор алиасов, в списке же привёл все, какие могут пригодиться в повседневной работе. Надеюсь, этот список кому-то окажется полезным, удачного использования!

Учимся работать с GIT проще некуда

В моей молодости 90-х годов для совместной разработки кода приходилось хранить файлы на каком-то сетевом диске и договариваться с коллегами, кто и что изменяет, чтобы не мешать друг другу.

Потом появились системы, которые контролировали доступ к файлам. Они просто делали все файлы по умолчанию только для чтения, и чтобы внести изменения программисты должны были помечать целый файл как занятый под себя и изменять его. Во время установки этой пометки файл реально копировался локально программисту и помечался в системе как занятый. Программист мог менять файл и потом забрасывать его обратно на сервер. Этот подход работал неплохо для пары человек, но для большого проекта с большим количеством программистов он превращался в кошмар. У меня на сайте в разделе статей до сих пор есть уроки по работе с VSS от 2009-го года, я храню их на память.

И вот Линус Торвальдс создает систему управления кодом git. Где-то я слышал, что Линус не очень хорошо умеет общаться с людьми и git был создан как раз для того, чтобы сократить коммуникации с людьми до минимума. Не знаю, правда это или нет, но результат все же впечатляющий.

Cамое главное отличие git состоит в том, что для внесения изменения в код не нужно блокировать файл. Вы делаете изменения, и система просто запоминает именно изменения. Потом, когда код сливается с другим кодом, изменения накладываются на основной код.

Установка

Итак, давайте знакомиться с git. Я все примеры буду выполнять в терминале на macOS, в Windows все работает абсолютно также. Заходим на сайт https://git-scm.com/downloads и здесь есть возможность скачать GIT для Windows, Linux или macOS.

Установка в Windows банальна – для этой ОС существует удобный и красивый мастер установки, в котором можно выбирать все по умолчанию, главное убедитесь, что установлена интеграция с PowerShell. После установки у вас появится выбор – работать в командной строке git bash или PowerShell. Если вы работаете в Windows, то я подозреваю, что второй будет для вас более привычным.

После завершения установки в проводнике можно будет кликнуть правой кнопкой мыши на любой папке и там должен быть пункт меню Git Bash Here, который запустит Bash терминал для работы с git:

В Windows я чаще работаю с PowerShell. Просто запустите его, создайте где-нибудь пустую папку для тестов и в ней выполняйте команды, которые мы будем рассматривать дальше. Обязательно практикуйтесь.

В Linux и macOS установка выполняется из командной строки. В Linux у меня ни разу проблем не было, а вот в macOS была, поэтому рассмотрим установку на маке.

Если у вас еще не установлен Brew, то рекомендую сделать это. Инструкции можно найти здесь https://brew.sh/. Если вы не уверены, установлен он или нет, то запустите терминал и выполните команду:

brew –version

Если нет ошибок и вы увидели версию, то brew установлен.

Теперь выполняем команды

brew update brew install git

Здесь может произойти ошибка, если нет прав на запись в папку /usr/local/sbin. Запускать их под админа смысла особо нет, вместо этого прямо в ошибке вам должны предложить выполнить следующую команду, чтобы дать своему пользователю права на папку /usr/local/sbin.

chown -R $(whoami) /usr/local/sbin

Если ошибки не было при установке git, то у вас права наверно уже были исправлены и не нужно выполнять chown.

И напоследок установим git-gui – графические утилиты для работы с git. Он не обязателен, если вы будете работать из командной строки, но я его все же ставлю, когда нужно посмотреть на историю изменений. В Windows gui утилиты ставятся автоматически, а в macOS нужно отдельно выполнить команду:

brew install git-gui

На мой взгляд стандартные графически утилиты git ужасные с точки зрения дизайна и интерфейса, но для меня это не проблема, потому что я ими реально пользуюсь очень редко. Я буду показывать, как работать с git из командной строки, потому что я считаю это очень важным навыком. Когда вы научитесь, то можно в дополнение установить утилиты с графическим интерфейсом, с более приятным внешним видом, чем стандартные. Такие утилиты можно найти здесь https://git-scm.com/downloads/guis.

Первое, что можно сделать после установки, это указать свое имя и e-mail. Это необходимо, чтобы git мог использовать эту информацию при создании коммита. Выполните две следующие команды:

git config --global user.name mflenov git config --global user.email mikhail@flenov

только замените mflenov на свое имя и mikhail@flenov свой email. Кстати, этот email не существует, так что не пишите мне на него, я не смогу ответить. Даже если вы добавите .info или .ru, такого email все равно не будет.

Последовательность выполнения команд не важна. После выполнения первой из них, git создаст файл.gitconfig в вашей домашней директории и сохранит в нем введенную вами информацию.

Если вы работаете в macOS или Linux, то попробуйте сейчас выполнить команду:

cat $HOME/.gitconfig

В результате вы должны увидеть:

[user] email = mikhail@flenov.ru name = mflenov

Как видите email и имя просто сохранены в этом файле и вы можете менять эту информацию вручную в файле или с помощью команд выше. Конечно же использование команд более предпочтительно.

Инициализация

Итак, у нас необходимые программы установлены. Создайте новую папку, на которой мы будем тестировать команды. В этой папке для начала нужно создать репозиторий:

git init

В результате вы должны увидеть что-то типа:

Initialized empty Git repository in /Users/mikhailflenov/Projects/youtube-demo/.git/

Здесь говориться, что создан новый репозиторий GIT и нам показана папка .git. Имена папок, которые начинаются с точки по умолчанию не видны в Linux и macOS и это хорошо. В этой папке git хранит свои внутренние вещи, в которые вас очень редко нужно будет заглядывать.

Командой git init вы создали репозиторий и ствол дерева вашего проекта, который будет называться master, а по последним рекомендациям его стали называть main. Я буду продолжать использовать старое название master.

Инициализация выполняется в принципе один раз на проект, когда вы создаете что-то новое. После этого забываем про git init.

Первая команда, которую вы скорей всего будете выполнять чаще всего git status. Выполните эту команду

git status

и в результате вы должны увидеть на экране:

On branch master No commits yet nothing to commit (create/copy files and use "git add" to track)

Первая строка говорит нам о том, что мы сейчас находимся на ветке по имени master. Как я уже сказал, в будущем главную ветку скорей всего переименуют в main, уже в эту сторону идет работа.

Это главная ветка. Вторая строка говорит, что у нас еще нет никаких коммитов. Последняя строка указывает на то, что нам даже нечего добавить. Нужно создать файлы в этой папке или скопировать их откуда-нибудь.

Теперь мы подготовили почву, и чтобы можно было растить дерево нужно посадить росток – сделать первый коммит в репозиторий. Создайте какой-нибудь файл папке, где вы проинициализировали репозиторий. В macOS в терминале для этого можно выполнить простую команду

echo hallo >> readme.txt

Теперь нужно добавить этот файл к git, чтобы он знал о нем, для этого выполняем команду

git add readme.txt

git отслеживает изменения файлов, которые вы добавляете в него и позволяет сохранить (закомитить) изменения и каждый коммит сохраняется в истории git.

Первый файл добавлен, теперь нужно сделать первое сохранение:

git commit -m 'initial commit'

Здесь мы с помощью команды git commit говорим, что нужно закоммитить, или зафиксировать добавленные файлы. Ключ -m позволяет добавить сообщение/комментарий (-m). Initial commit это и есть мой комментарий к первому коммиту.

Обратите внимание на результат команды:

[master (root-commit) 3167f60] initial commit 1 file changed, 1 insertion(+) create mode 100644 readme.txt

В первой строке нам говорят, что мы создали корневой коммит (root-commit) под номером 3167f60. Номера уникальны и генерируются с помощью алгоритма sha. Таким образом git создает точки сохранения. На диаграмме веток, которую я недавно показывал, это точки #1, #2 и #3.

Во второй строке дается статистика коммита и нам говорят, что изменен один файл и в нем изменена только одна строка.

Выполните сейчас команду gitk, чтобы посмотреть на визуальное представление

Слева наверху будет дерево, пока мы видим только корневой коммит. Сверху в центре – имя пользователя, который сделал изменения. Сверху справа – время изменения.

Обратите внимание на строку, которую я подчеркнул в середине красным цветом. Это Sha1 код, который был назначен коммиту. Мы уже видели его раньше, но только первые 7 символов 3167f60. Здесь же мы можем увидеть полный код. Очень редко бывает необходимость знать полный код, обычно достаточно короткого кода, который вы видели при создании коммита.

Работа с ветками кода

Никогда не разрабатывайте новый код прямо стволе, это очень и очень плохая практика. Только самый первый коммит может быть сделан прямо в мастере, чтобы создать дерево.

У меня master установлен на сервере staging от которого мы запускаем код на рабочие сервера. Клиент на этом сервере может делать изменения в параметрах, которые хранятся в конфигурационных файлах, и программисты могут пофиксить на этом сервере мега срочные баги, но только в очень редких случаях.

На компьютерах программистов никто и никогда не открывает master с целью разработки. Я думаю, что это даже запрещено политикой компании, хотя письменного подтверждения этому нет. Все просто понимают, что разрабатывать новый код или даже фиксить баги в стволе не очень хорошая идея.

Прежде чем что-то делать, нужно создать новую ветку, куда мы будем добавлять наш код. Что такое ветка кода? Реально представьте себе дерево. У вас есть ствол, и на верхушке ствола мы создаем ответвление, в котором работаем, пишем свой код, а когда работа закончена, то объединяем содержимое ветки со стволом.

Синяя ветка – это основное дерево. Когда мы создали красную ветку, то в ней фиксируется состояние кода на момент создания ветки, то есть то, что было в левой точке пересечения синей и красной линии. Теперь мы в своей ветке можем работать над кодом и сохранять его. На рисунке я # с цифрой я показал возможные точки сохранения и их оказалось три. Когда работа закончена, мы сливаем ветку с основным деревом в точке пересечения со стрелкой справа. В этот момент изменения кода #1, #2 и #3 попадают в основную ветку и становятся доступными в master.

Даже если в голове до сих пор не сформировалась окончательная картина, надеюсь в процессе этого вы все же увидите, как работает ветвление.

Итак, первое, с чего мы должны начать – создание ветки. Для этого выполняем команду:

git checkout -b имяветки база

git checkout говорит, что мы должны переключиться на репозиторий. Ключик -b говорит, что нужно не просто переключиться, а создать новую ветку с именем имяветки. Именование веток у каждого свое. Когда я работал в консалтинге над разными проектами, то именование состояло из двух частей:

имясайта/номертикета

или если я работал над чем-то большим, то имя имело формат:

имясайте/имяпроекта

Например, когда мне нужно было исправить баг под номером 415412 для сайта wheeloffortune, то я создавал ветку с именем:

wof/415412

По левой части сразу видно, что этот фикс нужно искать в репозитории для сайта wheeloffortune и описание фикса можно найти в тикете 415412.

Если нужно было работать над новым функционалом и это целый проект по редизайну на пару месяцев для сайта sonyrewards, то я мог назвать ветку:

sr/redesign2015

Сейчас у нас в компании ветки называют по имени команды + номер тикета:

teamname/415412

Можете взять на вооружение один из этих подходов, а можете использовать простые имена без деления, главное, чтобы это было вам удобно.

После имени бренча через пробел идет база - по документации необязательный параметр - от какой ветки вы хотите создать свою. Я рекомендую всегда указывать этот параметр. Если вы не укажите базу, то в качестве нее будет выступать текущая ветка. Чаще всего ветки нужно создавать от основной master, а не от текущей. Если только вы явно не хотите создать свою ветку от какой-то другой, команда создания будет

git checkout -b имяветки origin/master

Стоп, еще немного о именовании. В данном случае я указываю origin/master и это удаленный ствол. На это указывает слово origin. Если мы создаем новую ветку fixdone/345321, то это локальная копия на нашем диске. Удаленная копия на сервере git в репозитории будет иметь имя origin/fixdone/345321. Когда мы создаем новые ветки, то желательно создавать от удаленной версии master, но у нас ее пока нет, поэтому если попытаться выполнить такую команду, то она завершиться ошибкой.

Да, я рекомендую всегда использовать в качестве базы удаленную версию origin/master, которая указывает на версию на сервере, но если ее нет, то придется использовать локальную – просто master. Мы пока создали только локальный репозиторий. Пока нет удаленного, придется использовать локальный. Как только появиться удаленный, всегда используйте его. О удаленных ветках мы поговорим в следующий раз.

Итак, пока нет удаленного мастера, давайте создадим новую ветку от локального:

git checkout -b initialwork master

Я назвал ветку initialwork. В результате выполнения команды вы должны увидеть что-то типа:

Switched to a new branch 'initialwork'

Теперь мы находимся в ветке, где мы можем исправлять баг или работать над новым функционалом. Давайте создадим файл index.html. Вы можете воспользоваться для этого любым текстовым редактором.

Я создал index.html с таким содержимым:

Welcome

Home page

Welcome to my website

Если вы повторяете за мной, что я настоятельно рекомендую, то будет очень даже неплохо, если вы создадите файл с таким же именем и с таким же содержимым.

Выполняем команду git status, чтобы посмотреть текущее состояние:

On branch initialwork Untracked files: (use "git add . " to include in what will be committed) index.html nothing added to commit but untracked files present (use "git add" to track)

В первой строке нам напоминают, что мы находимся на ветке initialwork. Потом сообщают, что у нас в папке есть файл index.html, который не добавлен в git и изменения в файле не отслеживаются. Тут же есть подсказка, что для добавления файла в git нужно выполнить комануд git add . Мы уже это делали разок, давайте добавим index.html:

git add index.html

Снова выполняем git status, чтобы посмотреть, что изменилось:

On branch initialwork Changes to be committed: (use "git restore --staged . " to unstage) new file: index.html

Мы все еще находимся на той же ветке и мы добавили файл, который будет сохранен в git, но он еще не закомичен. Чтобы окончательно закомитить изменения, нужно выполнить команду git commit. Если вы передумали, и не хотите коммитить изменения в файле index.html, то отменить можно командой:

git restore --staged index.html

На то, как можно отменить добавление указывает подсказка при выполнении git status:

(use "git restore --staged . " to unstage)

Эта команда уже менялась, да если честно я ее я никогда не пытался запомнить ее, потому что подсказку можно всегда увидеть в git status.

Когда вы выполняете команду git add, вы подготавливаете свой коммит, по другому эту операцию на английском называют stage. Когда вы убираете файл, эта операция называется unstage. В некоторых программах вместо add и restore вы можете увидеть именно эти слова stage и unstage.

Но давайте не будем отменять, а закомитим файл. Если вы уже выполнили restore, то снова добавьте файл и давайте закомитим командой:

git commit -m 'add index.html file'

На этот раз я коммичу файл с сообщением 'add index.html file'. В консоли вы должны увидеть что-то типа:

[initialwork 2255b8f] add index.html file 1 file changed, 9 insertions(+) create mode 100644 index.html

Выполните команду gitk, чтобы посмотреть, какие произошли изменения. Слева вверху теперь уже две коммита. Пока они не выглядят как дерево, потому что мы просто создали последовательно две точки. Но напротив каждой из точек виден комментарий, который мы добавили при коммите, поэтому по этому комментарию можн легко найти нужно изменение в дереве:

Попробуйте сейчас изменить файл index.html и выполните команду git status. Результат должен быть примерно следующим:

Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: index.html

Обратите внимание, что в последней строки перед именем файла index.html появилась надпись modified. Чтобы сохранить изменения нужно снова добавить файл в коммит и закоммитить. Для добавления в коммит можно использовать команду git add. Если изменено много файлов, то их можно добавлять по маске

git add i*

Так мы добавим все файлы, имена которых начинаются с i.

Если вы хотите добавить в коммит все измененные файлы, то можно использовать ключ -u, что означает updated:

git add -u

Эта команда добавит только те файлы, котоыре изменены и за которыми уже наблюдает git. Новые файлы не будут добавлены, их можно потом добавить отдельно выполнив add.

Сливаем ветки

В файловом менеджере или в терминале с помощью команды ls посмотрите на файлы, которые у нас есть. Их должно быть два readme.txt и index.html.

Попробуем переключиться на другую ветку. Создайте новую ветку от мастера с именем secondone:

git checkout -b secondone master

Мы создали новую ветку от мастера. Давайте посмотрим на файловую систему. Обратите внимание, что файл index.html исчез. Когда мы создали новую ветку и переключились на нее, то мы видим только то, что в данный момент находиться в мастере. Index.html файла там нет, он живет в отдельной ветке initialwork.

Если нам нужны изменения, которые были сделаны в файле initialwork, то мы можем слить их. Для этого можно выполнить команду git merge и указать имя ветки, которую нужно слить:

git merge initialwork

В результате вы должны увидеть примерно следующее:

Updating 3167f60..2255b8f Fast-forward index.html | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 index.html

Теперь в файловой системе можно увидеть файл index.html.

Наши изменения начали ветвиться, как показано на следующем рисунке. Теперь понятно, почему

Но изменения все еще не в мастере. Мы можем переключиться на мастер:

git checkout master

и посмотреть на файловую систему. У нас тут все еще только readme.txt.

Обратите внимание, что при переключении на мастер я выполнял команду git checkout без ключа -b, потому что ветка master уже существует и нам не нужно ничего создавать, поэтому просто git checkout – переключиться без создания.

Теперь мы можем слить с мастером любую ветку initialwork или secondone. В обоих ветках уже есть файл index.html и в любом случае он появиться в мастере. Так что можно выполнить команду:

git merge initialwork

git merge secondone

А можете выполнить обе команды и посмотреть на результат. В первом случае произойдет слияние. Во втором случае нам сообщат, что все уже обновлено и слияния не будет:

git merge initialwork Updating 3167f60..2255b8f Fast-forward index.html | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 index.html git merge secondone Already up to date.

Огромный плюс в том, что для изменения файлов мы никогда и ничего не блокировали, никому не сообщали, что сейчас мы начнем работать над файлом и пожалуйста не трогайте их. Мы просто меняем файлы, сохраняем изменение и потом сливаем нужные ветки вместе. В git сохраняются только изменения, а не весь измененный файл. Это значит, что при слиянии двух веток, в которых изменен один и тот же файл, но в разных местах файла проблем не будет. Только если два программиста изменили одну и ту же строку в файле возникнут проблемы, но об этом стоит поговорить в следующий раз.

11 Ноября 2020 | Программирование

Поделитесь с друзьями

Внимание. Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание

30 команд Git, необходимых для освоения интерфейса командной строки Git

Git — самая популярная в мире распределённая система контроля версий. Линус Торвальдс, разработчик ядра ОС Linux, создал этот инструмент ещё в 2005 году, а сегодня Git активно поддерживается как проект с открытым исходным кодом. Огромное количество открытых и коммерческих проектов используют Git для контроля версий.

В данной статье перечисляются самые основные команды, которые следует знать разработчику, чтобы освоить управление репозиториями GitHub на высоком уровне. Ознакомиться с ними будет полезно как новичкам, так и опытным разработчикам.

30 основных команд, которые сделают из вас мастера Git

Как задать имя пользователя и адрес электронной почты
Кэширование учётных данных
Инициализация репозитория
Добавление отдельных файлов или всех файлов в область подготовленных файлов
Проверка статуса репозитория
Внесение изменений однострочным сообщением или через редактор
Просмотр истории коммитов с изменениями
Просмотр заданного коммита
Просмотр изменений до коммита
Удаление отслеживаемых файлов из текущего рабочего дерева
Переименование файлов
Отмена подготовленных и неподготовленных изменений
Изменение последнего коммита
Откат последнего коммита
Откат заданного коммита
Создание новой ветки и переход в неё
Просмотр списка веток
Удаление ветки
Слияние двух веток
Отображение журнала фиксации в виде графика для текущей или всех веток
Прекращение слияния при конфликте
Добавление удалённого репозитория
Просмотр удалённых URL-адресов
Получение дополнительных сведений об удалённом репозитории
Отправка изменений в удалённый репозиторий
Получение изменений из удалённого репозитория
Слияние удалённого репозитория с локальным
Отправка новой ветки в удалённый репозиторий
Удаление удалённой ветки
Использование перебазирования

1. Как задать имя пользователя и адрес электронной почты

Имя пользователя нужно, чтобы привязывать коммиты к вашему имени. Это не то же самое, что имя пользователя учётной записи GitHub, с помощью которого выполняется вход в профиль на GitHub. Задать или изменить имя пользователя можно с помощью команды git config . Новое имя будет автоматически отображаться в последующих коммитах, отправленных на GitHub через командную строку. Если хотите скрыть своё реальное имя, можно использовать в качестве имени пользователя Git произвольный набор символов.

git config --global user.name "Tara Routray"

Кроме того, командой git config можно изменять адрес электронной почты, привязанный к вашим коммитам Git. Новый адрес электронной почты будет автоматически отображаться во всех дальнейших коммитах, поданных на GitHub через командную строку.

git config --global user.email "dev@tararoutray.com"

2. Кэширование учётных данных

Кэшировать учётные данные можно с помощью параметра config с флагом --global . Так вы избавитесь от необходимости вручную вводить имя пользователя и пароль при создании нового коммита.

git config --global credential.helper cache

3. Инициализация репозитория

Создать пустой репозиторий Git или вновь инициализировать существующий можно параметром init . При инициализации он создаст скрытую папку. В ней содержатся все объекты и ссылки, которые Git использует и создаёт в истории работы над проектом.

git init

4. Добавление отдельных файлов или всех файлов в область подготовленных файлов

Добавить отдельный файл в область подготовленных файлов можно параметром add с указанием имени файла. Просто замените somefile.js на актуальное имя.

git add somefile.js

Кроме того, можно добавить все файлы и папки в эту область, предоставив wildcard . вместо имени файла:

git add .

5. Проверка статуса репозитория

Просмотреть статус нужного репозитория можно по ключевому слову status : его действие распространяется на подготовленные, неподготовленные и неотслеживаемые файлы.

git status

6. Внесение изменений однострочным сообщением или через редактор

При создании коммита в репозитории можно добавить однострочное сообщение с помощью параметра commit с флагом -m . Само сообщение вводится непосредственно после флага, в кавычках.

git commit -m "Your short summary about the commit"

Также можно открыть текстовый редактор в терминале для написания полного сообщения коммита. Оно может состоять из нескольких строк текста, в котором подробно характеризуются изменения, внесённые в репозиторий.

git commit

7. Просмотр истории коммитов с изменениями

Просматривать изменения, внесённые в репозиторий, можно с помощью параметра log . Он отображает список последних коммитов в порядке выполнения. Кроме того, добавив флаг -p , вы можете подробно изучить изменения, внесённые в каждый файл.

git log -p

8. Просмотр заданного коммита

Просмотреть полный список изменений, внесённых конкретным коммитом, можно с помощью параметра show , указав идентификатор или хеш коммита. Значение хеша уникально для каждого коммита, созданного в вашем репозитории.

git show 1af17e73721dbe0c40011b82ed4bb1a7dbe3ce29

Также можно использовать сокращённый хеш.

git show 1af17e

9. Просмотр изменений до коммита

Можно просматривать список изменений, внесённых в репозиторий, используя параметр diff . По умолчанию отображаются только изменения, не подготовленные для фиксации.

git diff

Для просмотра подготовленных изменений необходимо добавить флаг --staged .

git diff --staged

Также можно указать имя файла как параметр и просмотреть изменения, внесённые только в этот файл.

git diff somefile.js

10. Удаление отслеживаемых файлов из текущего рабочего дерева

Удалять файлы из текущего рабочего дерева можно с помощью параметра rm . При этом файлы удаляются и из индекса.

git rm dirname/somefile.js

Можно также использовать маски файлов (например *.js) для удаления всех файлов, соответствующих критерию.

git rm dirname/*.html

11. Переименование файлов

Переименовать файл или папку можно параметром mv . Для него указывается источник source и назначение destination . Источник — реально существующий файл или папка, а назначение — существующая папка.

git mv dir1/somefile.js dir2

При выполнении команды файл или папка, указанные как источник, будут перемещены в папку назначения. Индекс будет обновлён соответственно, но изменения нужно записать.

12. Отмена подготовленных и неподготовленных изменений

Восстановить файлы рабочего дерева, не подготовленные к коммиту, можно параметром checkout . Для проведения операции требуется указать путь к файлу. Если путь не указан, параметр git checkout изменит указатель HEAD, чтобы задать указанную ветку как текущую.

git checkout somefile.js

Восстановить подготовленный файл рабочего дерева можно параметром reset . Потребуется указать путь к файлу, чтобы убрать его из области подготовленных файлов. При этом не будет производиться откат никаких изменений или модификаций — однако файл перейдёт в категорию не подготовленных к коммиту.

git reset HEAD somefile.js

Если нужно выполнить это действие для всех подготовленных файлов, путь к ним указывать не надо.

git reset HEAD

13. Изменение последнего коммита

Внести изменения в последний коммит можно параметром commit с флагом --amend . Например, вы записали изменения, внесённые в ряд файлов, и поняли, что допустили ошибку в сообщении коммита. В этом случае можете воспользоваться указанной командой, чтобы отредактировать сообщение предыдущего коммита, не изменяя его снимок.

git commit --amend -m "Updated message for the previous commit"

Также можно вносить изменения в файлы, отправленные ранее. Например, вы изменили несколько файлов в ряде папок и хотите их записать как единый снимок, но забыли добавить в коммит одну из папок. Чтобы исправить такую ошибку, достаточно подготовить для фиксации остальные файлы и папки и создать коммит с флагами --amend и --no-edit .

git add dir1 git commit # Here you forgot to add dir2 to commit, you can execute the following command to amend the other files and folders. git add dir2 git commit --amend --no-edit

Флаг --no-edit позволит внести в коммит поправку без изменения сообщения коммита. В этом случае итоговый коммит заменит неполный, а выглядеть это будет так, как будто мы отправили изменения ко всем файлам в нужных папках как единый снимок.

Внимание! Не изменяйте публичные коммиты.

С помощью amend прекрасно исправляются локальные коммиты, а исправления можно передать в общий репозиторий. Однако изменять коммиты, уже доступные другим пользователям, не следует. Помните, что изменённые коммиты являются совершенно новыми, а предыдущий коммит уже не будет доступен в текущей ветке. Последствия будут такими же, как при отмене изменений публичного снимка.

14. Откат последнего коммита

Откатить последний коммит можно с помощью параметра revert . Создастся новый коммит, содержащий обратные преобразования относительно предыдущего, и добавится к истории текущей ветки.

git revert HEAD

▍ Разница между revert и reset

Команда git revert отменяет изменения, записанные только одним коммитом. Она не откатывает проект к более раннему состоянию, удаляя все последующие коммиты, как это делает команда git reset .

У команды revert есть два крупных преимущества по сравнению с reset. Во-первых, она не меняет историю проекта и производит операцию, безопасную для коммитов. Во-вторых, её объектом выступает конкретный коммит, созданный в любой момент истории, а git reset всегда берёт за точку отсчёта текущий коммит. К примеру, если нужно отменить старый коммит с помощью git reset, придётся удалить все коммиты, поданные после целевого, а затем выполнить их повторно. Следовательно, команда git revert — гораздо более удобный и безопасный способ отмены изменений.

15. Откат заданного коммита

Откатить проект до заданного коммита можно с помощью параметра revert и идентификатора коммита. Создастся новый коммит — копия коммита с предоставленным идентификатором — и добавится к истории текущей ветки.

git revert 1af17e

16. Создание новой ветки и переход в неё

Создать новую ветку можно с помощью параметра branch , указав имя ветки.

git branch new_branch_name

Но Git не переключится на неё автоматически. Для автоматического перехода нужно добавить флаг -b и параметр checkout .

git checkout -b new_branch_name

17. Просмотр списка веток

Можно просматривать полный список веток, используя параметр branch . Команда отобразит все ветки, отметит текущую звёздочкой (*) и выделит её цветом.

git branch

Также можно вывести список удалённых веток с помощью флага -a .

git branch -a

18. Удаление ветки

Удалить ветку можно параметром branch с добавлением флага -d и указанием имени ветки. Если вы завершили работу над веткой и объединили её с основной, можно её удалить без потери истории. Однако, если выполнить команду удаления до слияния — в результате появится сообщение об ошибке. Этот защитный механизм предотвращает потерю доступа к файлам.

git branch -d existing_branch_name

Для принудительного удаления ветки используется флаг -D с заглавной буквой. В этом случае ветка будет удалена независимо от текущего статуса, без предупреждений.

git branch -D existing_branch_name

Вышеуказанные команды удаляют только локальную копию ветки. В удалённом репозитории она может сохраниться. Если хотите стереть удалённую ветку, выполните следующую команду:

git push origin --delete existing_branch_name

19. Слияние двух веток

Объединить две ветки можно параметром merge с указанием имени ветки. Команда объединит указанную ветку с основной.

git merge existing_branch_name

Если надо выполнить коммит слияния, выполните команду git merge с флагом --no-ff .

git merge --no-ff existing_branch_name

Указанная команда объединит заданную ветку с основной и произведёт коммит слияния. Это необходимо для фиксации всех слияний в вашем репозитории.

20. Отображение журнала фиксации в виде графика для текущей или всех веток

Просмотреть историю коммитов в виде графика для текущей ветки можно с помощью параметра log и флагов --graph --oneline --decorate . Опция --graph выведет график в формате ASCII, отражающий структуру ветвления истории коммитов. В связке с флагами --oneline и --decorate , этот флаг упрощает понимание того, к какой ветке относится каждый коммит.

git log --graph --oneline --decorate

Для просмотра истории коммитов по всем веткам используется флаг --all .

git log --all --graph --oneline --decorate

21. Прекращение слияния при конфликте

Прервать слияние в случае конфликта можно параметром merge с флагом --abort . Он позволяет остановить процесс слияния и вернуть состояние, с которого этот процесс был начат.

git merge --abort

Также при конфликте слияния можно использовать параметр reset , чтобы восстановить конфликтующие файлы до стабильного состояния.

git reset

22. Добавление удалённого репозитория

Добавить удалённый репозиторий можно параметром remote add , указав shortname и url требуемого репозитория.

git remote add awesomeapp https://github.com/someurl..

23. Просмотр удалённых URL-адресов

Просматривать удалённые URL-адреса можно параметром remote с флагом -v . Этот параметр отображает удалённые подключения к другим репозиториям.

git remote -v

Такая команда открывает доступ к интерфейсу управления удалёнными записями, которые хранятся в файле .git/config репозитория.

24. Получение дополнительных сведений об удалённом репозитории

Получить подробные сведения об удалённом репозитории можно с помощью параметра remote show с указанием имени репозитория — например, origin .

git remote show origin

Эта команда отображает список веток, связанных с удалённым репозиторием, а также рабочих станций, подключённых для получения и отправки файлов.

25. Отправка изменений в удалённый репозиторий

Отправлять изменения в удалённый репозиторий можно параметром push с указанием имени репозитория и ветки.

git push origin main

Эта команда передаёт локальные изменения в центральный репозиторий, где с ними могут ознакомиться другие участники проекта.

26. Получение изменений из удалённого репозитория

Для загрузки изменений из удалённого репозитория используется параметр pull . Он скачивает копию текущей ветки с указанного удалённого репозитория и объединяет её с локальной копией.

git pull

Также можно просмотреть подробные сведения о загруженных файлах с помощью флага --verbose .

git pull --verbose

27. Слияние удалённого репозитория с локальным

Слияние удалённого репозитория с локальным выполняется параметром merge с указанием имени удалённого репозитория.

git merge origin

28. Отправка новой ветки в удалённый репозиторий

Передать новую ветку в удалённый репозиторий можно параметром push с флагом -u , указав имя репозитория и имя ветки.

git push -u origin new_branch

29. Удаление удалённой ветки

Чтобы избавиться от удалённой ветки, используйте параметр push с флагом --delete , указав имя удалённого репозитория и имя ветки.

git push --delete origin existing_branch

30. Использование перебазирования

Для доступа к этой функции используйте параметр rebase с указанием имени ветки. Перебазирование — это процесс объединения или перемещения последовательности коммитов на новый родительский снимок.

git rebase branch_name

Эта команда изменит основу ветки с одного коммита на другой, как если бы вы начали ветку с другого коммита. В Git это достигается за счёт создания новых коммитов и применения их к указанному базовому коммиту. Необходимо понимать, что, хотя ветка и выглядит такой же, она состоит из совершенно новых коммитов.

▍ Спасибо за внимание!

Вы узнали 30 основных команд интерфейса командной строки Git. Теперь, при условии регулярной практики, у вас есть всё необходимое, чтобы достичь мастерства в управлении репозиториями GitHub.

Блог компании RUVDS.com
Системное администрирование
Git
GitHub