Перейти к содержанию

Git - совместная разработка/Введение

Добавить ссылки
Материал из Викиучебника — открытых книг для открытого мира

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

Настройка

[править]

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

git config --global user.email "wiki@ru.wikibooks.org" - сохранит вашу почту

git config --global user.name "WikiMedia" - сохранит ваше имя(ник)

Создание Git-репозитория

[править]

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

Создать новый репозиторий git просто. Есть две команды, которые реализуют эту функциональность: git-init (1) и git-clone (1). Клонирование уже существующего репозитория будет рассмотрено позже. А пока давайте создадим новый репозиторий в новом каталоге: 

$ git init myrepo

Инициализированный пустой репозиторий Git под названием myrepo находится в:

  1. /home/username/myrepo/.git/ в Linux.
  2. C:/Users/username/myrepo/.git/ в Windows.


Если у вас уже есть каталог, который вы хотите превратить в репозиторий git: 

$ cd my_preexisting_repo #перейдем в существующую папку с проектом
$ git init

Взяв первый пример, давайте посмотрим, что произошло: 

$ cd myrepo 
$ ls -a 
.git

Весь ваш репозиторий(вернее, вся информация о нем) будет находиться в каталоге .git. Некоторые SCM оставляют файлы по всему вашему рабочему каталогу (например, .svn, .cvs, .acodeic и т. Д.). Git воздерживается от этой практики и помещает все в подкаталог корня репозитория с метко названным .git.

Проверка состояния

[править]

Чтобы проверить состояние вашего репозитория, используйте команду git-status (1). Например, недавно созданный репозиторий, в котором еще нет коммитов, должно показать следующее: 

$ git status
On branch master #на ветке master

Initial commit 

nothing to commit (create/copy files and use "git add" to track) #нечего коммитить

Выработайте привычку часто использовать git-status, чтобы быть уверенным, что вы делаете именно то, что хотите сделать

Добавление и коммит файлов

[править]

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

Чтобы подготовить файлы для следующего коммита, используйте команду git-add (1). 

$ nano file.txt
hack hack hack...
$ git status

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	file.txt

nothing added to commit but untracked files present (use "git add" to track)

Это показывает нам, что мы используем ветку под названием «master» и что есть файл, который git не отслеживает (еще не имеет истории коммитов). Git услужливо отмечает, что файл можно включить в нашу следующую фиксацию, выполнив git add file.txt: 

$ git add file.txt
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#	new file:   file.txt
#

После добавления файла он отображается как готовый к коммиту. Сделаем это сейчас: 

$ git commit -m 'My first commit'
[master (root-commit) be8bf6d] My first commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file.txt

В большинстве случаев вы не захотите использовать форму -m «Сообщение коммита» - вместо этого оставьте ее отключенной, чтобы открыть $EDITOR, чтобы вы могли написать желаемое сообщение коммита. Мы опишем это дальше, но в примерах будет использоваться форма -m «Сообщение о коммите», чтобы читатель мог легко увидеть, что происходит. Вы можете использовать git add -A для автоматической подготовки всех измененных и неотслеживаемых файлов для включения в следующий комит. После того, как файл отслеживается, git add -u обработает его, если он изменился.

reset

[править]

Если вы передумали размещать файл и еще не зафиксировали его, вы можете отключить его с помощью простейшей формы команды git-reset (1): 

$ git reset file.txt

отключить только один файл или убрать все из кэша:

$ git reset

git-reset имеет достаточно много интересных функций, например:

  • Чтобы отменить два последних коммита, не касаясь файлов: git reset 'HEAD~2'.
  • Для отмены двух последних коммитов и их изменений в файлах: git reset HEAD ~ 2 --hard.
  • Чтобы отменить две последние операции в ветке: git reset 'HEAD @ {2}' Это можно использовать для отмены нежелательного reset`а.

restore

[править]

git restore возвращается к версии файла, указанной в параметре.

Исключение файлов из Git

[править]

Часто в вашем рабочем пространстве есть файлы, которые вы не хотите добавлять в репозиторий. Например, emacs запишет резервную копию любого файла, который вы редактируете с суффиксом тильды, например filename ~. Несмотря на то, что вы можете вручную не добавлять их в коммит (что означает,что вы не используете git add -A), они загромождают список статусов.

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

Например:

# игнорировать резервные файлы emacs:
*~

# игнорировать все в кэше, в директории:
app/cache

Git ищет файл игнорирования под двумя именами:

  • .git/info/exclude — это относится к вашей личной копии репозитория, а не к публичной части репозитория.
  • .gitignore — поскольку он находится за пределами каталога .git, он обычно отслеживается Git, как и любой другой файл в репозитории.

То, что вы вставляете в один (или оба) из этих файлов, зависит от ваших потребностей. .gitignore - хорошее место, чтобы упомянуть о файлах, которые все, кто работает с копиями этого репозитория, вероятно, захотят игнорировать, например, о продуктах для сборки. Если вы проводите свои собственные эксперименты, которые вряд ли коснутся других участников кода, вы можете поместить соответствующие строки игнорирования в .git / info / exclude.

Обратите внимание, что игнорирование записей в файлах актуально только для команд git status и git add -A (добавить все новые и измененные файлы). Любые файлы, которые вы явно добавляете с помощью git add filename, всегда будут добавляться в репозиторий, независимо от того, совпадают ли их имена с игнорируемыми записями или нет. И как только они будут добавлены в репозиторий, изменения в них отныне будут автоматически отслеживаться с помощью git add -u.

Качественные сообщения в коммите

[править]

Tim Pope пишет о том, как должно выглядеть правильное сообщение в коммите(перевод):

  • Краткая (50 символов или меньше) сводка изменений.
  • При необходимости более подробный пояснительный текст. Может достигать до 72 символов в одной строке. В некоторых случаях первая строка рассматривается как тема коммита(заголовок), а остальной текст - как тело. Пустая строка, отделяющая сводку от тела, имеет решающее значение (если вы не опустите тело полностью).
  • Пишите в коммите в настоящем времени: «Исправить ошибку», а не «Исправил ошибку». Это соглашение аналогично и для сообщений о коммитах при git merge и git revert.
  • Следующие абзацы идут после пустых строк.
  • Макреры(маркированный список) - это тоже хорошо
  • Обычно для маркера используется дефис или звездочка, которым предшествует один пробел с пустыми строками между ними, но здесь есть разные варианты.
  • Используйте выступ.

Давайте начнем с нескольких причин, по которым 72 символа в коммите а - это хорошо.

  • Журнал Git не делает никакого форматирования для коммитов. При использовании пейджера по умолчанию или less -S, ваши абзацы отходят далеко от края экрана, что затрудняет их чтение. В терминале с 80 допустимыми символами, если мы вычтем 4 символа для отступа слева и еще 4 для симметрии справа, у нас останется 72 столбца.
  • git format-patch --stdout преобразует серию коммитов в серию электронных писем, используя сообщения коммита для тела сообщения. Хороший сетевой этикет гласит, что мы должны вложить в наши электронные письма обычный текст так, чтобы было место для нескольких уровней вложенных индикаторов ответа без переполнения в терминале до 80 символов.
Источник — https://ru.wikibooks.org/w/index.php?title=Git_-_совместная_разработка/Введение&oldid=204898