alex-boom · July 2, 2018 14:48
diff --git a/gitJC.txt b/gitJC.txt
 Git FAQ


 Шпаргалка по гиту и его командам: http://www.calculate-linux.ru/main/ru/git

 Общие настройки
 Выполнять всем, когда садитесь за новый компьютер. Если Вам поменяли комьютер их нужно снова выполнить. Если работаете с git на каком-то сервере под своим пользователем – то выполняем эти команды и там:


 git config --global user.email "{username}@justcoded.com" например [email protected]
 git config --global user.name "{first/last name}" например Stanislav Gurin
 git config --global core.filemode false
 git config --global color.ui auto
 Дополнительно для Linux/MacOS:

 git config --global core.autocrlf input
 Дополнительно для Windows:
 * Если у Вас компьютер c Windows, но вы работает с гитом через putty на сервере, то Вы выполняете команды для Linux!!!


 git config --global core.autocrlf true
 Где хранятся конфиги
 –global конфиг хранится в папке Вашего пользователя системы.

 Конфигурация локального репозитория хранится в файле .git/config.


 [core]
    filemode = false
 [user]
   email = ...
   name = ...

 В этом же файле указан путь в репозиторий BitBucket. Соответственно, если нужно подключится к репозиторию, который клонировал другой программист – то нужно просто убрать “{username}@” часть из пути репозитория.

 Настройки для *каждого* репозитория

 git config core.filemode false
 Слияние веток (git merge)
 Итак слияние веток (merge) – это перенос комитов (и изменений в файлах) из одной ветки в другую.

 Основные правила слияния:

 Merge можно выполнять только если у Вас нет измененных файлов (файлов, изменения которых не внесено в контроль версий. По простому – если у вас git status показывает что-то).
 Перед выполнением merge делайте git status – таким образом, вы проверяете 2 вещи:
 Вы находитесь на правильной ветке (в которую нужно внести изменения). – Это первая строка #On branch XXXXXX
 Что нет изменений неизвестных репозиторию: nothing to commit (working directory clean)
 Перед слиянием желательно убедиться что у Вас закачен последний код из удаленного репозитория. Это делает команда:


 git fetch
 # потом ввести логин/пароль
 Эта команда не меняет никаких Ваших файлов. Она просто забирает изменения из удаленного репозитория. Для внесения изменений нужно выполнить слияние!

 Команда слияния:

 git merge branch1 #копирует изменения из локальной ветки в текущую
 git merge origin/branch1 #копирует изменения из удаленной ветки (но слитой командой fetch) в текущую
 Пример:
 Вы скопировали себе главную ветку проекта (master) в ветку 23_some_task и работали в ней какое-то время над новым заданием. В тоже время Вася исправил множество багов в проекте, залил их в главную ветку и Вы хотите забрать себе обновления.

 Ваши действия:

 комит своих изменений (добиваемся состояния working directory clean)
 забираем изменения из удаленного репозитория (git fetch)
 выполняем слияние: git merge origin/master
 выполняем git status, чтобы убедится что там нет измененных файлов
 После успешного слияния Вы увидите что-то похожее:


 ...
 27 files changed, 414 insertions(+), 201 deletions(-)
 это значит все прошло успешно и у Вас теперь есть нужные изменения.

 Ошибки слияния (PANIC)
 Иногда возникает ситуация когда автоматическое сливание не заканчивает свою работу до конца.
 Причины может быть 2:

 ошибка диска
 конфликт (о нем немного позже)
 Ошибка диска обычно возникает на *nix системах, когда у Вашего пользователя нет прав записать файл физически на диск.
 (например был apache’ем создан каталог для uploads, а туда были занесены файлы в другой ветке. тогда у папки стоит владелец “www-data” и git туда не может ничего записать).

 Что происходит с репозиторием:

 Вносятся все изменения, которые получается внести.
 Информация о комитах из другой ветки еще не заносится, но поскольку файлы были изменены, то git готовит их для комита (по сути он за вас сделал git add)
 Итак чтобы распознать такой вид ошибок мы и делаем после сливания команду git status еще раз.
 Если была такого рода ошибка в статусе вы увидите много измененных файлов в разделе “to be commited“. При этом очень важно – НЕ должно быть файлов с пометкой both modified.

 Что делать:

 1. Все очень просто. Пишите:


 git reset --hard HEAD
 Эта команда отменяет merge, если в нем была ошибка.
 (На самом деле эта команда делает другую магию, но чтобы не забивать Вам голову – она отменяет обломавшийся merge)

 2. Далее нужно решить проблему с правами (“прочмодить” свой проект. Если прав не хватает (об этом Вам скажет консоль) – попросить руководство.)


 chmod 0777 -R *
 3. запустить мерж еще раз.

 Merge Conflict (Ужас, паника, слезы)
 На самом деле не стоит его бояться. Нужно понимать что такое конфликт.
 Конфликт возникает в тех местах, где система контроля версий не может решить как правильно ей внести изменения без помощи человека.

 Разберем на примере:
 Вася написал в строке 41: $a = $b + $c;
 А Петя в своей ветке написал в строке 41: $a = $b – $c;

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

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

 Что происходит при наличии конфликта:

 1. При выполнении слияния Вы увидите в консоли сообщение типа:


 Auto-merge failed.
 CONFLICT: /path/to/file/
 ....

 2. При распечатке git status, Вы увидите файлы помеченные как both modified. Это означает что этот файл был изменен в обоих ветках и он содержит конфликт. Помимо этого Вы увидите добавленные файлы для комита, которые были успешно “склеяны”.

 (как и прежде мы можем отменить ошибочный комит на этой стадии командой git reset –-hard HEAD)

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

 Как разрешить конфликт:

 На самом деле все супер просто. Самое главное правило – НЕ ИСПОЛЬЗУЙТЕ внешний интерфейс решения конфликтов (например Tortoise GIT). Обычно он делает много левых файлов, и в итоге больше запутывает Вас.

 Итак что мы все же делаем:

 git status, чтобы увидеть в каких файлах был конфликт (both modified)
 открываем файл, в котором был конфликт
 Ищем строки типа:

 >>>>>>>>>>HEAD
 кусок кода
 >>>>>>>>>>master
 кусок кода
 ===============
 Что они означают:

 Первый маркер (>>>>>>HEAD) показывает ту часть ВАШЕГО кода, которую не удалось склеить с другим кодом.
 Второй маркер (>>>>>>{branch name}) показывает начало НОВОГО кода, который был добавлен в ветке, которую вы себе заливаете
 Последний маркер (==============) означает конец конфликта
 Что делать:

 Прямо в редакторе наводите порядок – если Ваш код неправильный – заменяете его, если чужой код не совсем правильный – оставляете правильную версию.
 Вобщем в кратце – между перым маркером и конечным маркером Вы должны оставить правильный и валидный код.
 После этого маркеры удаляются.
 Добавляете измененные файлы в коммит (git add /path/to/file/filename)
 Делаете комит с пометкой, что это merge (git commit -m “Merged master in 23_some_task.”)
 Все! Поздравляю Вы разрулили свой конфликт!

 Откат изменений (git reset / git revert)
 Что делать если ошибочный комит был таки залит и попал в удаленный репозиторий

 1. Выполняем

 git reflog

 Видим что-то типа такого:

 a939286 HEAD@{0}: merge origin/master: Merge made by recursive.
 3c46f9d HEAD@{1}: commit: Debug toolbar IP filter (local network only)
 c697b40 HEAD@{2}: commit: Debug toolbar IP filter (local network only)
 daa25c6 HEAD@{3}: commit: Turn off debug mode for templates in offers
 Что это означает:
 [commit ID] [HEAD number] [commit message]

 2. Вам необходимо найти HEAD number перед неправильным.
 Например мы залили ошибочный комит в HEAD@{0}. Тогда нам нужен номер 1!

 3. Выполняем (где 1 – номер нужного комита):


 git reset --hard HEAD~1
 5. Если вы успели отправить этот комит в удаленный репозиторий, то нужно выполнить:


 git push origin HEAD --force


 Git ignore
 В системе Git можно настроить возможность автоматического игнорирования файлов. В корне проекта должен быть файл с названием .gitignore в котором описаны файлы и каталоги для игнорирования при комите. Наш корпоративный файл тут

 # install scripts
 init_wp

 # editor
 /nbproject/private/
 /nbproject/
 .project

 # composer
 composer.lock
 /vendor/
 /cms/

 # Ignore Mac DS_Store files
 .DS_Store
 ._*
 node_modules/
 bower/
 build/

 # linux backup files
 *~

 # markup
 .sass-cache
 node_modules
 *.map
 .tmp
 bower_components

 # wordpress configs and uploads
 /wp-config.php
 /.htaccess
 /wp-content/uploads/*
	Git FAQ


	Шпаргалка по гиту и его командам: http://www.calculate-linux.ru/main/ru/git

	Общие настройки
	Выполнять всем, когда садитесь за новый компьютер. Если Вам поменяли комьютер их нужно снова выполнить. Если работаете с git на каком-то сервере под своим пользователем – то выполняем эти команды и там:


	git config --global user.email "{username}@justcoded.com" например [email protected]
	git config --global user.name "{first/last name}" например Stanislav Gurin
	git config --global core.filemode false
	git config --global color.ui auto
	Дополнительно для Linux/MacOS:

	git config --global core.autocrlf input
	Дополнительно для Windows:
	* Если у Вас компьютер c Windows, но вы работает с гитом через putty на сервере, то Вы выполняете команды для Linux!!!


	git config --global core.autocrlf true
	Где хранятся конфиги
	–global конфиг хранится в папке Вашего пользователя системы.

	Конфигурация локального репозитория хранится в файле .git/config.


	[core]
	filemode = false
	[user]
	email = ...
	name = ...

	В этом же файле указан путь в репозиторий BitBucket. Соответственно, если нужно подключится к репозиторию, который клонировал другой программист – то нужно просто убрать “{username}@” часть из пути репозитория.

	Настройки для каждого репозитория

	git config core.filemode false
	Слияние веток (git merge)
	Итак слияние веток (merge) – это перенос комитов (и изменений в файлах) из одной ветки в другую.

	Основные правила слияния:

	Merge можно выполнять только если у Вас нет измененных файлов (файлов, изменения которых не внесено в контроль версий. По простому – если у вас git status показывает что-то).
	Перед выполнением merge делайте git status – таким образом, вы проверяете 2 вещи:
	Вы находитесь на правильной ветке (в которую нужно внести изменения). – Это первая строка #On branch XXXXXX
	Что нет изменений неизвестных репозиторию: nothing to commit (working directory clean)
	Перед слиянием желательно убедиться что у Вас закачен последний код из удаленного репозитория. Это делает команда:


	git fetch
	# потом ввести логин/пароль
	Эта команда не меняет никаких Ваших файлов. Она просто забирает изменения из удаленного репозитория. Для внесения изменений нужно выполнить слияние!

	Команда слияния:

	git merge branch1 #копирует изменения из локальной ветки в текущую
	git merge origin/branch1 #копирует изменения из удаленной ветки (но слитой командой fetch) в текущую
	Пример:
	Вы скопировали себе главную ветку проекта (master) в ветку 23_some_task и работали в ней какое-то время над новым заданием. В тоже время Вася исправил множество багов в проекте, залил их в главную ветку и Вы хотите забрать себе обновления.

	Ваши действия:

	комит своих изменений (добиваемся состояния working directory clean)
	забираем изменения из удаленного репозитория (git fetch)
	выполняем слияние: git merge origin/master
	выполняем git status, чтобы убедится что там нет измененных файлов
	После успешного слияния Вы увидите что-то похожее:


	...
	27 files changed, 414 insertions(+), 201 deletions(-)
	это значит все прошло успешно и у Вас теперь есть нужные изменения.

	Ошибки слияния (PANIC)
	Иногда возникает ситуация когда автоматическое сливание не заканчивает свою работу до конца.
	Причины может быть 2:

	ошибка диска
	конфликт (о нем немного позже)
	Ошибка диска обычно возникает на *nix системах, когда у Вашего пользователя нет прав записать файл физически на диск.
	(например был apache’ем создан каталог для uploads, а туда были занесены файлы в другой ветке. тогда у папки стоит владелец “www-data” и git туда не может ничего записать).

	Что происходит с репозиторием:

	Вносятся все изменения, которые получается внести.
	Информация о комитах из другой ветки еще не заносится, но поскольку файлы были изменены, то git готовит их для комита (по сути он за вас сделал git add)
	Итак чтобы распознать такой вид ошибок мы и делаем после сливания команду git status еще раз.
	Если была такого рода ошибка в статусе вы увидите много измененных файлов в разделе “to be commited“. При этом очень важно – НЕ должно быть файлов с пометкой both modified.

	Что делать:

	1. Все очень просто. Пишите:


	git reset --hard HEAD
	Эта команда отменяет merge, если в нем была ошибка.
	(На самом деле эта команда делает другую магию, но чтобы не забивать Вам голову – она отменяет обломавшийся merge)

	2. Далее нужно решить проблему с правами (“прочмодить” свой проект. Если прав не хватает (об этом Вам скажет консоль) – попросить руководство.)


	chmod 0777 -R *
	3. запустить мерж еще раз.

	Merge Conflict (Ужас, паника, слезы)
	На самом деле не стоит его бояться. Нужно понимать что такое конфликт.
	Конфликт возникает в тех местах, где система контроля версий не может решить как правильно ей внести изменения без помощи человека.

	Разберем на примере:
	Вася написал в строке 41: $a = $b + $c;
	А Петя в своей ветке написал в строке 41: $a = $b – $c;

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

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

	Что происходит при наличии конфликта:

	1. При выполнении слияния Вы увидите в консоли сообщение типа:


	Auto-merge failed.
	CONFLICT: /path/to/file/
	....

	2. При распечатке git status, Вы увидите файлы помеченные как both modified. Это означает что этот файл был изменен в обоих ветках и он содержит конфликт. Помимо этого Вы увидите добавленные файлы для комита, которые были успешно “склеяны”.

	(как и прежде мы можем отменить ошибочный комит на этой стадии командой git reset –-hard HEAD)

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

	Как разрешить конфликт:

	На самом деле все супер просто. Самое главное правило – НЕ ИСПОЛЬЗУЙТЕ внешний интерфейс решения конфликтов (например Tortoise GIT). Обычно он делает много левых файлов, и в итоге больше запутывает Вас.

	Итак что мы все же делаем:

	git status, чтобы увидеть в каких файлах был конфликт (both modified)
	открываем файл, в котором был конфликт
	Ищем строки типа:

	>>>>>>>>>>HEAD
	кусок кода
	>>>>>>>>>>master
	кусок кода
	===============
	Что они означают:

	Первый маркер (>>>>>>HEAD) показывает ту часть ВАШЕГО кода, которую не удалось склеить с другим кодом.
	Второй маркер (>>>>>>{branch name}) показывает начало НОВОГО кода, который был добавлен в ветке, которую вы себе заливаете
	Последний маркер (==============) означает конец конфликта
	Что делать:

	Прямо в редакторе наводите порядок – если Ваш код неправильный – заменяете его, если чужой код не совсем правильный – оставляете правильную версию.
	Вобщем в кратце – между перым маркером и конечным маркером Вы должны оставить правильный и валидный код.
	После этого маркеры удаляются.
	Добавляете измененные файлы в коммит (git add /path/to/file/filename)
	Делаете комит с пометкой, что это merge (git commit -m “Merged master in 23_some_task.”)
	Все! Поздравляю Вы разрулили свой конфликт!

	Откат изменений (git reset / git revert)
	Что делать если ошибочный комит был таки залит и попал в удаленный репозиторий

	1. Выполняем

	git reflog

	Видим что-то типа такого:

	a939286 HEAD@{0}: merge origin/master: Merge made by recursive.
	3c46f9d HEAD@{1}: commit: Debug toolbar IP filter (local network only)
	c697b40 HEAD@{2}: commit: Debug toolbar IP filter (local network only)
	daa25c6 HEAD@{3}: commit: Turn off debug mode for templates in offers
	Что это означает:
	[commit ID] [HEAD number] [commit message]

	2. Вам необходимо найти HEAD number перед неправильным.
	Например мы залили ошибочный комит в HEAD@{0}. Тогда нам нужен номер 1!

	3. Выполняем (где 1 – номер нужного комита):


	git reset --hard HEAD~1
	5. Если вы успели отправить этот комит в удаленный репозиторий, то нужно выполнить:


	git push origin HEAD --force


	Git ignore
	В системе Git можно настроить возможность автоматического игнорирования файлов. В корне проекта должен быть файл с названием .gitignore в котором описаны файлы и каталоги для игнорирования при комите. Наш корпоративный файл тут

	# install scripts
	init_wp

	# editor
	/nbproject/private/
	/nbproject/
	.project

	# composer
	composer.lock
	/vendor/
	/cms/

	# Ignore Mac DS_Store files
	.DS_Store
	._*
	node_modules/
	bower/
	build/

	# linux backup files
	*~

	# markup
	.sass-cache
	node_modules
	*.map
	.tmp
	bower_components

	# wordpress configs and uploads
	/wp-config.php
	/.htaccess
	/wp-content/uploads/*