git.txt

Ссылки по теме:
https://git-scm.com/book/ru/v2
___________________________________________________________________________________________________
Торвальдс саркастически отозвался о выбранном им названии git (что на английском сленге означает «мерзавец»):

I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.
(Я эгоистичный ублюдок, и поэтому называю все свои проекты в честь себя. Сначала Linux, теперь git.)
___________________________________________________________________________________________________

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

Типы СКВ:
 1. Локальные системы контроля версий
	- копировать папки :)
	- rcs (есть бд) изменения файла записываются в патч
 2. Централизованные системы контроля версий
	- Central VCS Server (CVS, Subversion и Perforce)
 3. Распределённые системы контроля версий
	- Git, Mercurial, Bazaar или Darcs

Как работает гит?
Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок (snapshot) того, 
как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, 
а делает ссылку на ранее сохранённый файл.

Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. 
Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. 
Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем.

Для создания Git-репозитория существуют два основных подхода.
1. Первый подход — импорт в Git уже существующего проекта или каталога.
2. Второй — клонирование уже существующего репозитория с сервера.

___________________________________________________________________________________________________
СОСТОЯНИЯ ФАЙЛОВ

В проектах, использующих Git, есть три части (состояния): 
1. каталог Git'а (Git directory), 
2. рабочий каталог (working directory),
	Файлы в вашем рабочем каталоге могут находиться в одном из двух состояний:
	-> tracked - отслеживаемые — это те файлы, которые были в последнем слепке состояния проекта (snapshot);
		Cостояния отслеживаеых файлов:
		1. unmodified - Зафиксированные файлы — файлы уже сохранённые в локальной базе.
		2. modified - Изменённые файлы — файлы, которые поменялись, но ещё не были зафиксированы.
		3. staged - Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.
	-> untracked - неотслеживаемые — не входили в слепок, не подготовленны к коммиту.
3. область подготовленных файлов (staging area).

Переходы между состояниями:
1. working directory - to -> staging area = add (на сцену?, stage files)
2. staging area - to -> Git directory = commit
3. working directory <- Git directory = checkout

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

Рабочий каталог — это извлечённая из базы копия определённой версии проекта. 
Эти файлы достаются из сжатой базы данных в каталоге Git'а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git'а, который содержит информацию о том,
что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом
называть его областью подготовленных файлов (staging area).

___________________________________________________________________________________________________
BRANCH

Ветка в Git'е — это просто легковесный подвижный указатель на один из коммитов. 
При каждом новом коммите он сдвигается вперёд автоматически.
Что произойдёт, если вы создадите новую ветку? Итак, этим вы создадите новый указатель, который можно будет перемещать.

Откуда Git узнает, на какой ветке вы находитесь в данный момент?
Он хранит специальный указатель, который называется HEAD (верхушка).
Это указатель на локальную ветку, на которой вы находитесь. 

Однако, прежде чем переключится на другую ветку, учтите, что если в вашем рабочем каталоге или индексе имеются 
незафиксированные изменения, которые конфликтуют с веткой, на которую вы переходите, Git не позволит переключить ветки. 
Лучше всего при переключении веток иметь чистое рабочее состояние. 
Существует несколько способов добиться этого:
	прятанье (stash) работы и
	правка (amend) коммита

Перемотка (fast forward) - процесс перемещения указателя родителя к коммиту дочерней ветки.

  a---b---c---d
  ^	      ^
  |	      |
master	   branch1

$ git merge branch1

  a---b---c---d
  	      ^
  	      |
	   branch1
	      ^
	      |
	    masters
___________________________________________________________________________________________________


 __________________________
| Установить пользователя: |
|__________________________|

	$ git config --global user.name "John Doe"
	$ git config --global user.email johndoe@example.com
	$ git config --global core.editor	// установить редактор по-умолчанию

 ____________________
| Проверка настроек: |
|____________________|

	$ git config --list

 _____________
| Информация: |
|_____________|

	$ git help <команда>			// как пользоваться коммандой?
	$ git status 				// узнать в каком состоянии находятся файлы
	$ git diff				/* даёт более развернутутю информацию (о том, чего нет в стэйдж, 
						 * непроиндексированные изменения)
						 */
	$ git diff --staged			/* даёт более развернутутю информацию (о том, что в стэйдж, 
						 * проиндексированные изменения)
						 */
		   --cached			// тоже, что и предудущая команда (появилась в раньше, по версиям)
	$ git show [что-то]			// часто может показать что интересное (инфа о последнем коммите, метке, remote)

	$ git log				// мощная команда для просмотра истории коммитов
	$ git log -p -2				// -p показывает разницу, которую внёс коммит -'n' размер списка, здесь два (-2)
	$ git log --since=2.weeks		// комиты за последние две недели
	$ git log --pretty=oneline		// каждый коммит в одну строку (удобно просмотреть большой список)
	$ git log --stat			/* выводит под каждым коммитом список изменённых файлов,
						 * количество изменённых файлов, а также количество добавленных и удалённых строк
						 * в этих файлах.
						 */ 
					
	$ git log --pretty=format:"%h - %an, %ar : %s"  // Свой формат вывода логов:
	 _______________________________________________________________________
	| Параметр |	Описание выводимых данных				|
	|----------|------------------------------------------------------------|
	| %H	   |	Хеш коммита						|
	| %h	   |	Сокращённый хеш коммита					|
	| %T	   |	Хеш дерева						|
	| %t	   |	Сокращённый хеш дерева					|
	| %P	   |	Хеши родительских коммитов				|
	| %p	   |	Сокращённые хеши родительских коммитов			|
	| %an	   |	Имя автора						|
	| %ae	   |	Электронная почта автора				|
	| %ad	   |	Дата автора (формат соответствует параметру --date=)	|
	| %ar	   |	Дата автора, относительная (пр. "2 мес. назад")		|
	| %cn	   |	Имя коммитера						|
	| %ce	   |	Электронная почта коммитера				|
	| %cd	   |	Дата коммитера						|
	| %cr	   |	Дата коммитера, относительная				|
	| %s	   |	Комментарий						|
	|__________|____________________________________________________________|

	$ git log --pretty=format:"%h %s" --graph // покажет ASCII граф
	$ git log --pretty=oneline --graph	  // покажет ASCII граф

 _________________________________________
| Работа в рамках локального репозитория: |
|_________________________________________|

	$ git init 				  // создать подкатолог .git

	$ git add .				  /* добавить файлы в staging area (добавить под версионный контроль, проиндексировать)	
						   *
						   * Ситуация:
						   * есть файл, мы делаем add, затем вносим изменения в этот файл. Делаем commit.
						   * В репозиторий попадет неизмененная версия файла, та, над которой сделали add
						   */
	$ git reset HEAD <файл>			  // отменить индексацию файла

	$ git rm -f <имя файла>			  // удалить файл, если он проиндексирован, этот файл будет удален и не попадет в комит
	$ git rm --cached <имя файла>		  // удалить файл из индекса на оставить на веннике
	$ git mv <имя файла old> <имя файла new>  // будто переместить, но часто используем для переименования
		
	$ git commit -m 'текст коммита'		  // переместить файлы из staging area в working directory
	$ git commit -a -m 'текст коммита'	  // флаг -a подволяет пропустить этап индексации (не надо делать git add)
	$ git commit				  // будет использован редактор (а там вывод из git status)

	$ git commit --amend			  // заменяет предыдущий коммит (например мы проиндексировали что-то ещё)
	$ git commit --amend -m 'new text'	  // заменить коммент к последнему комиту

 	$ git checkout -- <файл>		  /* до add, можно откатить изменения в файле к последнему коммиту
						   * это то что я всегда хотел научится делать !!! :)
						   */
 ____________________________________
| Работа с удалёнными репозиториями: |
|____________________________________|
	
	локальный   ---(push)---------> удаленный
	репозиторий <---------(pull)--- репозиторий

	$ git remote rename [old name] [new name]  // переименовать ссылку на удал. сервер (репозиторий)
	$ git remote rename pb paul

	$ git remote add [сокращение] [url]	   // добавить ссылку на удалённый репозиторий				
	$ git remote add origin git@gitlab.com:Yaraslau_Khamenka/synopsis.git
	$ git remote add serverName [url]

	$ git remote rm paul			   // удалить ссылку на удалённый репозиторий

	$ git remote				   // какие серверы настроены?
	$ git remote -v				   // посмотреть URL серверов
	$ git remote show [удал. сервер]	   // можно получить много полезной информации
	$ git remote show origin		   // пример ^


	$ git clone [url или SSH]		   /* Загрузить удалённый репозиторий по SSH git@gitlab.com:YK/synopsis.git
						    *
						    * Каждая версия каждого файла из истории проекта забирается (pulled) с сервера,
						    * когда вы выполняете git clone. Фактически, если серверный диск выйдет из строя,
						    * вы можете использовать любой из клонов на любом из клиентов, для того 
						    * чтобы вернуть сервер в то состояние, в котором он находился
						    * в момент клонирования. 
						    * Автоматически настраивает вашу локальную ветку master на отслеживание 
						    * удалённой ветки master на сервере, с которого вы клонировали.
						    * Теперь можно просто сделать git pull для синхронизации.
						    */



	$ git fetch [имя удал. сервера]		   /* Данная команда связывается с указанным удалённым проектом и забирает все те 
	$ git fetch origin			    * данные проекта,которых у вас ещё нет. После того как мы выполнили команду, 
						    * у нас должны появиться ссылки на все ветки из этого удалённого проекта. 
						    * Теперь эти ветки в любой момент могут быть просмотрены или слиты.
						    *
						    * Иными словами: эта команда ищет, какому серверу соответствует origin; 
						    * извлекает оттуда все данные, которых у вас ещё нет, и обновляет ваше 
						    * локальное хранилище данных + сдвигает указатель origin/master на новую позицию 
						    */ 

	$ git pull 				   /* Автоматически извлекает и затем сливает данные из удалённой ветки в вашу 
						    * текущую ветку. Выполнение git pull, как правило, извлекает (fetch) данные
						    * с сервера, с которого вы изначально склонировали, и автоматически пытается 
						    * слить (merge) их с кодом, над которым вы в данный момент 
						    * 
						    * pull = fetch + merge
						    */

	$ git push [удал. сервер] [ветка]	    // залить обновление на сервер
	$ git push origin master		    // пример ^

 ___________________
| Работа с метками: |
|___________________|

Какие метки есть?
 1. Легковесная метка — это что-то весьма похожее на ветку, которая не меняется — это просто указатель на определённый коммит. 
 2. Аннотированные метки хранятся в базе данных Git'а как полноценные объекты. Они имеют контрольную сумму, содержат
    имя поставившего метку, e-mail и дату, имеют комментарий и могут быть подписаны и проверены с помощью GNU Privacy Guard (GPG).
Вторые используются чаще (больше информации).

По умолчанию, команда git push не отправляет метки на удалённые серверы. Но при этом они прекрасно пулятся.

	$ git tag					// просмотреть имеющиеся метки (в алфавитном порядке)
	$ git tag -l 'v1.4.2.*'				// просмотр меток по маске

	$ git tag -a [имя метки] -m [коммент]		// создание метки
	$ git tag -a v1.4 -m 'my version 1.4'		// пример ^
	$ git tag -a v1.2 -m 'version 1.2' 9fceb02      // поставить метку постфактум (добавь контрольную сумму коммита)

	$ git push origin --tags			// метки необходимо отправлять явно

 _________
| Алиасы: |
|_________|

	$ git config --global alias.co checkout		/* так можно добавить алиасы для быстрого набора!
	$ git config --global alias.br branch		 *
	$ git config --global alias.ci commit		 * теперь вместо 'git commit' можно набрать 'git ci'
	$ git config --global alias.st status		 *
							 *
	$ git config --global  				 * теперь следующие две команды эквивалентны:
			alias.unstage 'reset HEAD --'	 *   $ git unstage fileA
							 *   $ git reset HEAD fileA
							 *
	$ git config --global alias.last 'log -1 HEAD'	 * посмотреть последний коммит: git last 
							 */
	
 _________
| BRANCH: |
|_________|		
	
	$ git branch [имя ветки]			/* Cоздать новую ветку = создать новый указатель на коммит 
							 * (имя указателя = имя ветки) после создания ветки мы всё ещё находимся 
							 * на той ветке из которой создали новую, то есть наш указатель HEAD, 
							 * где был там и остаётся.
							 */

	$ git checkout [имя ветки]			/* Перейти на новую ветку = переместить указатель HEAD на новую ветку
							 *
							 * Однако, прежде чем сделать это, учтите, что если в вашем рабочем каталоге
							 * или индексе имеются незафиксированные изменения, которые конфликтуют с
							 * веткой, на которую вы переходите, Git не позволит переключить ветки.
							 */ 
							
	$ git checkout -b [имя ветки]			// создать и перейти (это комбо из двух комманд выше)

	$ git merge [имя ветки]				/* Слить ветки (в ветку в которой мы находимся добавить изменения из той 
							 * ветки, которую мы указали)
							 */

	$ git branch -d [имя ветки]			// Удалить ветку
	$ git push [имя удал. сервера] :[имя ветки]	// Удалить удалённую ветку
	$ git push origin :notMaster

	$ git branch					// Информация о том, какие ветки есть
	$ git branch -v					// посмотреть последний коммит на каждой ветке
	$ git branch --merged				/* посмотреть какие ветки уже слили
							 * все ветки из этого списка, перед которыми нет *-ки можно удалить без потерь
							 */
	$ git branch --no-merged			// посмотреть какие ветки ещё не слили

	$ git config merge.conflictstyle diff3		/* Установить настройку, при которой видны не только точки HEAD сливаемых 
							 * веток, но и точка предка
							 */

	$ git rebase master				/* находясь в ветке [имя ветки]	перемещаемся в ветку master
							 * так, будто бы мы работали на этих ветках не параллельно а последовательно.
							 */

	Графическое Слияние (GUI Merging)...

	$
	$
	$