GIT - uniqcle/DevOps GitHub Wiki
git --version #Узнать последнюю версию
system # All users
global # All repos of the current user
local # The current repo
git config --global user.name "uniqcle" #Настройка пользователя и емейл.
git config --global user.email [email protected]
git config --global core.editor "code --wait" //VS Code by default
git config --global -e //open config file
git config --global core.autocrlf true //on Windows
git config --global core.autocrlf input //on Linux/Mac
git config –-list #Выдает список конфигурации
#Если что-то одно нужно показать
git config user.name
git config user.email
git config --system init.defaultBranch master # изменения названия ветки по умолчанию
git config –-unset-all –-global user.email #Удаление определенной настройки
git init #создать новый проект в текущей папке
git init folder-name #создать новый проект в указанной папке
git config --list --global --show-origin # путь до настроек --local --global --system
git status --short # -s о статусах файлов в укороченном формате
git config --global core.autocrlf true
text.txt save as .gitignore -> добавление папок
#не обрабатывать файлы
*.a #имя которых заканчивается на .a
*.[oa] #заканчивающиеся на .o или .a
*~ #игнорировать все файлы заканчивающиеся на тильду (~)
!lib.a #НО отслеживать файл lib.a, несмотря на то, что мы игнорируем все .a файлы с помощью предыдущего правила
/TODO #игнорировать только файл TODO находящийся в корневом каталоге, не относится к файлам вида subdir/TODO
build/ #игнорировать все файлы в каталоге build/
doc/*.txt #игнорировать doc/notes.txt, но не doc/server/arch.txt
doc/**/*.txt #игнорировать все .txt файлы в каталоге doc/
git clone git://github.com/schacon/grit.git #клонировать удаленный репозиторий в одноименную папку
git clone [email protected]:nicothin/web-design.git foldername # клонировать в папку «foldername»
git add . #Добавление/индексирование всех файлов
git add --all # или так git add :/, git add -A не важно в каком разделе находимся
git add название-директории/ # определенную категорию
git add licence.php #или одного
git add "*.txt" #Добавление в индекс перед коммитом
Пропускаем этап добавления файлов в индекс git commit -am "текст коммита"
Несмотря на довольно громкий заголовок, полностью пропустить этап добавления файлов в индекс не получится. Но нам не придётся прописывать команду git add.
Для таких задач используют команду git commit
с опцией -a
(развёрнуто --all
) — она сначала добавляет изменения в индекс, а потом фиксирует их. Этот трюк работает только с отслеживаемыми файлами. То есть для файлов, которые имеют статус untracked
, команда работать не будет. Вам всё равно придётся сначала прописать git add
, а уже потом только git commit -m "текст коммита"
.
git commit -a -m "fix: restores the behavior of the viewport meta tag in safari to version 9.0".
пример хорошего коммита.
Команду можно писать короче — git commit -am "текст коммита"
.
git stash #Копирование в буфер обмена для последующей работе. Используется, если необходимо переключиться на др. ветку.
git stash list #Показывает запись в буфере
git stash pop #Извлечение результатов
Удаление файла (просто удалить отслеживаемый файл из папки недостаточно, нужно сделать его неотслеживаемым и отправить коммит)
git ls-files # show files in the staging area
git rm text.txt # Удалить из отслеживаемых неиндексированный файл (файл будет удален из папки)
git rm -f text.txt # удалить из отслеживаемых индексированный файл (файл будет удален из папки)
git rm --cached readme.txt # Удалить из отслеживаемых индексированный файл (файл останется на месте)
git rm --cached -r bin/ # delete files from the staging area
git mv text.txt test_new.txt # переименовать файл «text.txt» в «test_new.txt»
git mv readme_new.md folder/ # переместить файл readme_new.md в папку folder/ (должна существовать)
git reset HEAD # убрать из индекса все индексированные файлы
git reset HEAD hello.txt # убираем файл из stage-области
discard # - отмена изменений (не закомиченных)
revert #- отмена измененного коммита
reset # - откат изменений всех (до выбранного)
Допустим, вы создали или изменили какой-то файл и добавили его в список «на коммит» (staging area)
с помощью git add
, но потом передумали включать его туда. Убрать файл из staging поможет команда git restore --staged <file>
(от англ. restore
— «восстановить»).
Иногда нужно «откатить» то, что уже было закоммичено, то есть вернуть состояние репозитория к более раннему. Для этого используют команду git reset --hard <commit hash>
(от англ. reset
— «сброс», «обнуление» и hard — «суровый»).
Может быть так, что вы случайно изменили файл, который не планировали. Теперь он отображается в Changes not staged for commit (modified).
Чтобы вернуть всё «как было», можно выполнить команду git restore <file>
.
Команда git restore --staged <file>
переведёт файл из staged
обратно в modified
или untracked
.
Команда git reset --hard <commit hash>
«откатит» историю до коммита с хешем . Более поздние коммиты потеряются!
Команда git restore <file>
«откатит» изменения в файле до последней сохранённой (в коммите или в staging) версии.
git checkout text.txt # Откат изменений определенного файла, если непроиндексированный файл.
git checkout -- text.txt # отменить все изменения, внесенные в отслеживаемый файл со времени предыдущего коммита (файл не добавлен в индекс, не откоммичен)
git checkout -- .
git commit -m "Name of commit" # закоммитить отслеживаемые индексированные файлы.
git commit -a -m "Name of commit" # закоммитить отслеживаемые индексированные файлы (указано название коммита, не требует git add, не добавит в коммит неотслеживаемые файлы). Коммит всех файлов.
git commit # закоммитить отслеживаемые индексированные файлы (откроется редактор для введения названия коммита)
git commit –-amend –m ‘Коммент’ # изменить последний коммит (Insert — режим ввода, : — командный режим; в командном режиме: :wq — сохранить и выйти)
git commit --amend -m "Новое название" # переименовать последний коммит (только если ещё не был отправлен в удалённый репозиторий)
Добавить изменения в уже созданный последний коммит git commit --amend
git commit
есть опция под названием --amend
. Она позволяет добавить изменения в уже созданный последний коммит. Важно помнить, что когда мы добавим новые изменения в последний коммит, то хэш этого коммита изменится. Поэтому такую манипуляцию нужно производить до того, как вы отправите коммит в удалённый репозиторий.
Также есть нюанс. Если мы пропишем опцию с git commit
, появится дополнительное окно редактора кода, в котором нам будет предложено отредактировать коммит. Но если вам не нужно ничего редактировать, то это окно можно просто закрыть. Перед этим не забудьте сохранить файл с помощью сочетания клавиш Ctrl + S
.
Важно: если вы работаете на операционной системе Mac, возможно, у вас откроется текстовый редактор VI. Не пугайтесь. Для начала определитесь, хотите ли вы изменить текст коммита или написать его.
Если да — нажмите клавишу i
, и тогда вы перейдёте из обычного режима в режим ввода. После исправления текста нажмите на клавишу Esc
, чтобы вернуться в обычный режим. Иногда может потребоваться два раза нажать на Esc
, но чаще хватает и одного. После этого нажмите на клавишу с символом двоеточия :
, чтобы перейти в командный режим. Далее введите wq
(означает «Записать файл и выйти») и нажмите Enter
.
Если же вам не нужно ничего делать с текстом, то выполните те же действия, начиная с клавиши двоеточия :
(пропустив нажатие на клавиши i
и Esc
).
Есть и более простые способы, которые позволяют избежать вызова данного окна с файлом COMMIT_EDITMSG
. Если вам нужно отредактировать последний коммит, воспользуйтесь командой git commit --amend -m "новый текст последнего коммита"
. Если вам не нужно редактировать текст последнего коммита, то просто пропишите git commit --amend --no-edit
.
git revert HEAD --no-edit # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения
git revert b9533bb --no-edit # создать новый коммит, отменяющий изменения указанного (b9533bb) коммита без запуска редактора сообщения (указаны первые 7 символов хеша коммита)
git reset --hard 75e2d51 # вернуть репозиторий в состояние коммита с указанным хешем ОПАСНО! пропадет вся работа, сделанная после этого коммита
# Сливает 2 последних коммита на удаленном репозитории
git reset --soft HEAD~2
git commit 'Your message'
git push -f origin master
git remote # показывает какие репозитории уже настроены
git remote –v # Чтобы посмотреть, какому URL соответствует сокращённое имя в Git. показать список удалённых репозиториев, связанных с этим
# Добавление/Удаление/Переименование удаленного репозитория
git remote add origin git://github.com/schacon/ticgit.git # Добавляет origin депозиторий
git remote add test git://github.com/paulboone/ticgit.git # Добавляет новый удалённый git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url]
git remote set-url origin url-адрес # обновить URL-адрес, но так, чтобы при этом не удалять локальный псевдоним
git remote set-url --add origin url-адрес # использовать origin и при этом отправлять изменения в разные удалённые репозитории
git remote get-url origin # получить URL-адрес удалённого репозитория
git remote set-url --delete origin https://github.com/uniqcle/html-academy.git # удалим данный репозиторий из origin
git remote remove origin # убрать привязку удалённого репозитория с сокр. именем origin
git remote rm origin # удалить привязку удалённого репозитория
git remote rename origin academy # переименуем origin в academy
git remote show origin # получить данные об удалённом репозитории
git push –u origin master # Отправляет наработки в удаленный репозиторий git push [удал. сервер] [ветка] git push --set-upstream origin main
git pull origin # влить изменения с удалённого репозитория (все ветки)
git pull origin master # влить изменения с удалённого репозитория (только указанная ветка)
git fetch origin # скачать все ветки с удаленного репозитория, но не сливать
git fetch origin master # то же, но скачивается только указанная ветка
git tag #Просмотр меток
git tag -a 'Ver1.0' -m "Ваш комментарий" #Создание меток
git tag -d 'Ver1.0' #Удаление метки
# Просмотр веток
git branch # какие ветки есть. Выводит список веток
git branch –a # --all показать все имеющиеся ветки (в т.ч. на удаленных репозиториях)
git branch -v # список веток и последний коммит в каждой
git branch -l # --list локальные ветки по маске. git branch -l "task-*"
git branch -r # --remotes
# создание ветки
git switch --create new_branch # альтернативный способ создания ветки и переход на нее -с
git branch new_branch #Создает ветку но не переключается на нее
git checkout -b new_branch #Создает ветку и тут же на нее переключается. new_f - название ветки
git checkout -b new-branch 5589877 #создать ветку new-branch, начинающуюся с коммита 5589877
# переключение
git switch master # переключиться
git checkout f_3 #Перейти в указанную ветку. Переключение между ветками. Переход на f_3
git checkout b9533bb #переключиться на коммит с указанным хешем
git checkout master #вернуться к последнему коммиту в указанной ветке
git switch --detach origin/main # переключение на удаленную ветку, если было сделано git fetch
# операции с ветками. Переименование/удаление/просмотр
git branch -m [<старое-название-ветки>] <новое-название-ветки> # переименование ветки
git branch -m new_branch_name #переименовать локально ТЕКУЩУЮ ветку в new_branch_name
git branch -d hotfix # --delete удалить ветку hotfix
git branch --delete --force hotfix # удал. без слияния
git push -d origin hotfix # --delete удал. на удаленном репозитории
git branch --merged # показать ветки, уже слитые с активной (их можно удалять)
git branch --no-merged # показать ветки, не слитые с активной
git push origin :old_branch_name new_branch_name #применить переименование в удаленном репозитории
git branch --unset-upstream #завершить процесс переименования
git checkout origin/github_branch
# посмотреть ветку, скачанную с удалённого репозитория (локальной редактируемой копии не создаётся! если нужно редактировать, придётся влить)
git checkout --track origin/github_branch
# создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё
git merge develop # Находясь в ветке main сливаем develop fast-forward (без коммита)
git merge --no-ff develop -m "message" # no-ff (с коммитом)
# сжатие сливаемых коммитов и создает 1. мелкие коммиты актуальны только на момент работы или проверки,
# а после их нужно объединить в один.
# переносятся лишь сделанные изменения, и они сразу добавляются в индекс,
# чтобы мы смогли самостоятельно создать коммит.
git merge develop --squash
git merge –-abort #Отмена слияние. Возращаем ветку до момента слияния
git config --global merge.tool kdiff3 #Утилита с помощью которой мержим
git mergetool #Запуск утилиты, если есть конфликты
git rebase new_branch # подтягивает последние изменения в ветке, с которой хотите мержить
Решаем конфликт с помощью командной строки git checkout --their index.html
Пропишем команду git merge conflict/command-line --no-ff --message "feat"
. Слияние будем выполнять с использованием режима no-fast-forward
, чтобы создался коммит слияния.
<<<<<<< HEAD (Current change)
<h1 class="subheading">title</h1>
=======
<h1 class="conflict">title</h1>
>>>>>>> conflict/command-line (Incoming change)
Если вы хотите выбрать изменение, пришедшее с conflict/command-line
, воспользуйтесь командой git checkout --their index.html
. Если хотите выбрать изменение, которое было на ветке main
, используйте команду git checkout --ours index.html
.
Опция --their
отвечает за входящие изменения, а опция --ours
— за принятие изменений, которые были сделаны в текущей (целевой) ветке.
Вместо файла index.html
может быть любой другой файл, в котором возник конфликт. Минус этого подхода в том, что если у вас конфликт в нескольких местах, то с помощью этих команд вы не сможете выбрать разные значения для разных участков кода. То есть у вас либо примутся все входящие изменения, либо все те, которые были в текущей ветке.
Если же вам нужно в одном месте принять входящие изменения, а в другом оставить текущие, придётся вручную менять файл. Собственно, как мы это делали в демонстрации, когда затягивали изменение с удалённого репозитория.
Мы выберем входящие изменения. Поэтому воспользуемся командой git checkout --their index.html
.
index.html
находится в разделе Unmerged paths
, что означает «Не слитые (не замкнутые) пути»
, а также имеет статус both modified — «Оба модифицированные»
.
Почему оба, если файл один? Git учитывает не только файл на ветке main``, но и на ветке
conflict/command-line```. Пока мы не добавим данное изменение в индекс и не зафиксируем, он будет считать оба файла модифицированными.
Давайте добавим изменение в индекс с помощью команды ``git add --all```.
Теперь у нас есть два варианта развития событий.
-
Мы можем самостоятельно создать коммит с помощью команды
git commit --message "текст коммита"
. -
Мы воспользуемся командой
git merge --continue
. Она позволяет продолжить слияние, поэтому у нас будет создан коммит с текстом, который мы указывали, когда прописывали команду слияния.
Мы выбираем второй вариант. Пропишем команду git merge --continue
. Тут нужно упомянуть: если слияние проходит с использованием режима fast-forward
, то вам придётся вручную создавать коммит.
Открылся специальный файл Git — COMMIT_EDITMSG
, который позволяет отредактировать текст коммита. Текст коммита нам редактировать не нужно. Поэтому, находясь в файле, просто нажмём сочетание клавиш Ctrl + S
, чтобы сохранить изменения, а затем закроем его.
Внизу в этом файле также отмечен наш модифицированный index.html
. После его закрытия вернёмся в Git Bash и увидим, что коммит создан.
git push
и удалем ветку git branch --delete conflict/command-line
Решаем конфликт с помощью VS Code Merge Editor
раздел Settings
или «Параметры».
Пропишем в поиске git.mergeEditor
.
Далее нам нужно убрать флажок, если хотим вернуть старый инструмент. Мы не будем этого делать, так как новый инструмент удобнее.
Нам также нужно установить Merge Editor для Git по умолчанию, чтобы его можно было вызывать из командной строки. Ведь если мы сейчас попробуем ввести команду git mergetool
, то получим ошибку: не настроен ни один инструмент.
Перейдём в глобальный конфигурационный файл c:users
и после всех записей добавим следующее:
[merge]
tool = vscode
[mergetool "vscode"]
cmd = code --wait --merge $REMOTE $LOCAL $BASE $MERGED
[mergetool]
keepBackup = false
Давайте разберём новые разделы:
В [merge]
с ключом tool
мы указали редактор кода vscode как инструмент по умолчанию.
В разделе [mergetool "vscode"]
с ключом cmd мы указали, что после написания команды git mergetool
должна открыться новая вкладка в редакторе кода VS Code для решения конфликта.
В разделе [mergetool]
с ключом keepBackup
мы установили значение false
, что означает «не нужно сохранять резервные копии после решённых конфликтов».
После этого закрываем конфигурационный файл.
Если мы сейчас пропишем команду git mergetool
, то увидим совсем другую картину. Git сообщит, что файлов, нуждающихся в объединении, нет.
Создаем ветку git switch --create conflict/merge-editor
Создаем записи, сохраняем. В ветке main git merge conflict/merge-editor --no-ff --message "feat: the branches were merged"
Образовался конфликт.
git mergetool
-> Complete Merge
-> ```git add`` -> commit -> git push
--oneline
— выводит хэш в укороченном формате, ветку, в которой был сделан коммит, а также текст коммита. Это опция, пожалуй, наиболее используемая, так как позволяет уместить большее количество коммитов на одном экране.
--stat
— выводит список коммитов, как и обычная команда git log
, а также статистику по изменённым файлам (какие файлы были изменены и количество изменённых строк).
--shortstat
— уменьшенная версия опции --stat. Она выводит только общее количество изменённых файлов и количество изменённых строк.
--name-only
— выводит то же самое, что и команда git log
, а также дополнительно список изменённых файлов.
--name-status
— улучшенная версия --name-only
. Выводит названия изменённых файлов и статус, который у них был на момент коммита. Позволяет отследить, какие файлы были добавлены или удалены.
--abbrev-commit
— выводит то же самое, что и команда git log
, но вместо длинного хэша будет короткий, как при использовании опции --oneline
.
--relative-date
— выводит то же самое, что и команда git log
, только показывает дату в относительном формате, что порой бывает удобно (например, 2 дня назад).
-p
— позволяет посмотреть не только то, что выводит обычная команда git log, но ещё и показывает, какие конкретно изменения были сделаны в каждом коммите. Отметим, что примерно такой же вывод есть и у команды git diff
— она позволяет сравнивать коммиты и обычные файлы.
Сначала ставится -
, а после без пробела пишется цифра. Цифра указывает, какое количество последних коммитов нужно отобразить. У неё точно такой же вывод, как и у команды git log.
--author=имя-автора
— позволяет вывести коммиты от определённого автора. Когда в команде работает несколько человек, бывает трудно найти коммиты определённого сотрудника, а эта опция решает данную проблему.
--graph
— дополнительно к стандартному выводу команды git log показывает ASCII-граф, в котором отображается история ветвлений и слияний.
--reverse
— позволяет вывести коммиты в обратном хронологическом порядке, то есть сначала будут идти старые, а потом новые.
--after=дата
— выводит коммиты, которые были сделаны после определённой даты.
--before=дата
— выводит, коммиты которые были сделаны до определённой даты.
какие опции мы используем чаще всего в работе:
git log --oneline
git log --stat --abbrev-commit --relative-date --graph
git log -p index.html # показать историю изменений файла index.html (выход из длинного лога: Q)
git log -p -5 index.html #показать историю изменений файла index.html (последние 5 коммитов, выход из длинного лога: Q)
git log -2 #показать последние 2 коммита
git log -2 --stat # показать последние 2 коммита и статистику внесенных ими изменений
git log -p -22 Q) #показать последние 22 коммита и внесенную ими разницу на уровне строк (выход из длинного лога:
git log --pretty=format:"%h - %an, %ar : %s" -4 #показать последние 4 коммита с форматированием выводимых данных
git log --graph -10 #показать последние 10 коммитов с ASCII-представлением ветвления
git log --since=2.weeks #показать коммиты за последние 2 недели
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short #мой формат вывода, висящий на алиасе оболочки
git log master..branch_99 # показать коммиты из ветки branch_99, которые не влиты в master
git log branch_99..master #показать коммиты из ветки master, которые не влиты в branch_99
git show 60d6582 #показать изменения из коммита с указанным хешем
git show HEAD^ #показать данные о предыдущем коммите
git diff # посмотреть непроиндексированные изменения (если есть, иначе ничего не выведет). Что изменили, но не проиндексировали
git diff --staged # посмотреть проиндексированные изменения (если есть, иначе ничего не выведет). Что проиндексировали и уйдет в следующий коммит.
git .git/ #Зайти в папку
git #информация по командам
# //комментарий
docs/ #исключение папки и все что в ней находится
# docs/*.txt #исключение файлов по маске расширения
git help <команда>
git <команда> --help
man git-<команда>
gitk #Вызов Git редактора после коммитов
git status
git status --untracked-files=normal # all none normal
ls # показывает какие файлы есть в папке
# удалить из репозитория все неотслеживаемые папки и файлы (папки и файлы, добавленные в .gitignore останутся на месте)
git clean -f -d
git branch feature/the-finest-branch // создай ветку от текущей с названием feature/the-finest-branch;
git checkout -b feature/the-finest-branch // создай ветку feature/the-finest-branch и сразу переключись на неё.
git branch // покажи, какие есть ветки в репозитории (текущая ветка *);
git branch -a // покажи все известные ветки, как локал, так и удалённые (в origin, или на GitHub).
git checkout feature/br // переключись на ветку feature/br.
git diff main HEAD // покажи разницу между веткой main и указателем на HEAD;
git diff HEAD~2 HEAD — покажи разницу между тем коммитом, который был два коммита назад, и текущим.
git branch -d br-name // удали ветку br-name, но только если она является частью main;
git branch -D br-name // удали ветку br-name, даже если она не объединена с main.
git push -u origin my-branch // отправь новую ветку my-branch в удалённый репозиторий и свяжи локальную ветку с удалённой, чтобы при дополнительных коммитах можно было писать просто git push без -u;
git push my-branch // отправь дополнительные изменения в ветку my-branch, которая уже существует в удалённом репозитории;
git pull // подтяни изменения текущей ветки из удалённого репозитория.