Программирование PC Краткий справочник по Git Thu, November 21 2024  

Поделиться

Нашли опечатку?

Пожалуйста, сообщите об этом - просто выделите ошибочное слово или фразу и нажмите Shift Enter.


Краткий справочник по Git Печать
Добавил(а) microsin   

Небольшая памятка по командам Git, приемы работы с локальным репозиторием.

1. Основные команды (выполненные в текущем каталоге корневой папки проекта):

Команда Функция
git init Создание репозитория в текущем каталоге.
git config user.name "имя" Ввод имени пользователя репозитория(1).
git config user.email "box@domain.ru" Ввод email пользователя репозитория(1).
git add -n * Проверка, какие файлы будут добавлены в репозиторий.
git add readme.txt Добавить в репозиторий файл readme.txt(2).
git add util/**/*.cpp Добавить все файлы *.cpp, которые находятся в папке util и её подкаталогах.
git add *.c *.h *.s *.asm Добавить в репозиторий все файлы(2) с расширениями *.c, *.h, *.s, *.asm.
git add --all Добавит изменения всех отслеживаемых и не отслеживаемых в базе файлов. Опция -A аналогична опции --all, см. далее врезку "Q20. Как удалить отслеживаемые файлы из репозитория".
git commit -m "190311 first commit" Выполнить коммит репозитория. Чтобы исправить текущую фиксацию, используйте команду git commit --amend.
git commit -am "текст комментария" Добавление опции -a автоматически отразит в базе репозитория все отслеживаемые, модифицированные файлы перед применением фиксации. См. далее врезку "Q20. Как удалить отслеживаемые файлы из репозитория".
git status Показать состояние репозитория - какие файлы были добавлены или изменены.
git status --untracked-files=no Показать состояние репозитория без отображения файлов, которые еще не добавлены в репозиторий.
git rm --cached имяфайла Убирает из индекса репозитория указанный файл (он больше не отслеживается). В рабочем каталоге этот файл останется. Команду удобно использовать, если вы поторопились добавить в индекс файл командой add, и хотите сделать дополнительные изменения в этом файле.
git log Просмотр истории изменений репозитория (история фиксаций commit).
git log --reflog Просмотр истории ВСЕХ фиксаций. Эта команда полезна, когда был произведен откат на более старую фиксацию (простая команда git log более свежие фиксации не покажет). См. также git reflog.
git reflog Просмотр истории всех фиксаций в сокращенном виде. В некоторых случаях эта команда более удобна, чем git log --reflog. См. также врезку "Отличия git log --reflog и git reflog".
git pull Взять изменения из remote-репозитория в локальный репозиторий.
git push Выгрузить изменения в локальном репозитории в remote-репозиторий.
git push -uf Принудительная выгрузка локальных изменений на сервер. Полезно использовать после команды git commit --amend.
git clone address [newname] Сделать локальную копию репозитория(3).
git checkout -b имяветки Создание новой ветви имяветки в репозитории, и переключение на работу в ней. Основная ветвь носит имя master, содержимое ветви master будет сохраняться неизменной.
git checkout master Возврат в основную ветвь репозитория.
git checkout -- файл Откат текущих изменений файла. Файл вернется к состоянию, которое было сохранено в последнем commit. Внимание: все изменения в файле, если они были, будут безвозвратно потеряны!
git stash Позволяет временно заархивировать (припрятать [7]) измененные, но не прошедшие commit файлы, когда их требует перезаписать команда git pull.
git commit -e Откроет текстовый редактор для ввода комментария фиксации. Этот вариант создания фиксации позволяет нативно вводить многострочный комментарий [11].
git diff ... Сравнение фиксаций или ветвей проекта [12].
git reset --hard Откат изменений всех файлов к последней фиксации. Внимание: это опасная команда в том плане, что все не зафиксированные изменения в файлах будут потеряны, и проект вернется к последнему состоянию, который был сохранен последним commit.

Примечания:

(1) Просмотреть все настройки можно командой git config -l или git config --list.
(2) Если добавляемые файлы уже присутствуют в репозитории, то будут отображены изменения в этих файлах.
(3) Команда git clone автоматически создаст папку для репозитория. Если не указан параметр newname, то имя этой папки будет назначено автоматически из имени репозитория, иначе репозиторий будет создан в папке с именем newname.

2. Подробная помощь по команде (откроется окно браузера со справкой):

git help команда

3. Краткая подсказка по команде:

git команда -h

4. Файл .gitignore позволяет создать список файлов, которые не нужно отслеживать. В этом файле можно делать комментарии, комментарием считается строка, которая начинается на символ #. В каждой строке указывается имя файла, который игнорируется, в именах можно использовать символы группирования * и ?. Чтобы исключить папку и файлы в ней, нужно добавить имя папки со слешем в конце, например: Debug/. Примеры файлов .gitignore см. в [4].

5. Можно создавать алиасы (синонимы) команд для быстрого доступа к ним. Вот так например, можно создать синоним git st для команды git status:

git config --global alias.st "status -s"

После этого команды git st и git status будут выполняться одинаково.

Установка выполняется по шагам с помощью обычного мастера. Однако не некоторых шагах не очевидно, какие опции выбирать.

Начальные 4 шага вопросов не вызывают. Нужно согласиться с условиями лицензии, выбрать папку для установки, поставить галочки устанавливаемых компонентов, выбрать место размещения для ярлыков запуска. Можно оставить все по умолчанию:

Git setup01

Git setup02

Git setup03

Git setup04

На этом шаге лучше всего выбрать редактор, которым Вы привыкли пользоваться. Мне нравится Notepad2:

Git setup05

На этом шаге предлагают настроить рабочее окружения для запуска Git. Первый вариант никак не модифицирует переменные окружения, подразумевается запуск Git под управлением командной строки MinGW bash. Второй и третий вариант прописывает некоторые переменные окружения (пути запуска), чтобы можно было запускать Git как из стандартного интерпретатора команд Windows, так и из MinGW bash. Я выбрал второй вариант, который задан по умолчанию:

Git setup06

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

Git setup07

Здесь выбрал вариант, который при операциях Git не модифицирует окончания строк текстовых файлов:

Git setup08

Здесь лучше оставить выбор по умолчанию. Вариант настройки MinTTY обеспечивает удобную цветовую подсветку выводимого текста в консоли:

Git setup09

Эти опции тоже лучше оставить по умолчанию:

Git setup10

Git setup11

Git setup12

Как работать с Git по шагам, начиная с создания репозитория. Предполагается, что Git уже установлен.

1. Зайдите в рабочий каталог проекта, запустите сессию bash. Можно конечно пользоваться и стандартной командной строкой Windows, но MINGW64 Bash удобнее, потому что он предоставляет цветовую подсветку сообщений, и корректно поддерживает Unicode, что позволяет пользоваться русскими буквами в командах Git.

Git MINGW64 Bash window

2. Необходимо создать репозиторий и указать для него имя пользователя и email. Для создания репозитория выполните команду:

git init

После этого выполните следующие команды (вместо Your Name и anyemail@domain.ru укажите любое имя и адрес электронной почты):

git config --global user.name "Your Name"
git config --global user.email "anyemail@domain.ru"

3. Выполните команду git add -n *, которая выведет список файлов, которые могут быть потенциально добавлены в репозиторий. Скорее всего, в этом списке будут некоторые файлы, изменение которых отслеживать не нужно (объектные и двоичные файлы, картинки, логи и т. п.). Если такие файлы есть, то перейдите к шагу 4, а если нужно добавить все файлы из выведенного списка, то перейдите к шагу 6.

Если проект большой, и много его файлов находится в отдельных папках, то команду проверки git add -n можно запускать на файлы только одной папки. Например, вот проверка, какие файлы будут добавляться в репозиторий из папки lib проекта:

git add -n lib

4. Создайте в текстовом редакторе файл .gitignore, после этого начните добавлять в него записи для тех файлов, которые нужно игнорировать (Git не будет их отслеживать). Начните с папок, которые находятся в каталоге проекта, папку .git обрабатывать не нужно, это служебная папка.

Внимание: чтобы можно было в файле .gitignore использовать имена файлов с русскими буквами, файл .gitignore должен быть в кодировке UTF-8.

Предположим, что есть папка bin в каталоге проекта, и в ней находятся файлы с расширениями dlb, ldr, bin, log, которые не надо добавлять в репозиторий. Тогда в файл .gitignore добавьте следующие строки:

# Что игнорировать в папке bin:
bin/*.dlb
bin/*.ldr
bin/*.bin
bin/*.log

Если в папке много подкаталогов, и Вы хотите обработать их сразу все, то можно воспользоваться группировкой /**/:

doc/**/*.bmp

Обратите внимание, что первая строка начинается на #, это просто комментарий, добавленный для удобства. Сохраните файл .gitignore и снова выполните команду git add -n *, Вы увидите, что файлы из составленного списка игнорируются.

Каждую отдельную папку можно проверять командой  git add -n имяпапки/.

5. После того, как создали список игнорируемых файлов для папки, добавьте её в репозиторий на отслеживание, для этого выполните команду git add без опции -n. Например, так добавляется папка lib:

git add lib/

Аналогичные шаги 4 и 5 проделайте со всеми папками и файлами проекта.

6. Теперь осталось сделать коммит.

git commit -m "190312 первый коммит"

Здесь опция -m задает обязательный комментарий для коммита. В комментарии я люблю указывать 6 цифрами дату коммита (YYMMDD). Имейте в виду, что русские буквы в комментарии можно указывать только в командной строке bash (он устанавливается вместе с Git).

7. Чтобы сделать локальную копию репозитория в текущем каталоге на диске, используйте команду git clone. Пример клонирования репозитория BluetoothBLEClient [8] через web-ссылку:

git clone https://github.com/jjjsmit/BluetoothBLEClient.git

# Что игнорировать в папке bin:
bin/*.dlb
bin/*.ldr
bin/*.bin
bin/*.zlib
bin/*.log
 
# Что игнорировать в папке bootloader:
bootloader/*.pcf
bootloader/Debug/
bootloader/Release/
 
# Все содержимое в папке deleted игнорируется:
deleted/
 
# Что игнорировать в папке doc:
doc/**/*.pdf
doc/**/*.png
doc/**/*.bmp
doc/**/*.svg
doc/**/*.zip
doc/**/*.jpg
doc/**/*.psd
doc/**/*.png
doc/**/*.xls
doc/**/*.doc
doc/**/*.docx
doc/**/*.spl7
doc/181219автовыбор-КРЛ
 
# Что игнорировать в папке lib:
lib/**/*.bak
lib/**/*.old
lib/**/*.pcf
lib/**/*.dlb
 
# Что игнорировать в папке mainapp-VDK:
mainapp-VDK/**/*.dlb
mainapp-VDK/**/*.bak
mainapp-VDK/**/*.pcf
mainapp-VDK/**/*.log
 
# Что игнорировать в папке pictures:
pictures/**/*.bmp
pictures/**/*.png
pictures/**/*.psd
pictures/**/*.old
pictures/**/*.bin
pictures/**/*.pdf
pictures/**/*.zlib
 
# Что игнорировать в папке util:
util/**/*.als
util/**/*.exe
util/**/*.dxe
util/**/*.old
util/**/*.zip
util/**/*.bmp
util/**/*.ico
util/**/*.dll
util/**/*.o
util/**/*.vsd
util/**/*.suo
util/**/*.gz
util/**/*.url
util/**/*.pfx
util/**/*.ldr
util/**/*.chm
util/calibr/Debug/
util/calibr/Release/
util/calibr/bin/Debug/
util/calibr/bin/Release/
util/calibr/obj/
util/calibr/publish/
util/zpipe-test/pack01
util/zpipe-test/src
util/visa/bin/Debug/
util/visa/bin/Release/
util/visa/publish/
util/visa/obj/

[git reflog]
 
NAME
   git-reflog - Управление информацией reflog
 
SYNOPSIS
   git reflog < subcommand> < options>
 
DESCRIPTION
   Эта команда принимает различные субкоманды (subcommand), а также различные опции (options), зависящие от
   subcommand:
 
      git reflog [show] [log-options] [< ref>]
      git reflog expire [--expire=< time>] [--expire-unreachable=< time>]
                 [--rewrite] [--updateref] [--stale-fix]
                 [--dry-run | -n] [--verbose] [--all [--single-worktree] | < refs>...]
      git reflog delete [--rewrite] [--updateref]
                 [--dry-run | -n] [--verbose] ref@{specifier}...
      git reflog exists < ref>
 
   Ссылка на лог (reference logs, или "reflogs") записывается, когда в локальном репозитории обновляются подсказки
   по ветвям (tips of branches) и другие ссылки. Reflogs полезны в различных командах Git, чтобы можно было
   указать старое значение ссылки. Например, HEAD@{2} означает "где имя HEAD использовалось за 2 перемещения
   до этого", а master@{one.week.ago} означает "где имя master используется для указания на одну неделю ранее
   в этом локальном репозитории", и так далее. См. в gitrevisions(7) для более подробной информации.
 
   Эта команда управляет информацией, записанной в reflogs.
 
   Субкоманда "show" (которая также активируется по умолчанию, когда не указана субкоманда для git reflog) покажет
   лог ссылки, предоставленной в командной строке (или HEAD, по умолчанию). Команда reflog охватывает все недавние
   действия, и дополнительно HEAD reflog записывает переключение между ветвями репозитория. Команда git reflog show
   это алиас для команды git log -g --abbrev-commit --pretty=oneline; см. git-log(1) для дополнительной информации.
 
   Субкоманда "expire" elfkztn старые записи журнала. Записи, которые старше чем expire time, или записи, которые
   старее чем expire-unreachable time, и недоступные из текущего состояния (current tip), будут удалены из reflog.
   Обычно это не используется напрямую — вместо этого см. git-gc(1).
 
   Субкоманда "delete" удаляет одиночные записи из reflog. Её аргумент должен четко указывать на удаляемую запись
   (например "git reflog delete master@{2}"). Эта субкоманда также обычно не используется напрямую.
 
   Субкоманда "exists" проверит, subcommand есть ли в reflog ссылка ref. Если есть, то будет возвращен нулевой
   статус, иначе будет возвращен ненулевой статус.
 
Опции для show:
   git reflog принимает любые опции, которые принимает команда git log.
 
Опции для expire:
   --all
      Обработать reflogs всех ссылок.
 
   --single-worktree
      По умолчанию, когда указано --all, обрабатываются reflogs из всех рабочих ветвлений (working trees). Эта опция
      ограничит обработку на reflogs только из текущего working tree.
 
   --expire=< time>
      Удалит записи, которые старше указанного времени time. Если эта опция не указана, то время устаревания
      (expiration time) берется из установки конфигурации gc.reflogExpire, которая в свою очередь по умолчанию
      равна 90 дней. Опция --expire=all удалит записи независимо от их возраста; --expire=never выключит удаление
      доступных записей (однако см. --expire-unreachable).
 
   --expire-unreachable=< time>
      Удалит записи старее чем < time>, которые недоступны из текущего положения (current tip) ветви репозитория.
      Если эта опция не указана, то expiration time берется из установки конфигурации gc.reflogExpireUnreachable,
      которая в свою очередь по умолчанию равна 30 дням. Опция --expire-unreachable=all удалит недоступные
      записи независимо от их возраста; --expire-unreachable=never выключит раннее удаление недоступных
      записей (однако см. --expire).
 
   --updateref
      Обновит ссылку на значение верхней записи reflog (т. е. < ref>@{0}), если предыдущая верхняя запись была
      удалена (эта опция игнорируется для символических ссылок).
 
   --rewrite
      Если предшествующая запись reflog была удалена, подстроит её "old" поле SHA-1 равным "new" SHA-1 полю записи,
      которая ей теперь предшествует.
 
   --stale-fix
      Удалит любые записи reflog, указывающие на "испорченные фиксации" (broken commits). Испорченная фиксация
      это commit, который недоступен из любого имени ссылки (reference tip), и таким образом ссылается, прямо
      или косвенно, на отсутствующий commit, tree, или объект blob.
 
      Это вычисление включает в себя обход всех доступных объектов, т. е. это имеет ту же стоимость, что и
      git prune. Это главным образом предназначено для исправления повреждения, вызванного сборкой мусора
      (см. git-gc) более старых версий Git, которые не защищают объекты, на которые ссылается reflogs.
 
   -n, --dry-run
      Не делает реальное удаление любых записей; просто покажет, какие записи могли быть удалены.
 
   --verbose
      Выводит дополнительную информацию.
 
Опции для delete:
   Команда git reflog delete принимает опции --updateref, --rewrite, -n, --dry-run и --verbose, которые имеют
   тоже самое значение, которое использовалось для субкоманды expire.
 
[git log --reflog]
 
   --reflog
      Работает так, как если бы все объекты, упомянутые в reflog, были перечислены в командной строке
      как < commit>.

[Манипуляции с ветками (branch)]

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

Команда Функция
git branch Показать список всех веток, которые существуют в репозитории. По умолчанию в репозитории существует только одна основная ветка - master. Если веток несколько, то текущая ветка будет помечена звездочкой и её название выделена зеленым текстом.
git branch -a Посмотреть список веток в локальном и сетевом репозитории. Текущая ветка в локальном репозитории будет выделена зеленым цветом, а ветки в сетевом репозитории будут выделены красным, и будут иметь префикс remotes/origin/.
git branch имяновойветки Создать новую ветку в проекте без переключения на неё.
git checkout -b имяновойветки Создать новую ветку и переключиться на неё.
git switch -c имяновойветки Создать новую ветку от текущей фиксации, и сделать эту ветку текущей. Как переключаться между фиксациями, см. [9].
git branch -D имяветки Удалить ветку.
git switch - Отмена предыдущей операции переключения между ветками.
git checkout ссылканаветку Переключение между ветками. Вместо ссылканаветку может быть указано либо имя ветки (master или любое другое имя), либо первые шесть HEX-символа хеша фиксации. Список фиксаций с хешами можно посмотреть командой git log --pretty=oneline.
git branch -m old new Переименовать ветку. Ветка с именем old получит имя new.
git diff локальная_ветка origin/ветка_на_сервере_Git Сравнить локальную ветку репозитория и такую же ветку в сетевом репозитории. Например:

git diff feature/activation_done origin/feature/activation_done

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

[FAQ]

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

git config --global user.name "Your Name"
git config --global user.email "anyemail@domain.ru"

Вместо Your Name и anyemail@domain.ru подставьте свое имя и адрес электронной почты.

Создайте файл .gitignore, поместите его в корневую папку проекта (там же, где находится папка репозитория .git), и в этом файле создайте строки, обозначающие исключаемые файлы (см. выше описание работы с файлом .gitignore).

Для этого используйте группировку /**/. Например, следующая запись .gitignore исключит из репозитория все файлы *.pdf, которые находятся в папке util, и во всех её подкаталогах:

util/**/*.pdf

Групповые подстановки можно также использовать и в командной строке Git.

Файл .gitignore должен иметь кодировку UTF-8. Вместо стандартной консоли команд cmd.exe в Windows используйте командную строку MINGW64 bash (устанавливается вместе с Git).

Процесс по шагам (взято из замечательной статьи [6]):

1. Сначала надо создать на сервере пустой репозиторий. Обычно это делается в HTML-интерфейсе сервера. После этого нужно запомнить Git-ссылку на этот репозиторий. Предположим, ссылка такая:

http://git.netserver.ru/username/myproject.git

2. В папке локального репозитория выполнить команды:

git remote add server http://git.netserver.ru/username/myproject.git
git push server master:master

Первая команда добавляет в конфигурацию репозитория новый сервер, вторая делает выгрузку репозитория на сервер.

3. Для того, чтобы команды git теперь работали с репозиторием на сетевом сервере git.netserver.ru, выполните команду:

git config remote.origin.url http://git.netserver.ru/username/myproject.git

Иногда надо дополнительно выполнить следующую команду, чтобы протолкнуть (push) текущую ветку репозитория (branch) на сетевой сервер, и установить его как приемник push:

git push --set-upstream origin master

После этой команды  git push и git pull будут по умолчанию работать с репозиторием на сетевом сервере.

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

git add .
git commit -a
git push

Чтобы засинхронизировать текущий проект с сервером, используйте команду:

git pull

В репозитории (это был nRF5x SDK 12.3) множество проектов примеров содержат файлы Makefile, распределенные по разным каталогам. Простая команда с указанием имени файла не позволяет добавить в репозиторий эти файлы:

d:\asm\nRF5_SDK_12.3.0_d7731ad>git add Makefile
fatal: pathspec 'Makefile' did not match any files

Проблема в том, что тут указано полное имя, без шаблона wildcard. Чтобы команда сработала, нужно указать в качестве имени файла */Makefile, что будет соответствовать файлам Makefile в любом из подкаталогов репозитория:

d:\asm\nRF5_SDK_12.3.0_d7731ad>git add */Makefile
add 'examples/ant/ant_advanced_burst/d52_starterkit/s212/armgcc/Makefile'
add 'examples/ant/ant_advanced_burst/pca10040/s212/armgcc/Makefile'
add 'examples/ant/ant_async_transmitter/d52_starterkit/s212/armgcc/Makefile'
add 'examples/ant/ant_async_transmitter/pca10040/s212/armgcc/Makefile'
add 'examples/ant/ant_background_scanning/d52_starterkit/s212/armgcc/Makefile'
add 'examples/ant/ant_background_scanning/pca10040/s212/armgcc/Makefile'
add 'examples/ant/ant_broadcast/rx/d52_starterkit/s212/armgcc/Makefile'

На примере файла .gitignore:

git add .gitignore

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

git add ".*"

Попытался сделать push ветки на сервер, не получилось, git выдает сообщение:

fatal: Вы сейчас не находитесь ни на одной из веток

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

1. Копию всех исходников!
2. git checkout имя_той_ветки_котору_надо_выгрузить_на_сервер. Эта команда отменит все изменения, и вернет старое локальное состояние этой ветки.
3. Вернуть все исходники обратно из копии, сделанной на шаге 1.
4. git add *, git commit -m "bla-bla"
5. git push

Восстановить случайно удаленный файл можно командой git checkout имяфайла.

$ git status
Текущая ветка: main
Эта ветка соответствует « main ».
 
Изменения, которые не в индексе для коммита:
   удалено:       src/adcbatt.c
   удалено:       src/main.c
 
$ git checkout src/adcbatt.c
Updated 1 path from the index
$ git checkout src/main.c
Updated 1 path from the index

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

1. Копию всех исходников!
2. git checkout имя_той_ветки_котору_надо_выгрузить_на_сервер. Эта команда отменит все изменения, и вернет старое локальное состояние этой ветки.
3. Вернуть все исходники обратно из копии, сделанной на шаге 1.
4. git add *, git commit -m "bla-bla"
5. git push

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

$ git status
fatal: detected dubious ownership in repository at '/home/имяпользователя/каталог'
To add an exception for this directory, call:
 
   git config --global --add safe.directory /home/имяпользователя/каталог

Исправить ошибку можно либо командой git config --global, как советуется в этом сообщении об ошибке, либо если поменять владельца каталога репозитория на текущего пользователя:

$ sudo chown -R $USERNAME каталогрепозитория

Откат одного файла:

$ git checkout -- полный/путь/до/файла

Откат всех файлов сразу:

$ git reset --hard

Следующие команды принудительно перезапишут локальные изменения репозитория и восстановят зафиксированное состояние из сетевого репозитория:

$ git reset --hard HEAD
$ git pull

Более мягкие методы, например с помощью команды git stash, см. в посте [10].

Используйте команду git diff. Подробнее см. [12].

Предположим, что вы сделали несколько изменений в проекте, и не хотите делать фиксацию (commit) этих изменений. И вам нужно переключиться на какую-то предыдущую фиксацию, сбросив все эти изменения. Для этого нужно сначала сбросить все изменения командой git reset --hard, а потом командой git checkout переключиться на нужную фиксацию, указав её контрольную сумму:

$ git reset --hard
$ git checkout 93daeff2400033f00e5adbf04fb68cab27e7f9ff

Цветной вывод:

git reflog --date=iso

Монохромный вывод:

git reflog --pretty='%cd %h %gd %gs'

Пользовательский формат:

git reflog --format='%C(auto)%h %< |(20)%gd %C(blue)%cr%C(reset) %gs (%s)'
git reflog --format='%C(auto)%h %< |(20)%gd %C(blue)%ci%C(reset) %gs (%s)'
git reflog --pretty='%Cred%h%Creset -%C(auto)%d%Creset %gs %Cgreen(%cr) %C(bold blue)< %an>%Creset'
git reflog --pretty='%Cred%h%Creset -%C(auto)%d%Creset %gs %Cgreen(%ad) %C(bold blue)< %an>%Creset'
git reflog --format="%C(yellow)%h%C(reset) %gs %C(green)%ad%C(reset) %C(blue)[%ar]%C(reset)"

См. также [16].

git log --graph --oneline --decorate --all
git log --graph --simplify-by-decoration --pretty=format:'%d' --all

См. также [17].

При переходе на новый SDK было удалено из локальной папки проекта множество файлов. После команд git add * и git commit -m "сообщение фиксации" эти файлы остались в локальном репозитории git, помеченные как "deleted". Как их быстро удалить, чтобы не удалять каждый файл по отдельности командой git rm?

Это можно сделать следующей последовательностью команд:

$ git add --all
$ git commit -am "Удалил файлы из репозитория git."
$ git status
$ git push

Что означает -all. Опция --all команды add (можно применить вместо неё -A) добавит изменения всех отслеживаемых и не отслеживаемых в базе файлов, т. е. удалит из репозитория все удаленные в проекте файлы, и добавит не отслеживаемые, в том числе и те, которые начинаются на точку (такие как .gitignore или .config) (см. [1]).

Что означает -am. Из документации: "Команда git commit -a автоматически отразит в базе репозитория все отслеживаемые, модифицированные файлы перед применением фиксации. Если вы считаете, что стадия git add в рабочем процессе излишняя, Git позволит вам пропустить эту часть с помощью опции -a. Это в основном говорит Git запустить git add на любом файле, который "отслеживается" - т. е. на любом файле, который был в вашей последней фиксации, и который был изменен. Это позволит вам, если захотите, получить рабочий процесс больше похожим на стиль Subversion, когда после редактирования файлов вы просто запускаете git commit -a, когда хотите сделать снимок всего, что было изменено. Хотя вам все еще понадобится запустить команду git add, чтобы начать отслеживать новые файлы, так же как и в Subversion.

Таким образом, команда git commit -am позволит вам добавить изменения в базу репозитория и одновременно создать фиксацию с указанным сообщением [2].

[Pro Git]

Существует книга, которая может послужить замечательным введением в мир git - Pro Git, авторы Scott Chacon и Ben Straub. Эта книга переведена на многие языки, в том числе и на русский язык.

Книга на русском языке доступна в виде репозитория GitHub [13], а также доступна её онлайн-версия [14]. Получить книгу последней версии в популярных электронных форматах можно, если выполнить её компиляцию (см. врезку).

$ git clone https://github.com/progit/progit2-ru.git
$ cd progit2-ru/
$ bundle config set --local path '.bundle/vendor'
$ bundle install
$ bundle exec rake book:build

После выполнения этой команды в папке проекта progit2-ru появятся скомпилированные файлы progit.pdf, progit.mobi, progit-kf8.epub, progit.fb2.zip, progit.epub, progit.html.

При выполнении команды bundle install столкнулся с ошибкой:

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
current directory:
/home/ADMSK/apsinyutki/asm/progit2-ru/.bundle/vendor/ruby/3.0.0/gems/racc-1.7.3/ext/racc/cparse
/usr/bin/ruby3.0 -I /usr/lib/ruby/vendor_ruby -r ./siteconf20240109-25035-tgyk07.rb extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/include/ruby.h
You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.
extconf failed, exit code 1

Как исправить:

$ sudo apt install ruby-bundler

[Словарик]

branch ветвление проекта (создание его отдельной версии в репозитории).

commit легковесный снимок состояния файлов в определенный момент времени (когда был сделан коммит).

head самая последняя версия файлов в репозитории.

repository репозиторий, база данных, где хранится история изменений проекта. Git хранит репозиторий в папке .git, которая находится в корневом каталоге проекта.

staging area область файловой системы (список файлов), подготовленная к коммиту.

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

[Ссылки]

1. Downloads Git site:git-scm.com.
2. Learn Git site:atlassian.com.
3. Подробное введение в работу с Git site:tproger.ru.
4. A collection of useful .gitignore templates site:github.com.
5. git: быстрый старт.
6. Как перенести локальный GIT-репозитарий на сервер вместе со всей историей site:webhamster.ru.
7. Инструменты Git - Припрятывание и очистка site:git-scm.com.
8. jjjsmit / BluetoothBLEClient site:github.com.
9Git: как переключаться между фиксациями.
10. How do I force "git pull" to overwrite local files? site:stackoverflow.com.
11. git: как создавать многострочный комментарий для commit.
12. git: как сравнивать фиксации и ветки.
13. Репозиторий Pro Git на русском языке.
14. Онлайн-версия Pro Git на русском языке.
15. 240109progit2-ru.zip - скомпилированная книга Pro Git на русском языке в форматах  HTML, EPUB, FB2, Mobi (kf8), PDF.
16. Is there a way to cause git-reflog to show a date alongside each entry? site:stackoverflow.com.
17. Output of git branch in tree like fashion site:stackoverflow.com.

 

Добавить комментарий


Защитный код
Обновить

Top of Page