и снова гит

git is Distributed Version Control System (DVCS)

Official Git Site - http://git-scm.com/

$ git help  - общий хелп

$ git help config - хелп по конкретной команде

$ git config --global user.name "Andrii Ieremenko"

$ git config --global user.email "andrew.yeremenko@gmail.com"

$ git config --global color.ui true pretty command line colors
$ git config --global core.editor emacs
$ git config --global merge.tool opendiff
Чтобы поставить настройку не глобально, а толь дла данного репозитория делаем:
$ git config core.editor emacs

$ git config --list  # увидеть поточное состояние настроек, которые ме настроили выше указанными командами
На одно поле может быть установлено несколько настроек, чтобы быть уверенным какая настройка точно испльзуется  в данном репозитории:
$ git config user.email

Эти команды редактируют файл .git/config префикс у имени это имя блока к которому относится команда.

Работа с локальным репозиторием

$ git init ## создаем локальный репозиторий

Initialized empty Git repository in /Users/coreer/store/.git/

$ git add <list of files>  ## добавить в сейджинг указанный файлы - они будут учавствовать в последующем комите

$ git add --all ## добавляет в стейджинг все новосозданные и удаленные, которые уже трекаются репозиторием

$ git add *.txt ## добавляются все текстовые файл из поточной директории в стейджинг.

$ git add docs/*.txt ## добавляются все текстовые файл из директории докс в стейджинг.

$ git add docs/ ## добавляются все текстовые файл из директории докс и всех ее поддиректорий в стейджинг.

$ git add "*.txt" ## добавляются все текстовые файлы проекта из всех дирекорий и поддиректорий в стейджинг.

$ git diff ## show unstaged differences since last commit

$ git diff --staged ## show staged differences since last commit

$ git rm --cached <file>   ## убрать из стейджинга случайно добавленный файл, если он при этом уже трекался гитом, то тогда пометить его для удаления при последующем комите, но локально с диска он не удаляется.

$ git reset HEAD <file>  ## убрать из стейджинга добавленный файл, разница с предыдущим вариантом состоит в том, что если он уже трекается, то он остается в старом виде, а не удаляется.
$ git checkout -- <file>  ## просто убрать(без возможности восстановить) незастейдженные исправления в файле
$ git commit -a -m "Message" ## добавить все уже затреканные измененные файлы в стейджинг и сразу их закомитить
Последующие команды локального репозитория можна делать только до момента загрузки обрабатываемого бранча в удаленный репозиторий.
$ git reset --soft HEAD^ ## откатить каретку поточной ветки на один комит назад, при этом изменения из последного коммита попадают опять в стейдж эриа.
$ git commit --amend [-m "New commit msg"] ## если мы потеряли какие-то изменения для последнего комита мы можем все еще добаить ему недостающее, при этом мы даже можем перезаписать сделанный коментарий
$ git reset --hard HEAD^ ## откатить каретку поточной ветки на один коммит назад, при этом изменения из последнего коммита просто потеряются
$ git reset --hard HEAD^^ ## а так мы откатимся на два коммита.

Работа с удаленным репозиторием

Чтобы определять права для юзеров на удаленном репозитории мы можем воспользоваться хостингом GitHub or BitBucket. Или же чем-то, что мы можем поставить у себя:

- Gitosis - питон утилита, которая помогает в системе навешать некие права на гитовый репозиторий, который работает как удаленный

- Gitorious - платформа для хостинга с открытым исходным кодом

- GitLab - платформа для хостинга с открытым исходным кодом с более широким функционалом

Заливка на

$ git remote add origin <url> ## связать локальный репозиторий с неким удаленным и задать этой связи имя

$ git remote -v ## вывести список все доступныз связей с удаленными репозиториями (на каждую добавленную нами связь по факту создается две - одна на сливания, другая для заливания)

$ git push -u <remotename> <localbranch> ## заливаем содержимое локального бранча на указанный репозиторий, кроме этого мы указываем с помошью ключа -u, что нужно запомнить эту заливку и все последующие без указания ремоута и бранча заливать опять сюда же.

$ git remote rm <remotename>## удалить ненужный ремоут

Загрузка с

$ git clone <url> ## сливает удаленный репозиторий на локальный диск и создает локальный репозиторий, создает ремоут origin и привязывает его к урлу, с которого был создан локальный репозиторий.

Процесс смердживания(локальный бранчей)

$ git checkout master
$ git merge cat
Fast-forward ## means that there were no commits in master after branching from it to cat. So it is easy for git to merge such branches.
$ git branch -d cat ## let's delete no needed more branch


$  git checkout -b admin ## создает из поточной бранчи новую с указанным именем и сразу переключается на нее
$ git branch cat ## создает новый бранч с указанным именем, но не переключается на него из поточного.

Если в ветке, из которой мы создали свою, произошли изменения, то наш мердж уже небудет таким простым, если все гладко, то просто выведется vi с просьбой оставить сообщение почему это мержд необходим и что мы тут делаем
Команды vi:
j - down  k - up   ESC - leave mode   :wq - save & quit
h - left     l - right  i - insert mode         :q!  - cancel & quit


$ git pull ## стягивает изменения из удаленного репозитория, и в случае если там уже были комиты после последнего комита, который мы стянули в локальный репозиторий, и мы сделали уже свои комиты в локальный репо, делается git merge <remote>/<thebranch> <thebranch>

Resolving conflicts

$ git pull
...
CONFLICT (content): Merge conflict in FILENAME.EXT
Automatic merge failed; fix conflict and then commit the result.
$ git status
# ...
# both modified:   FILENAME.EXT

$ vi FILENAME.EXT

Something the same
<<<<<<<  HEAD
Our local version
=======
Remote version
>>>>>>>
4e76d35..........{remote commit hash}

Правим руками и удаляем гитовые отметки
$ git commit -a
Открывается ви и мы видим уже перечень файлов, в которых мы решили конфликты. Отавляем + свое сообщение и сохраняем файл, что завершает коммит
$ git push

Работа с удаленными бранчами

Создание уделенной:

$ git checkout -b <new_distrib_branch> ## создать локально

$ git push origin <new_distrib_branch> ## залить на удаленный репозиторий

$ git branch -r ## list all remote branches

$ git checkout <new_distrib_branch> ## стягивается удаленная, но перед этим нужно сделать pull или fetch, чтобы обновить список удаленных бранчей в своем локальном репозитории. Отличие pull от fetch, последний обновит просто список бранчей (информацию о удаленном репозитории), а pull попытается еще и сделать мердж с подошедшей бранчей

$ git remote show origin

  * remote origin

     remote remote_some_other

     ...

     Fetch URL:

     Push URL:

     HEAD branch: master

     Remote branches:

         master      tracked

         ...

     Local branches configured for 'git pull':

         ... список локальных и с какими удаленными они связаны для мержев

     Local refs configured for 'git push':

         ... список локальных и с какими удаленными они связаны для пуша (именно это сохранил ключ -u)

$ git push origin :no_needed_anymore ## удалить удаленно бранчу, но оставить локально

удалить локальную после удаленной :
$ git branch -d no_needed_anymore ## может написать, что эта бранча не полностью смерджена, если мы все таки уверенны, что она смерджена и больше не нужно то вводим следующую команду
$ git branch -D no_needed_anymore

После этого, если кто-то другой попытается запушить ему выведется сообщение о том, что он работает только на бокальной бранче, если он введет 
$ git remote show origin
   Remote branches:
   master                                                           tracked
   refs/remotes/origin/no_needed_anymore      stale     (дает нам понять что она была удалена)
$ git remote prune origin ## чистим свой ремоут от удаленных отдаленных бранчей, больше в списке удаленных не будет


Иногда бываетнеобходимо связать свою локальную бранчу с удаленной под другим именем
Например если мы пользуемся хостингом хероку, то он деплоит только бранчи с именем master, а если мы деплоим на хостинг который является для нас стейджинго, и у нас локальная бранча так и называется стейджинг? Тогда в этом случае на этом ремоуте мастером будет то, что мы называем локально стейджингом:
$ git branch
   * staging
      master
$ git push heroku-staging staging:master  ## отправили локальную бранчу staging под именем master на ремоут heroku-staging

Работа с тегами

$ git tag ## список всех тегов

   v0.0.1

   v0.0.2

$ git checkout v0.0.1 ## переключиться на код, который представляет тег

$ gut tag -a  v0.0.3 -m "version  0.0.3" ## добавить новый тег из поточного положения каретки HEAD

$ git push --tags ## залить на удаленку теги