Полезное

Мы Вконтакте

Работа с Git

Добавлено Июл 29 2015

Если вы графический или web дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и спровоцировал проблему, кто поставил задачу и когда, и многое другое. Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо накладок. Вы можете использовать контроль версий практически для любых типов файлов. Многие люди в качестве метода контроля версий применяют копирование файлов в отдельную директорию (возможно даже директорию с отметкой по времени, если они достаточно умны). Данный подход очень распространён из-за его простоты, однако он, невероятным образом, подвержен появлению ошибок. Можно легко забыть в какой директории вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.

Статья нуждается в некоторой доработке. Учтите это при изучении.

Первый запуск Git

Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:

Код:
$ git config —global user.name «John Doe»

$ git config —global user.email johndoe@example.com

Если указана опция —global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе.

Если указана опция —global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе.

Выбор редактора

Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git’е. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Мне удобнее использовать Notepad++ установить его по умолчанию можно так:

Код:
$ git config —global core.editor «‘C:/Program Files (x86)/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin»

Естественно, что notepad++ должен быть установлен именно по этому пути: C:/Program Files (x86)/Notepad++/notepad++.exe

Создание репозитория в существующей директории

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

Код:
$ git init

Эта команда создаёт в текущей директории новую поддиректорию с именем .git, содержащую все необходимые файлы репозитория — основу Git-репозитория. На этом этапе ваш проект ещё не находится под версионным контролем.

Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первый коммит изменений. Добиться этого вы сможете запустив команду git add несколько раз, указав индексируемые файлы, а затем выполнив git commit:

Код:
$ git add *.c
$ git add LICENSE
$ git commit -m ‘initial project version’

Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.

Клонирование существующего репозитория

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

Код:
$ git clone https://github.com/libgit2/libgit2 mylibgit

В Git’е реализовано несколько транспортных протоколов, которые вы можете использовать. В предыдущем примере использовался протокол https://, вы также можете встретить git:// или user@server:path/to/repo.git, использующий протокол передачи SSH.

Команда Git status

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Предположим, вы добавили в свой проект новый файл, простой файл README. Если этого файла раньше не было, и вы выполните git status, вы увидите свой неотслеживаемый файл вот так:

Код:
$ git status

# On branch master
# Untracked files:
# (use «git add …» to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use «git add» to track)

Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status. Статус «неотслеживаемый файл», по сути, означает, что Git видит файл, отсутствующий в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите.

Отслеживание изменений

Чтобы начать отслеживать изменение в файлах используйте команду git add.

Код:
$ git add README

Для файла readme, чтобы начать отслеживать все файлы в папке используйте

Код:
$ git add –A

Если вы снова выполните команду status, то увидите, что файл README теперь отслеживаемый и индексированный:

Код:
$ git status
# On branch master
# Changes to be committed:
# (use «git reset HEAD …» to unstage)
#
# new file: README
#

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

Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы. В таком случае, вы можете создать файл .gitignore с перечислением шаблонов соответствующих таким файлам. Откройте GitBush и перейдите в папку с проектом, введите touch .gitignore это создаст gitignore.

Вот пример файла .gitignore:

Код:
$ cat .gitignore
*.[oa]
*~

Первая строка предписывает Git’у игнорировать любые файлы заканчивающиеся на .o или .a — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (~).

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

Просмотр индексированных и не индексированных изменений

Если результат работы команды git status недостаточно информативен для вас — вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff. Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:

Код:
$ git diff
diff —git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
— a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end

+ run_code(x, ‘commits 1′) do
+ git.commits.size
+ end
+
run_code(x, ‘commits 2′) do
log = git.commits(‘master’, 15)
log.size

Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff —cached. (В Git’е версии 1.6.1 и выше, вы также можете использовать git diff —staged). Эта команда сравнивает ваши индексированные изменения с последним коммитом.

Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.

Фиксация изменений

Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status, вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit:

Код:
$ git commit

Эта команда откроет выбранный вами текстовый редактор. Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы («выхлоп») команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.

Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit, указав его после параметра -m, как в следующем примере:

Код:
$ git commit -m «Story 182: Fix benchmarks for speed»

Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита (463dc4f), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

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

Игнорирование индексации

Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add:

Код:
$ git status
# On branch master
#
# Changes not staged for commit:
#
# modified: benchmarks.rb
#
$ git commit -a -m ‘added new benchmarks’
[master 83e38c7] added new benchmarks
1 files changed, 5 insertions(+), 0 deletions(-)

Обратите внимание на то, что в данном случае перед коммитом вам не нужно выполнять git add для файла benchmarks.rb.

Удаление файлов

Для того чтобы удалить файл из Git’а, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm, которая также удаляет файл из вашего рабочего каталога, так что вы в следующий раз не увидите его как “не отслеживаемый”.

Код:
$ git rm grit.gemspec

После следующего коммита файл исчезнет и больше не будет отслеживаться. Если вы изменили файл и уже проиндексировали его, вы должны использовать принудительное удаление с помощью параметра -f.

Код:
$ git rm –f grit.gemspec

Просмотр истории коммитов

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

Код:
$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700
first commit

По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке – последние коммиты находятся вверху. Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям. Посмотрим на наиболее популярные из них. Одним из наиболее полезных аргументов является -p, который показывает разницу, внесенную в каждый коммит. Так же вы можете использовать аргумент -2, который позволяет установить лимит на вывод количества коммитов.

Код:
$ git log -p -2

Если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию —stat:

Код:
$ git log —stat
Опция —stat печатает под каждым из коммитов список и количество измененных файлов, а также сколько строк в каждом из файлов было добавлено и удалено. В конце можно увидеть суммарную таблицу изменений.
Опции для ограничения вывода по времени, такие как —since и —until, являются очень удобными. Например, команда «$ git log —since=2.weeks» покажет список коммитов, сделанных за последние две недели:

Это команда работает с большим количеством форматов – вы можете указать определенную дату вида «2008-01-15″ или же относительную дату, например «2 years 1 day 3 minutes ago».

Операции отмены

В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git’а, где неверными действиями можно необратимо удалить результаты своей работы.

Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит, можно запустить commit с параметром —amend (дополнить):

Код:
$ git commit —amend

Отмена индексирования файла:

Код:
$ git reset HEAD CONTRIBUTING.md

Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md? Как можно просто «разызменить» его ? вернуть к тому виду, который был в последнем коммите (или к изначально склонированому, или еще как-то полученному в рабочий каталог)?

Код:
$ git checkout — CONTRIBUTING.md

Важно понимать, что git checkout — [file] — опасная команда. Любые изменения соответствующего файла пропадают — вы просто копируете поверх него другой файл. Ни в коем случае не используйте эту команду, если вы не убеждены, что файл вам не нужен.

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

Удаленные репозитории это версии вашего проекта, которые размещаются в интернете или где-то в сети. Чтобы добавить новый репозиторий используйте команду git remote add [shortname] [url]:

Код:
$ git remote add pb https://github.com/paulboone/ticgit

Чтобы получить список всех удаленных репозиториев существует команда git remote

Код:
$ git remote -v

pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)

Чтобы получить данные из удаленных проектов, вы можете запустить:

Код:
$ git fetch [remote-name]

Команда тянет из удаленной ветки все данные, которые у вас еще нет. Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch).

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Выполнение git pull, как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: git push [удал. сервер] [ветка]. Чтобы отправить вашу ветку master на сервер origin. Вы можете выполнить следующую команду для отправки наработок на сервер:

Код:
$ git push origin master

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push.

Удаление и переименование удалённых репозиториев

Для переименования ссылок в новых версиях Git’а можно вылолнить git remote rename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul, вы можете сделать это следующим образом:

Код:
$ git remote rename pb paul
$ git remote
origin
paul

Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm:

Код:
$ git remote rm paul
$ git remote
origin

Bitbucket

В качестве средства для совместной разработки я использую «Ведро битов». В отличии от Github, он позволяет создавать неограниченное количество репозиториев как открытых, так и приватных. Бесплатно над проектом может работать до пяти человек. Первое что нужно сделать это создать rsa ключ для доступа к репозиторию (https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git)

Git оболочка уже поставляется с клиентом SSH. Откройте Git Bash и выполните следующие действия, чтобы проверить установку:

Код:
ssh –v

$ ssh -v
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]

Проверьте содержимое ~/.ssh папки

Код:
$ ls -a ~/.ssh
ls: /c/Users/manthony/.ssh: No such file or directory

Если у вас уже есть идентификатор по умолчанию, вы увидите два id_ * файла:

Код:
$ ls -a ~/.ssh
. .. id_rsa id_rsa.pub known_hosts

В этом случае вы уже можете использовать RSA идентификатор по умолчанию (id_rsa.pub) в вашей учетной записи BitBucket. Можете пропустить следующую секцию.

Настройка идентификатора по умолчанию

По умолчанию, система добавляет ключи для всех идентичностей в каталог /Users/yourname/.ssh. Следующая процедура создает идентичности по умолчанию.

  1. Откройте терминал
  2. Введите ssh-keygen
  3. Код:
    $ ssh-keygen

    Generating public/private rsa key pair.

    Enter file in which to save the key (/c/Documents and Settings/manthony/.ssh/id_rsa):

  4. Нажмите ввод, чтобы принять ключ по умолчанию и путь.
  5. Ведите пароль при запросе.
  6. Код:
    manthony@MANTHONY-PC ~
    $ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/c/Users/manthony/.ssh/id_rsa):
    Created directory ‘/c/Users/manthony/.ssh’.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /c/Users/manthony/.ssh/id_rsa.
    Your public key has been saved in /c/Users/manthony/.ssh/id_rsa.pub.
    The key fingerprint is:
    e7:94:d1:a3:02:ee:38:6e:a4:5e:26:a3:a9:f4:95:d4 manthony@MANTHONY-PC
    manthony@MANTHONY-PC ~
    $
  7. Проверьте список файлов в папке
  8. Код:
    $ ls ~/.ssh
    id_rsa id_rsa.pub

Команда создана два файла, один для открытого ключа (id_rsa.pub) и один для закрытого ключа ( id_rsa).

  1. Создание a SSH config file
  2. Создайте новый файл в ~/.ssh/ — config
  3. Добавить запись в файл в следующем формате:
  4. Код:
    Host bitbucket.org
    IdentityFile ~/.ssh/ Вторая линия с отступом. Это углубление (один пробел) является важным, поэтому убедитесь, что вы включили его.Вторая строка местоположение вашего приватного файла ключа. Если вы следуете инструкциям, введите id_rsa для .
    Когда вы закончите содержимое файла должно выглядеть примерно так:

    Host bitbucket.org
    IdentityFile ~/.ssh/id_rsa
    Сохраните и закройте файл.

  5. Перезапустите терминал GitBash.

Установка открытого ключа в Bitbucket

  1. Откройте и войдете
  2. Нажмите на аватар->управление аккаунтом
  3. Нажмите SSH-ключи
  4. Откройте терминал и введите
  5. Код:
    cat ~/.ssh/id_rsa.pub
  6. Скопируйте ключ, если вам такой способ покажется неудобным откройте любым текстовым редактором id_rsa.pub и скопируйте ключ (Из терминала НАДЁЖНЕЕ!)
  7. Вернитесь к странице ключей и нажмите новый ключ.
  8. Введите в поле Label — Default public key.
  9. Вставьте скопированный ключ в поле Ключ SSH.
  10. Нажмите кнопку добавить ключ, система добавила ключ в ваш аккаунт.
  11. ssh_key

  12. Вернитесь к терминалу и проверьте настройки командой
  13. Код:
    ssh -T git@bitbucket.org
  14. Если всё идёт по плану вы получите имя своего аккаунта, что-то на подобии этого:
  15. Код:
    conq: logged in as tutorials.
    You can use git or hg to connect to Bitbucket. Shell access is disabled.

Использование Bitbucket

  1. Создайте тестовый репозиторий кликнув в Bitbucket создать->создать репозиторий
  2. Назовите его GitTests
  3. Создайте на своей машине папку GitTests и добавьте туда текстовой файл
  4. Откройте GitBush и перейдите в эту папку
  5. Введите git init
  6. Добавьте свой удаленный репозиторий
  7. Код:
    git remote add origin git@bitbucket.org:modern/gittests.git
  8. Добавьте новые файлы в список отслеживаемых
  9. Код:
    git add -A
  10. Зафиксируйте изменения, создайте свой первый commit
  11. Код:
    git commit -m ‘Initial commit with contributors’

    [master (root-commit) 15ee0ca] Initial commit with contributors
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 TestDoc.txt

  12. Отправьте файл на сервер
  13. Код:
    git push -u origin master

Отличная работа, теперь вы все настроено! Да, чтобы не вводить постоянно пароль push/pull запросах можно снова воспользоваться командой:

Код:
ssh-keygen -t rsa

На вопрос для ключевой фразы, оставьте это поле пустым и просто нажмите клавишу ВВОД. Так же можно при создании ключей опустить ключевую фразу. (Если на Windows 8 столкнётесь с проблемами, попробуйте так сделать)

Пример использования Git вместе с Unreal Engine

  1. Зайдите в папку с проектом
  2. Создадите .gitignore с таким содержимым
  3. Код:
    *.gitignore

    *.sdf

    *.suo

    Binaries/

    Build/

    Intermediate/

    Saved/

    Выполните git init

    git add –A

  4. Создайте репозиторий на bitbucket
  5. Добавьте его командой git remote add origin git@bitbucket.org:NAME/REPO.git
  6. Сделайте commit: git commit
  7. Отправьте данные на сервер git push origin master
  8. Готово!
  9. Скриншот 2015-07-26 15.53.56

Теперь добавим пользователя, чтобы можно было работать совместно. Для этого нажмите настройки в репозитории, выберите управление доступом затем введите имя пользователя на Bitbucket, как только вы это сделаете ему придёт письмо с приглашением которое он должен принять.

  1. После того как приглашение принято у него на главной странице появится ваш репозиторий:
  2. Скриншот 2015-07-26 17.04.45

  3. Следующее что нужно сделать вашему напарнику – создать папку для проекта и скопировать репозиторий себе на компьютер командой git clone
  4. Код:
    git clone git@bitbucket.org:USER/unrealtest.git unreal-test
  5. Внесем изменения, добавим Readme файл
  6. Скриншот 2015-07-26 17.14.30

    Код:
    git add Readme.md

    git commit –m “add readme file”

    git push origin master

  7. Readme добавлен!
  8. Обновите локальный репозиторий на первой машине командой
  9. Код:
    git pull origin master

Теперь readme есть и у вас.

В заключение

Гитом пользоваться просто, а польза от него неоценима. Я описал лишь базовые понятие позволяющие «Встать и идти» для более глубокого понимания советую официальную рускоязычную книгу Pro Git. Для работы будет достаточно первых 200 страниц.

https://git-scm.com/book/en/v2

Так же стоит упомянуть что существуют графические оболочки для Git и Bitbucket – Git GUI и Source Tree.

Учебные материалы
Учим ветвления

За статью спасибо: Вадиму Невскому, Jquest’у (форматирование)

Добавил: jQuest Категория: Статьи


Комментарии

На данный момент не добавлено ни одного комментария.

Оставить комментарий

Вы должны войти, что бы оставлять комментарии.

UEngine.ru © 2017
Все права защищены. При копировании материалов с сайта, ссылка на первоисточник обязательна.
Яндекс.Метрика
Главная страница