Библиотека знаний - unix:git

.gitignore файл

Anonymous (anonymous@undisclosed.example.com) — 2017-02-16T02:04:01+00:00

.gitignore файл

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

If a file is already being tracked by Git, adding the file to .gitignore won’t stop Git from tracking it. You’ll need to do git rm –cached <file> to keep the file in your tree and then ignore it.

Исключем из индекса

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

$ git update-index --assume-unchanged -- <file>

или

$ git rm --cached <file>

А для получения списка файлов можете воспольоваться

$ git status --porcelain

И в нем найти необходимый файл с помощью grep

Включаем в индекс

$ git update-index --no-assume-unchanged -- <file>

Особенности

.gitignore не влияет на git stash save, хотя влияет на git clean -df

Почему так, я и не понял.

Редактирование истории в git

Anonymous (anonymous@undisclosed.example.com) — 2015-09-25T09:20:00+00:00

scm, git

Редактирование истории в git

Более строго следует говорить не о "редактировании" или "изменении" истории, а о cоздании "альтернативной" истории. Если специально ничего не предпринимать, в репозитории git остаются все объекты "старой" истории, соответствующие предыдущим коммитам и версиям файлов. На эти объекты не будут "ссылаться" ветки, но если Вы вспомните их SHA1-ключи, либо как-то специально позаботитесь их "пометить" (тэгом, или другой веткой), то старая история будет c точки зрения git "ничем не хуже" новой.

Почти во всех командах git можно ссылаться на коммиты любым способом: - с помощью SHA1-ключа, - с помощью имени ветки (если это последний коммит на ветке), - с помощью тэга (если вы его предусмотрительно поставили git tag), - c помощью специальных имён, например HEAD - последний коммит на

 данной ветке, HEAD^ - предпоследний (точнее, первый предок
 последнего коммита) и т.п. Подробности см. git-rev-parse --help

Ниже в командах, которые допускают любую идентификацию коммита, я буду указывать в качестве аргумента <id>, или <id-…>. Если допускается только имя ветки, указывается <ветка>.

Для начинающих я рекомендую приступая к редактированию истории пометить все ключевые точки тэгами. Их хорошо видно в gitk. Только не забудьте их потом удалить git tag -d

В понятие истории git я буду включать не только совокупность коммитов git-а, но и содержание рабочего каталога (да простят меня потомки).

Типовые задачи редактирования истории:

1. Отказаться от всех изменений в рабочем каталоге (аналог revert в svn).

 Кошерный способ: git checkout -f
 Отказаться от части изменений можно с помощью: git checkout <path>
 НО: git checkout . не удалит, например, вновь добавленных файлов.
 Более жёсткий способ удалить _все_ изменения: git reset --hard HEAD

2. "Сохранить" изменения (состояние) рабочего каталога.

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

3. Отредактировать/дополнить последний коммит:

 git commit --amend
 Можно применять даже если Вам просто понадобилось переписать commit-log
 (например, Вы его "недописали" или он оказался не в той кодировке).
 Фактически при выполнении этой операции будет создан _другой_ commit 
 object, и HEAD ветки будет связан с ним. (Старый объект в репозитории
 git тоже сохранится).

4. "Отказаться" от нескольких последних коммитов в истории (в частности,

  от последнего)
 Создать новую ветку new в нужной нам точке истории и переставить на
 неё существующую:
 git checkout <id> -b new
 git branch -M <нужная нам ветка>
 Например, отказаться от последнего коммита на ветке master (если мы
 на нём находимся), можно так:
 git checkout HEAD^ -b new_master
 git branch -M master
 После первой команды мы находимся "на один коммит назад" и создали там
 новую ветку с именем new_master (текущей веткой является new_master). 
 После второй команды мы "переименовали" new_master в master, -M позволяет
 проигнорировать, что master уже есть.
 Тоже самое можно сделать одной командой:
 git reset --hard <id>
 Но это менее безопасно (см. ниже).

5. "Переставить" метки веток.

git reset [--ключ] <id>
Позволяет "передвинуть" текущий HEAD (и метку ветки) на заданный коммит.
Есть три варианта, задаваемых ключами:
--hard - "выкидывает" всё текущее состояние рабочий копии, вы оказываетесь
на коммите <id>, как будто после него ничего не было;
Т.е. это просто "перестановка ветки".
--soft - "сохраняет" изменения в рабочей копии (и в "индексе" git) и добавляет
к ним изменения из "истории" от <id> до точки, из которой мы переходим.
Более подробно см. п. "Слияние нескольких коммитов в один".
--mixed - (по умолчанию) - ведёт себя как --soft, но не изменяет состояние
"индекса" git (оно будет соответствовать коммиту <id>, на который мы
перешли) - новые и изменённые файлы не считаются "добавленными" в индекс,
т.е. в отличии от --soft для них требуется явно делать git add,
git rm, .etc
Поскольку git reset (особенно --hard), позволяет "потерять" последнее
положение ветки (т.е. оставить HEAD "непомеченным"), следует использовать
эту команду с осторожностью.

6. Слияние нескольких коммитов в один.

 Если это "последние" коммиты в истории этой ветки:
 git reset --soft <id>
 git commit -a -s [--amend]
 Первая команда позволяет "отскочить" HEAD на несколько коммитов назад, при
 этом сохранив все "изменения" этих коммитов в рабочем каталоге.
 Например, git reset --soft HEAD^^ позволит "объединить" изменения последнего
 и предпоследнего коммитов.
 Если мы хотим "добавить" к этим изменениям, изменения из коммитов с другой
 ветки, нам поможет git cherry-pick --no-commit <id>
 Эта команда "добавляет" изменения коммита в рабочий каталог и в индекс, но не
 выполняет операцию commit.

7. Удаление нескольких коммитов "внутри истории". git-rebase magic

 Например, у Вас есть история ветки:
  ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N) - ветка
 и вам захотелось удалить коммиты (N-4)-(N-2) включительно.
 Это можно сделать с помощью команды git-rebase:
 git-rebase --onto <ветка>~5 <ветка>~2 <ветка>
 Например, git-rebase --onto master~5 master~2 master
 Нотация <id>~<n> означает n-ый коммит назад, т.е. в данном случае:
  - master - (N)
  - master~2 - (N-2)
  - master~5 - (N-5)
 Смысл операции git-rebase --onto <id-newbase> <id-upstream> <id-head>:
  1) Переключиться на коммит <id-head> (== git checkout <ветка>, если
     <id-head> - это HEAD ветки)
  2) Начать новую ветку от точки <id-newbase>
  3) "Поместить" на новую ветку коммиты от <id-upstream> до <id-head>,
     не включая <id-upstream>
  4) Если <id-head> - это HEAD ветки, переставить <ветку> на то, что получилось
 В данном случае:
 От коммита (N-5) мы начинаем "применять" коммиты (N-1) и (N), и переставляем
 метку ветки, в результате чего получается "новая история":
      (N-1)'-(N)' - ветка
       /
 ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N)

8. Объединение коммита с "внутренним" коммитом в истории.

 Например, в коммите <id-src> Вы исправили ошибку в "старом исправлении" <id-dst>,
 которое было несколько коммитов назад.
 Последовательность действий:
 1) Создать новую ветку new_branch от коммита <id-dst>, который надо
    поменять (дополнить).
    git checkout <id-dst> -b new_branch
 2) Сделать cherry-pick коммита <id-src>, который вы хотите "приплюсовать" к
    внутреннему.
    git cherry-pick --no-commit <id-src>
 3) "Дополнить" последний коммит изменениями из рабочего каталога.
    git commit --amend
 4) Добавить в новую историю последовательность "правильных" коммитов:
    git rebase --onto HEAD <id-первый коммит>^  <id-последний коммит>
 5) Переставить ветку на новый HEAD
    git branch -f <имя ветки>

 Пояснения требуют два последних действия:
   git rebase в данном случае добавляет нужную последовательность коммитов 
   "в голову" новой ветки, но если <id-последний коммит> - это не HEAD
   старой ветки, то после git rebase новый HEAD не будет соответствовать
   ни какой ветке ! (так уж работает git rebase)
   Для этого требуется последняя операция, она явно переставляет ветку
   на HEAD.

 Если наше исправление было бы не закоммичено, можно было воспользоваться
 git stash и git stash apply вместо git cherry-pick.

9. Редактирование "внутреннего" коммита.

 Действия аналогичны п.8, но проще. Пусть мы находимся на ветке <имя ветки>.
 1) Извлечь коммит <id-dst>, подлежащий редактированию; ветку new_branch 
    создавать при этом не обязательно, но желательно:
    git checkout <id-dst> [-b new_branch]
 2) Исправить код, "дополнить" последний коммит изменениями из рабочего
    каталога.
    git commit -a --amend
 3) Добавить в новую историю последовательность "правильных" коммитов:
    git rebase --onto HEAD <id-dst> <имя ветки>
 4) Удалить ветку new_branch, если она была создана на шаге 1)
    git branch -D new_branch

 Специально переставлять ветку <имя ветки> в данном случае не требуется, т.к.
 в команде git rebase в п. 3) в качестве последнего аргумента было имя ветки,
 а не просто SHA1-id. В такой ситуации эта команда "автоматически" переставит
 ref ветки.

10. rebase ветки с помощью git rebase.

  git rebase <upstream-branch>
  Эта операция подробно рассмотрена в разъяснениях Никиты по идеологии и
  сценариям использования git.
  Не следует относится к git rebase "формально": например, если Вы считаете,
  что некоторые коммиты с ветки разумнее было бы переместить на master, можно
  "продублировать" их на master с помощью git cherry-pick, после чего сделать
  git rebase. После этого, с веки эти коммиты волшебным образом исчезнут.

11. "Откат" отдельного коммита.

  Строго говоря, это не редактирование истории: просто автоматически добавляется
  коммит (либо, изменение в рабочей копии), "отменяющее" заданный коммит.
  git revert [--no-commit] <id>
  Эту возможность следует использовать если Вы не хотите "честно" редактировать
  историю. Например, коммит надо откатить только на одной из ветвей, либо
  этот коммит был "очень давно", и не хочется перестраивать из-за него всю
  историю целиком.

Мини документация

Anonymous (anonymous@undisclosed.example.com) — 2017-03-21T02:30:39+00:00

scm, git

Мини документация

http://marklodato.github.io/visual-git-guide/index-ru.html?no-svg

Init

mkdir new_repo1 && cd new_repo1 && git init
mkdir new_repo1 && cd new_repo1 && git init –bare origin

Config

Global

git config –global user.name "Your Name"
git config –global user.email "your_email@whatever.com"
git config –global core.filemode false

User

git config core.bare false - Делаем из bare репозитория обычный
git config core.filemode false

Clone

git clone git@github.com/repo.git
git clone –no-hardlinks origin master
git clone –no-hardlinks ./repo1 ./repo2

Add

git add Копирует файлы (в их текущем состоянии) на сцену.
git commit Сохраняет снимок сцены в виде коммита.
git reset – Восстанавливает файлы на сцене, а именно копирует файлы из последнего коммита на сцену. Используйте эту команду для отмены изменений, внесенных командой git add файлы. Вы также можете выполнить git reset чтобы восстановить все файлы на сцене.
git checkout – Копирует файлы со сцены в рабочую директорию. Эту команду удобно использовать чтобы сбросить нежелательные изменения в рабочей директории.

Вы можете использовать git reset -p, git checkout -p, и git add -p вместо (или вместе с) именами файлов, чтобы в интерактивном режиме выбирать, какие именно изменения будут скопированы.

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

Commit

git commit -a аналогичен запуску двух команд: git add для всех файлов, которые существовали в предыдущем коммите, и git commit.
git commit Создает новый коммит, в основе которого лежат уже существующие файлы, добавляя изменения только для указанных файлов. Одновременно, указанные файлы будут скопированы на сцену.
git checkout HEAD – Копирует файлы из текущего коммита и на сцену, и в рабочую директорию.

Diff

Commit

amend (Перезаписать последний комит)

Если вы сделали ошибку в последнем коммите, её легко исправить с помощью команды git commit –amend. Эта команда создает новый коммит, родителем которого будет родитель ошибочного коммита. Старый ошибочный коммит будет отброшен, конечно же если только на него не будет ещё каких-либо других ссылок, что маловероятно.

Checkout

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

Когда вы указываете имя файла (и/или ключ -p), git копирует эти файлы из указанного коммита на сцену и в рабочую директорию. Например, git checkout HEAD~ foo.c копирует файл foo.c из коммита HEAD~ (предка текущего коммита) в рабочу директорию и на сцену. Если имя коммита не указано, то файл будет скопирован со сцены в рабочую директорию. Обратите внимание на то что при выполнении команды git checkout HEAD~ foo.c позиция указателя текущей ветки (HEAD) остаётся прежней, указатель никуда не перемещается.

В том случае если мы не указываем имя файла, но указываем имя (локальной) ветки, то указатель HEAD будет перемещен на эту ветку (мы переключимся на эту ветку). При этом сцена и рабочая директория будут приведены в соответствие с этим коммитом. Любой файл, который присутствует в новом коммите (a47c3 ниже) будет скопирован из истории; любой файл, который был в старом коммите (ed489), но отсутствует в новом, будет удален; любой файл, который не записан ни в одном коммите, будет проигнорирован.

В том случае, если мы не указываем имя файла, и не указываем имя (локальной) ветки, а указываем тег, дистанционную (remote) ветку, SHA-1 хеш коммита или что-то вроде master~3, то мы получаем безымянную ветку, называемую «Detached HEAD» (оторванная голова). Это очень полезная штука, если нам надо осмотреться в истории коммитов. К примеру, вам захочется скомпилировать git версии 1.6.6.1. Вы можете набрать git checkout v1.6.6.1 (это тег, не ветка), скомпилировать, установить, а затем вернуться в другую ветку, скажем git checkout master. Тем не менее, коммиты из состояния «Detached HEAD» происходят по своим особым важным правилам

Коммит из состояния «Detached HEAD»

Когда мы находимся в состоянии оторванной головы (Detached HEAD), коммит совершается по тем же правилам, что и обычно за исключением одной маленькой особенности: ни один указатель ветки не будет изменен или добавлен к новому коммиту. Вы можете представить эту ситуацию как работу с анонимной веткой.

Если после такого коммита вы переключитесь в ветку master, то коммит 2eecb, совершенный из состояния «Detached HEAD» потеряется и попросту будет уничтожен очередной сборкой мусора только потому нет ни одного объекта, который бы на него ссылался: ни ветки, ни тега.

В том случае, если вы хотите сохранить этот коммит на будущее, вы можете создать на основе его новую ветку командой git checkout -b new.

Reset

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

Если коммит указан без имен файлов, указатель ветки будет перемещен на этот коммит, а затем сцена приведется в соответствие с этим коммитом. Если мы используем ключ –soft, то сцена не будет изменена. Если мы используем ключ –hard, то будет обновлена и сцена, и рабочая директория.

Если имя коммита не будет указано, по умолчанию оно будет HEAD. В этом случае указатель ветки не будет перемещен, но сцена (а также и рабочая директория, если был использован ключ –hard) будут приведены к состоянию последнего коммита.

<fc #008080>Если в команде указано имя файла (и/или ключ -p), то команда работает также как checkout с именем файла</fc>, за исключением того, что только сцена (но не рабочая директория) будет изменена. Если вы подставите имя коммита на место двойной черты, вы сможете получить состояние файла из этого коммита, тогда как в случае с двойной чертой вы получите состояние файла из коммита, на который указывает HEAD.

Checkout VS Reset

Merge

Команда merge (слияние) создает новый коммит на основе текущего коммита, применяя изменения других коммитов. Перед слиянием сцена должна быть приведена в соответствие с текущим коммитом. Самый простой случай слияния — это когда другой коммит является предком текущего коммита: в этом случае ничего не происходит. Другой простой случай слияния — когда текущий коммит является предком другого коммита: в этом случае происходит быстрая перемотка (fast-forward). Ссылка текущей ветки будет просто перемещена на новый коммит, а сцена и рабочая директория будут приведены в соответствие с новым коммитом.

Во всех других случаях выполняется «настоящее» слияние. Вы можете изменить стратегию слияния, но по умолчанию будет выполнено «рекурсивное» слияние, для которого будет взят текущий коммит (ed489 ниже на схеме), другой коммит (33104) и их общий предок (b325c); и для этих трех коммитов будет выполнено трехстороннее слияние. Результат этого слияние будет записан в рабочую директорию и на сцену, и будет добавлен результирующий коммит со вторым родителем (33104).

Cherry Pick

Команда cherry-pick («вишенка в тортике») создает новый коммит на основе только одного сладкого «коммита-вишенки», применив все его изменения и сообщение.

Rebase

Если находясь в ветке master выполнить git merge next, мы получим историю изменений раздваивающуюся после коммита на 2 ветви и заканчивающуюся автоматическим слиянием веток, родителями этого merge-коммита будут ревизии C (из master’а) и F (из бранча next). Избежать подобной ветвистости помогает волшебная команда git rebase.

Перебазирование (rebase) — это альтернатива слиянию для задач объединения нескольких веток. Если слияние создает новый коммит с двумя родителями, оставляя нелинейную историю, то перебазирование применяет все коммиты один за одним из одной ветки в другую, оставляя за собой линейную историю коммитов. По сути это автоматическое выполнение нескольких команд cherry-pick подряд.

На схеме выше вы видите как команда берет все коммиты, которые есть в ветке topic, но отсутствуют в ветке master (коммиты 169a6 and 2c33a), и воспроизводит их в ветке master. Затем указатель ветки перемещается на новое место. Следует заметить, что старые коммиты будут уничтожены сборщиком мусора, если на них уже ничего не будет ссылаться.

Используйте ключ –onto чтобы ограничить глубину захвата объединяемой ветки. На следующей схеме вы можете увидеть как в ветку master приходят лишь последние коммиты из текущей ветки, а именно коммиты после (но не включая) 169a6, т. е. 2c33a.

Есть также интерактивный режим перебазирования git rebase –interactive, с помощью которого вы сможете сделать вещи похитрее простого линейного применения коммитов, а именно сбрасывание (dropping), изменение порядка (reordering), правка (modifying) и выдавливание (squashing) коммитов. Нет наглядной схемы, чтобы показать эти возможности; за описанием лучше обратиться к справке по git-rebase(1).

Детали

Содержание файлов не хранится в индексе (.git/index) или в объектах коммитов. Правильнее было бы сказать, что каждый файл хранится в базе данных объектов (.git/objects) в двоичном представлении; найти этот файл можно по его SHA-1 хешу. В файле индекса записаны имена файлов, их хеши и дополнительная информация. В информации о коммитах вы встретите тип данных дерево, для идентификации которого также используется SHA-1 хеш. Деревья описывают директории в рабочей директории, а также содержат информацию о других деревьях и файлах в принадлежащей к обозначенному дереву. Каждый коммит хранит идентификатор своего верхнего дерева, которое содержит все файлы и другие деревья, измененные в этом коммите.

Если вы делаете коммит из состояния «оторванной головы» (detached HEAD), то на этот коммит будет ссылаться ссылка истории HEAD. Но рано или поздно время хранения этой ссылки истечет, и этот коммит будет уничтожен сборщиком мусора точно также, как это делается при выполнении команд git commit –amend и git rebase.

Равнозначные команды

git reset –hard e3f1e37 и git checkout e3f1e37
git add . && git commit -m "Comment" и git commit -am "Comment"
git checkout master~3 и git reset –hard HEAD~3

Наилучшая замена команд

git pull origin master на git pull –rebase origin master
git pull origin feature на git pull –rebase origin feature

Легенда

сцены — stage / index промежуточное состояние файлов, до создания комита
- Применяется для временного / промежуточного состояния файлов перед формированием комита.
- index — область зафиксированных изменений, т.е. всё то, что вы подготовили к сохранению в репозиторий.
repository
origin — Ссылка на внешний репозиторий

Применяется git checkout origin/master, git checkout -b test origin/test

HEAD — указатель на commit, в котором мы находимся.
master — имя ветки по-умолчанию, это тоже указатель на определённый коммит
origin — имя удалённого репозитория по умолчанию (можно дать другое)
fast-forward — Объединение веток, при котором не выполняется merge (а комиты просто складываются 1 за другим) и получила название fast-forward. Принудительное применение команды git merge –ff-only collider/terminate