Git, часть 2 — конфигурация, возможности и работа

Git, часть 2 — конфигурация, возможности и работа

Ранее уже я писал вводную статью по системе контроля версий — GIT (Работа с Git, часть1 – Введение). На этот раз будет продолжение. И в этой статье сделаю более расширенный обзор. Время идет, и я тоже кое что успел на практике закрепить, по этому я расширю те вопросы, которые были затронуты не столь глубоко в моей предыдущей статье.

Некоторые знакомые и пользователи просили написать детальней про GIT и как им пользоваться. Жаловались что много статей но из них мало что поняли… Попробую теперь и я в этой статье объяснить по своему, простым языком… Надеюсь все таки это вам хоть что-то да прояснит.

Итак, что нужно сделать… Для того что бы можно было начать работать с системой контроля версий git достаточно создать конфигурационные файлы(если ранее их не было) и инициализировать рабочую директорию. Инициализация делается в директории где находится проект, который нужно поместить в контроль версий. Что же касается очереди действий, то желательно сперва создать пользовательский конфигурационный файл, и только после этого делать инициализацию в рабой директории, хотя и не обязательно в такой очерёдности, просто желательно.

В этой статье я углублюсь в создание конфигурационного файла, установок, некоторых удобств и попробую рассказать как можно оперировать командами: init, add, rm, mv, commit, status, log, diff, blame, branch, stash, …

Забегая на перед: следующая часть планируется по слияниям версий (мержингу) и около мержинговых тем ($ git merge & etc)…

Ну а теперь ознакомьтесь с тем что я для вас приготовил:

Для общего понимания, имеет смысл сказать что git реагирует на 3 типа конфиг-файлов:

—system — это установки для всего гита в дистрибутиве (или ОС), общие для всех .git репозитариев любого пользователя

—global — это пользовательские установки, общие для всех .git репозитариев пользователя

—local — это локальные установки для каждого .git репозитария

От сюда логично вытекает следствие что вы можете гибко конфигурировать, однако на практике обычно ограничиваются конфиг-файлами типа —global и —local,в то время  как —system используют крайне редко. Таким образом очевидно что локальные перекрывают глобальные, а те в свою очередь системные. Но, все в ваших руках. ;)

Естественно нужно установить git

$ sudo aptitude install git-core bash_completion

И еще полезно настроить свой Bash completion:

$ cp /opt/local/etc/bash_completion.d/git ~/.git-bash-completion.sh

$ echo «[ -f ~/.git-bash-completion.sh ] && . ~/.git-bash-completion.sh» >> ~/.bash_profile

$ . ~/.bash_profile

 

Теперь нам нужно создать конфигурационный файл

$ touch ~/.gitconfig

Ну и заполнить его… Во первых сделать это можно средствами командной строки:

$ git config —global user.name «Your Name Comes Here»

$ git config —global user.email you@yourdomain.example.com

$ git config —global color.branch auto

$ git config —global color.diff auto

$ git config —global color.interactive auto

$ git config —global color.status auto

$ git config —global alias.st status

$ git config —global alias.ci commit

$ git config —global alias.co checkout

$ git config —global alias.br branch

$ git config —global core.editor «mcedit»

$ git config —global merge.tool opendiff

 

В результате после всех этих команд создастся конфигурационный файл ~/.gitconfig с соответствующим содержимым.

Так же нужно ещё указать файл ~/.gitignore в котором будут указаны игнорируемые для git типы файлов. Добавим в наш пользовательский конфиг и это:

$ git config —global core.excludesfile ~/.gitignore

Его мы заполним в статье, чуть позже…

 

Конфигурационный файл можно сразу создавать в текстовом редакторе. Вот приблизительно так должен выглядеть ваш конфиг:

[core]
 #ignorecase = true
 excludesfile = /home/stas/.gitignore

[user]
 name = "Stanislav Prykhodko"
 email = "stas@***mail***.com"

[color]
 status = auto
 branch = auto
 ui = true

#[http]
#proxy = http://login:password@our-proxy-server:8088
#proxy = http://domain\\login:password@our-proxy-server:8088

[alias]
 st = status
 ci = commit
 my-status = status -s -b
 my-log = log --pretty=format:'%h - %s' --graph

При необходимости просмотреть конфиг, не обязательно лезть и искать файл конфига, можно воспользоваться командой

$ git config --list

Под собственные нужды можете указать собственный шрифт в конфиг-файле программы просмотра gitk

set mainfont {Monaco 12} set textfont {Monaco 12} set uifont {Monaco 12}

 

Теперь нужно создать игнор-файл и заполнить его контентом игнорируемых типов файлов, в котором будет указано какие файлы или директории не нужно помещать в контроль версий.

$ touch  ~/.gitignore

Заполнить следующим содержимым или под свои нужны

# Compiled source
# ###################
*.apk
*.com
*.class
*.dll
*.exe
*.o
*.so
*.dex

# Packages #
############
 # it's better to unpack these files and commit the raw source
 # git has its own built in compression methods
 *.7z
 *.dmg
 *.gz
 *.iso
 *.jar
 *.rar
 *.tar
 *.zip
# Logs and databases #
######################
 *.log
 *.sql
 *.sqlite
# OS generated files #
######################
 .DS_Store*
 ehthumbs.db
 Icon?
 Thumbs.db 

В принципе на этом можно считать наш тюнинг законценным. Однако конкретно в вашем случае этого может оказаться недостаточным, так как вдруг у вас какая специфика… тьфу-тьфу-тьфу… ;)

Подходим к использованию, команды: init, add, rm, mv, commit, status, log, diff, blame, branch, stash, …

 

Инициализация

Теперь приступаем к инициализации.

Тут все в точности как описывалось ранее в статье ранее. По этому если вы этого еще не знаете, и что бы не повторяться сможете прочитать по ссылке — Работа с Git, часть1 – Введение.

 

Добавление файлов

$ git add ./dir/Provider.cpp

Точно также как было сделано add делаются и другие команды с сопутствующим смыслом:

$ git add file
$ git rm file
$ git mv file

Вывод текущего статуса или состояний

$ git status

Тут словно как в песне — «Следи за собой, будь осторожен». Смотреть статус своих изменений необходимо перед каждым коммитом (перед командой $ git commit ).

Это не только хороший тон, но и безопасность ваших изменений, а то такого натворите… Как только вы запросите статус, вы получите информацию о всех изменённых файлах, тех что не попали в контроль или были удалены.

 

Вывод логов, информации о версиях

Красивый и форматированный вывод логов

$ git log —pretty=format:»%h %ad | %s%d [%an]» —graph —date=short

$ git log —pretty=oneline —graph
$ git log —graph -w

$ git log —stat — Выводит общую статистику по каждому коммиту

Графические программы для просмотра логов изменений

qgit, gitg, gitk, …

Просмотр отдельных комитов

git show —name-only — позволят просмотреть отдельные комиты

$ git show —name-only 6572f7bc
commit 6572f7bce47c6791abbc504a94cbbf17e851165e
Author: Stanislav Prykhodko <stas@***mail***.com>
Date:   Mon Feb 13 13:13:26 2012 +0200
Version 1.1.8: incorrect count of event a few days
Version 1.1.8 — main changes: incorrect count of event on current day
Signed-off-by: Stanislav Prykhodko <stanislavp@2kgproup.com>
AndroidManifest.xml
Doxyfile
src/com/alarmspider/organizer/Test.java

git show 34b99c2dd23 — позволят просмотреть произвольный комиты

Различия между версиями

$ git diff — проверить изменения, полезнейшая команда, можно проверять отличия от того что было с тем что в данный момент, или между произвольными версиями или каммитами…
$ git diff
$ git diff HEAD
$ git diff ^HEAD
$ git diff a348cc99..34a56d456 — различия между произвольными коммитами с короткой формой записи
$ git diff 0c31ff9eb26af76340920bce29865ffd2b11cbf1 a4e3b3439e4878c1b2c0597fabf02ad284582d26 — различия между произвольными коммитами с полной формой записи
$ git diff 0c31ff9eb26af76340920bce29865ffd2b11cbf1..38d47782e9c5a5b47aab39bbd04acb1f83349a28 — различия между произвольными коммитами с полной формой записи

Работа с бранчем, создание нового и удаление

$ git branch —  просмотр списка всех бранчей

$ git branch -a —  просмотр списка всех бранчей


$ git checkout -b WakeUp — создание бранча

$ git branch -D WakeUp — удаление бранча

Использование необходимой версии по его ID

$ git checkout 38d407782e9
$ git checkout  db5159eb2c294ae1f4812f42b55843696a306a3c
$ git checkout 38d407782e9c5a5b47aab39bbd04acb1f83349a2

Оперирование изменениями между бранчами

$ git stash — замечательная команда, предназначенная для переноса незакоммиченых изменений в буфер и забор её оттуда через git stash pop, вот наглядный пример.
$ git status — проверили что есть какие то изменения
$ git stash — переместили изменения в виртуальный буфер
$ git checkout -b fix_something — создали нудный нам новый бранч
$ git stash pop — вставили из бужера в новый бранч (уже они будут в fix_something)
$ git status — проверили что все изменения отобразились в статусе
$ git commit -as -m»Add same fix» — Закоммитили изменения в контроль fix_something

Получить последнюю версию файла

$ git fetch $ git fetch ./Makefile

Обнулить изменения версии файла или определенному коммита

$ git reset —hard file.txt
$ git reset —hard HEAD~2
$ git reset —hard libs/utils/Android.mk

 

Откатить изменения

$ git revert 20d0fa2c2a9bad57cf63207802a6c1097246d1d7

 

Переназначить верхушку для изменений

$ git rebase -i HEAD~2

 

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

$ git blame Test.java - показывает полную версию


^dc06f64 (Stanislav Prykhodko 2012-02-01 15:22:32 +0200    4) import java.util.Calendar;
^dc06f64 (Stanislav Prykhodko 2012-02-01 15:22:32 +0200    5) import java.util.List;
^dc06f64 (Stanislav Prykhodko 2012-02-01 15:22:32 +0200   6) import java.util.Locale;

А также можно посмотреть сокращенную версию

$ git blame ./Test.java -s - показывает сокращенную версию


^dc06f64    4) import java.util.Calendar;
^dc06f64    5) import java.util.List;
^dc06f64   6) import java.util.Locale;

Внесение изменений в контроль

$ git commit -as — закоммитить изменения и подписать
$ git commit -as —amend — закоммитить изменения и изменить информационное поле коммита и подписать текущего соммита
$ git commit -a —amend HEAD^1 — закоммитить изменения и изменить информационное поле коммита и подписать произвольного соммита

 

Создать patch-file

$ git format-patch -2 - тут 2 последних коммита берутся для создания патча.

Имя патча будет такое же как у коммита, для примера будет дано название — UpdateStatStucture. На выходе патч будет назван: UpdateStatStucture.patch

 

Принять patch-file

$ git apply patch

 

Загрузить последнюю версию с репозитария в рабочую директорию

$ git fetch ssh://username@android.host.com:23456/platform/system/core refs/changes/03/3003/1 && git checkout FETCH_HEAD

 

Загрузить последнюю версию с рабочей директории в удаленный репозитарий

$ git push ssh://username@android.host.com:23456/platform/system/core HEAD:refs/for/p-brand-mr2-release

 

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