Работаем с Git, основные команды для начинающих

Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:

    $ git config –global user.name "firstName  lastName"
$ git config –global user.email "email@mail.ru"

Превратим наш проект в репозиторий git. Для начала просто создайте папку git_site, затем введите следующие команды:

    $ mkdir git_site
$ cd git_site
$ git_init 

Где mkdir - команда для создания новых каталогов;
cd - переход в указанную папку; команда cd используется для смены текущего каталога.
   cd .. на уровень выше
   cd \ в корень текущего диска
   d: перейти на диск D
   cd c:\windows перейти в каталог windows

После инициализации каталога будет выведено соответствующее сообщение:

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

$ git add

Далее в наш каталог (git_site) можно поместить файлы сайта. Скопируем файлы сайта в папку git_site. Далее, давайте добавим файлы в репозиторий.

Для этого понадобится выполнить команду:

    $ git add 

$ git status

Команда $ git status позволяет отследить состояние репозитория. Эта команда позволяет узнать, какие изменения необходимо зарегистрировать git (при необходимости, отменить).

$ git commit –a , $ git commit –am "...", $ git commit –a –m "..."

Чтобы зарегистрировать добавление вышеприведенных файлов необходимо выполнить следующую команду:

    $ git commit –a –m "add files"

–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.

Подтверждение с описанием выполненных действий.

Мы сделали "снимок кода". Теперь мы можем редактировать файлы и регистрировать наши изменения.

$ git stash

Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно. Для таких случае существует команда stash. Команда stash позволит сохранить изменения, не регистрируя их. Например:

    $ git stash

$ git stash list

Чтобы просмотреть все сохраненные, но не зарегистрированные изменения понадобится следующая команда:

    $ git stash list

На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.

$ git stash pop

Восстановить же изменения поможет следующая команда:

    $ git stash pop

$ git merge

Чтобы объединить ветки, например, ветку hotfix с веткой master, необходимо выполнить следующие команды:

    $ git checkout master
$ git merge hotfix

Давайте удалим ветку hotfix. Для этого воспользуемся следующей командой:

    $ git branch –d hotfix

Ветвление

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

$ git checkout –b

Чтобы создать новую ветку выполните команду:

    $ git checkout –b hotfix

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

Теперь давайте внесем изменения в файл index.html. Например, давайте подключим стилевой файл. И в самом стилевом файле увеличим размер шрифта у параграфа. Сделаем git status и зарегистрируем изменения:

    git commit –a –m "add css and change style p"

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

----------------------

git init (инициализируем git реп-й)

Чтобы проинициализировать Git репозиторий введите команду:

git init

Будет создана папка /.git/. Репозиторий - это скрытая папка, в которой работает Git.

git status (Проверяем статус)

Комнада, выводяюща статус репозитория, чтобы увидеть в каком состоянии находится наш проект:

git status

git add (добавляем файл)

Чтобы сообщить Git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью:

git add

Сейчас git отслеживает наш файл test.txt. Давайте выполним

git status

снова, чтобы понять, что изменилось!

git commit (фиксируем изменения)

Чтобы сохранить изменения на данном этапе мы выполним команду создания коммита и передадим ей в качестве аргумента сообщение, описывающие изменения, сделанные в этом коммите.

git commit -m "Add cute octocat story"

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору. В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора (для этого в редакторе по-умолчанию (Vim) вам нужно нажать клавишу ESC, ввести :wq и нажать Enter). Вы увидите ..... (http://githowto.com/ru/commiting_changes)

Используем маску

К счастью, у нас есть возможность добавить все файлы, используя шаблон. Не забывайте про кавычки!

git add "*.txt"

git commit –a –m ”new comment here”

Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).

$ git add

Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,

git commit –a –m ”new comment here”

).

--amend

git commit --amend

Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,

git commit commit -m "первый коммит"
git add some_file
git commit --amend

Второй коммит заменит результат первого и в итоге останется 1 коммит

Работаем с GitHub

Зарегистрируйтесь на GitHub. Создайте репозиторий.

Чтобы разместить наш локальный репозиторий на GitHub, мы должны добавить удаленный репозиторий.

Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git

Выполняем команду с указанными аргументами:

git remote add origin https://github.com/try-git/try_git.git

Где origin - имя удаленного репозитория.

Плюсы и минусы bitbucket.org и GitHub

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Процесс разработки:

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

$ git remote

Эта команда показывает имя удаленного репо, если такой имеется в наличии.

$ git remote –v

Ключ –v показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

$ git help name_command

Коммитим и пушим на GitHub (global настройки matching и simple)

Если мы выполнима для настройки глобального конфига следующую команду:

$ git config --global push.default matching

То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

$ git config --global push.default simple

В данном случае протолкнется лишь текущая ветка.

git remote (прсматриваем уд. реп.)

Команда git remote позволяет просмотреть удаленные репозитории

git remote -v параметр -v позволяет увидеть URL-адреса.

git remote add (добавляем уд. реп.)

Добавление удаленных репозиториев под короким именем:

git remote add [сокращенное имя] [url]

git remote add kuku [url] - теперь вместо полного URL-адреса в командную строку можно вводить имя kuku

Пример использования:

git remote add interview https://github.com/asdasd/interview.git
git pull interview master

Пример использования:

Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku

git init
git remote add kuku https://github.com/denzLLL/test.git
git fetch kuku
git pull kuku master

git remote show (получаем инфо. об уд. реп.)

Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.

git remote show [имя удал. реп.]
git remote show origin

git fetch (извлечение данных из уд. реп.)

Извлечение данных из уд. реп. выполняется командой:

git fetch [имя уд. реп.]
git fetch kuku

После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта

Получаем данные из удаленного репо, но при этом они есть лишь в папке .git, в рабочей папке их нет. Для того чтобы данные появились в рабочей папке необходимо выполнить команду:

$ git pull

git push (проталкиваем изменения)

Команда git push говорит Git, куда отправить наши изменения, когда все готово. Итак, запушим наши локальные изменения в наш удаленный репозиторий на GitHub. Имя удаленного репозитория origin, а ветка по умолчанию называется master (не думайте пока что о ветках). Параметр -u позволит нам в будущем не указывать дополнительные параметры, а просто выполнять git push. Git будет знать, что нужно делать.

git push -u origin master

где origin – это куда отправляем (удаленный репозитарий), а
master это то, что отправляем (в нашем случае master).

git pull (стягиваем изменения)

Давайте представим, что прошло какое-то время. Мы пригласили других людей в наш проект, они забрали наши изменения в свои локальные репозитории и внесли свои изменения, запушили их. Мы можем проверить изменения на GitHub и спуллить их с помощью команды:

git pull origin master

Забираем изменения из ветки (master) на удаленном сервере (origin) и проводим слияние с активной веткой.

git diff, git diff HEAD

Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда git dif --cached покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

git diff

В данном случае мы хотим получить изменения с нашего последнего коммита, ссылку на который мы можем получить с помощью указателя HEAD.

git diff HEAD

Еще один полезный вариант использования git diff - просмотр изменения, которые уже были помещены в промежуточную область. Запомните! В этой области находятся файлы, которые git готов(!) закоммитить.

git reset (Откатываем изменения/удаляем файлы из промежуточной области)

Вы можете удалять файлы из промежуточной области с помощью git reset.

git reset octofamily/octodog.txt

git log (информация о последних коммитах)

Иногда просто хочется вернуться назад и забыть все изменения до определенного момента, потому что все они были неправильными. В таком случае Для просмотра изменений (истории коммитов) используется команда

$ git log

покажет список последних коммитов и их хеши SHA1.

На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:

$ git help log

Например, мы можем выводить историю в более удобном формате:

$ git log --pretty=format:"%h - %an, %ar : %s"

%h – короткий код самого коммита;
%an – автор;
%ar – когда был сделан;
%s - комментарий.

Ограничиваем коммиты по времени:

$ git log --since=2.weeks

$ git log -p -2

-p показывает разницу, внесенную каждым коммитом. -2 ограничивает выводимый результат последними 2 записями.

--stat используется для получения краткой статистики по каждому коммиту.

--graph добавляет графику с историей ветвлений и слияний

git checkout (Отмена изменений)

Файла был удален из промежуточной области. Но сам файл все еще находится в проекте! Файлы могут быть возвращены в состояние последнего коммита с помощью команды:

git checkout -- <name_file>

Откатим octocat.txt

git checkout -- octocat.txt

git checkout 82f5

Для указания коммита достаточно первых нескольких символов его хеша (82f5), но можете скопировать и весь хеш.

git checkout (получаем уд. ветку)

Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :

git checkout -b [имя_ветки] origin/[имя_ветки]

(?) или просто git checkout [имя_ветки]; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.

git branch (создаем ветку)

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

Давайте создадим новую ветку и назовем ее clean_up:

git branch clean_up

git branch -d (удаление ветки)

Вы можете использовать команда git branch -d <branch name> для удаления ветки. Сделаем это:

git branch -d clean_up

git branch -vv (наблюдаем за уд. ветками)

Команда git branch -vv позволяет получить список всех веток, за которыми идет наблюдение (за какой веткой следит на уд. сервере и на сколько опережает соотв. ветку на уд. сервере).

git branch -vv
  master 99a07a2 [origin/master: ahead 6]
  two    9d309c4 [origin/two]
  

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

git fetch --all
git branch -vv

git rm (удаляем файлы)

Команды git rm, которая не только удалит файлы с диска, но и добавит сведения об их удалении в Git.

git rm '*.txt'

Если вы проиндексировали файл, то следует воспользоваться параметром -f, который инициирует принудительное удаление

merge (смержим в текущую ветку другую)

Настал момент, когда вы должны смержить изменения из ветки clean_up в ветку master.

Мы уже находимся в ветке master (вы уже знаете, как в этом убедиться). Осталось только сказать Git, что мы хотим смержить в текущую ветку другую - clean_up:

git merge clean_up

git clone

$ git clone <git url>

По url создаем локальный репозиторий, склонировав удаленный, например, с gitHub. Предварительно необходимо выполнить команду git init.

То есть:

$ mkdir epicgame & cd epicgame
$ git init
$ git remote add <upstream name> <git url>
$ git clone <git url>

rejected

Если при push появляется rejected, то это говорит о том, что необходимо скачать изменения с удаленного сервере и уже затем push-ть.

Конфликты

Сообщение о конфликте:

CONFLICT (content): Merge conflict in main.js
    Automatic merge failed; fix conflicts and then commit the result.

В статусе (git st) появляется блок:

Unmerged paths:
……

То есть у нас появились файлы, которые автоматически не с merg-сь.

То есть в самом файле:

<<<<<<< HEAD
// Fry comment
=========
// Bender comment
>>>>>>> 1ea3ease3232323easasea6sase6as5eas6aseas4e

Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения (// Fry comment) или оставить строку пользователя Bender (// Bender comment).

Разные полезные команды:

Добавляем пользователя:

$ git config --global user.name “kostya”

(config – работаем с конфигом; --global – ключ для глобального конфига; user.name - имя).

$ git config --global user.email kostya@example.ru

(задаем email глобально)

$ git config –list

(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig)

Игнорирование файлов:

На одном уровне с папкой .git создаем текстовый документ: .gitignore (убираем разрешение .txt, то есть сохраняем с All types(.) в Notepad++).

В самом файле указываем игнорирование, например:

# folder logs
logs/
# txt-files
docs/*.txt

$ git rm

$ git rm --cached name_file.txt

Файл name_file.txt станет обратно (untracked; от track - следить), то есть вернется в состояние перед командой git add.

СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ

Без ключа –m откроется редактор vim (:x – означает сохранить и выйти).

Поменяем редактрор по умолчанию (vim), он будет открываться в том случае, если мы не прописываем комментарий в командной строке.

$ git config --global core.editor "'H:\Sublime Text 3\sublime_text.exe' -multiInst -notabbar -nosession -noPlugin"

Изменения можно проверить в C:\Users\name_user\.gitconfig

ВЕТКИ ($ git checkout –b new_branch)

$ git checkout –b new_f

Создаем ветку new_f и тут же переходим в нее.

$ git branch –v

С использованием –v показывает ветки с последними коммитами.

merge

Чтобы избежать каких-либо недочетов сперва стоит merge-ть рабочую ветку(если она есть) с master, а уже потом на master merge-ть с рабочей (это делается для лучшего выявления конфликтов).

Указываем какой утилитой будем разрешать конфликты

$ git config --global merge.tool kdiff3

Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):

git mergetool

Но для GIT kdiff3 необходимо предварительно скачать (http://kdiff3.sourceforge.net/).

Далее потребуется запустить команду:

$ git config --global mergetool.kdiff3.cmd ‘”D:\\Program Files\\KDiff3\\kdiff3\”  $BASE $LOCAL $REMOTE –o $MERGED’

Или прописать в .gitconfig:

[mergetool "kdiff3"]
cmd = \"D:\\\\Program Files\\\\KDiff3\\\\kdiff3\"  $BASE $LOCAL $REMOTE –o $MERGED

Далее можно merge-ть (решать конфликты):

git mergetool

Далее придется удалить куче неотслеживаемых файло (БЭКАПОВ) командой (http://stackoverflow.com/questions/61212/how-do-i-remove-local-untracked-files-from-my-current-git-branch):

git clean -f

Полезные статьи (источник):

• Глава 2. GIT Базовые операции
• frontend.tech-mail.ru (GIT)
• git-scm.com/book/ru (руководство по GIT)