Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Основные команды
Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.
git add
Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. Ниже перечислены наиболее интересные варианты использования этой команды.
Знакомство с этой командой происходит в разделе Отслеживание новых файлов главы 2.
О том как использовать git add для разрешения конфликтов слияния написано в разделе Основные конфликты слияния главы 3.
В разделе Интерактивное индексирование главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.
В разделе Деревья показано как эта команда работает на низком уровне, чтобы вы понимали, что происходит за кулисами.
git status
Команда git status показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
Мы познакомили вас с этой командой в разделе Определение состояния файлов главы 2, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.
git diff
Мы познакомили вас с основами этой команды в разделе Просмотр индексированных и неиндексированных изменений главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.
Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…B в разделе Определение применяемых изменений главы 5.
git difftool
Мы лишь вкратце упомянули о ней в разделе Просмотр индексированных и неиндексированных изменений главы 2.
git commit
В разделе О ветвлении в двух словах главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.
И наконец мы заглянули внутрь команды git commit в разделе Объекты коммитов главы 10 и узнали что она делает за кулисами.
git reset
В разделе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.
git rm
Команда git rm используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
git mv
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
Мы лишь вкратце упомянули эту команду в разделе Перемещение файлов главы 2.
git clean
Команда git clean используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Мы рассмотрели множество опций и сценариев использования этой команды в разделе Очистка рабочего каталога главы 7.
Git add all что делает
Check your version of git by running
SYNOPSIS
DESCRIPTION
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore.
The «index» holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working tree, and before running the commit command, you must use the add command to add any new or modified files to the index.
This command can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content to the index.
The git status command can be used to obtain a summary of which files have changes that are staged for the next commit.
Please see git-commit[1] for alternative ways to add content to a commit.
OPTIONS
For more details about the
syntax, see the pathspec entry in gitglossary[7].
Don’t actually add the file(s), just show if they exist and/or will be ignored.
Allow adding otherwise ignored files.
Allow updating index entries outside of the sparse-checkout cone. Normally, git add refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See git-sparse-checkout[1] for more details.
Add modified contents in the working tree interactively to the index. Optional path arguments may be supplied to limit operation to a subset of the working tree. See “Interactive mode” for details.
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
Open the diff vs. the index in an editor and let the user edit it. After the editor was closed, adjust the hunk headers and apply the patch to the index.
The intent of this option is to pick and choose lines of the patch to apply, or even to modify the contents of lines to be staged. This can be quicker and more flexible than using the interactive hunk selector. However, it is easy to confuse oneself and create a patch that does not apply to the index. See EDITING PATCHES below.
Update the index just where it already has an entry matching
. This removes as well as modifies index entries to match the working tree, but adds no new files.
Update the index not only where the working tree has a file matching
but also where the index already has an entry. This adds, modifies, and removes index entries to match the working tree.
Update the index by adding new files that are unknown to the index and files modified in the working tree, but ignore files that have been removed from the working tree. This option is a no-op when no
This option is primarily to help users who are used to older versions of Git, whose «git add
…», i.e. ignored removed files.
Don’t add the file(s), but only refresh their stat() information in the index.
If some files could not be added because of errors indexing them, do not abort the operation, but continue adding the others. The command shall still exit with non-zero status. The configuration variable add.ignoreErrors can be set to true to make this the default behaviour.
Override the executable bit of the added files. The executable bit is only changed in the index, the files on disk are left unchanged.
This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options).
EXAMPLES
Adds content from all *.txt files under Documentation directory and its subdirectories:
Note that the asterisk * is quoted from the shell in this example; this lets the command include the files from subdirectories of Documentation/ directory.
Considers adding content from all git-*.sh scripts:
INTERACTIVE MODE
When the command enters the interactive mode, it shows the output of the status subcommand, and then goes into its interactive command loop.
The command loop shows the list of subcommands available, and gives a prompt «What now> «. In general, when the prompt ends with a single >, you can pick only one of the choices given and type return, like this:
You also could say s or sta or status above as long as the choice is unique.
The main command loop has 6 subcommands (plus help and quit).
This shows the change between HEAD and index (i.e. what will be committed if you say git commit ), and between index and working tree files (i.e. what you could stage further before git commit using git add ) for each path. A sample output looks like this:
It shows that foo.png has differences from HEAD (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, binary would have been shown in place of nothing). The other file, git-add—interactive.perl, has 403 lines added and 35 lines deleted if you commit what is in the index, but working tree file has further modifications (one addition and one deletion).
This shows the status information and issues an «Update>>» prompt. When the prompt ends with double >>, you can make more than one selection, concatenated with whitespace or comma. Also you can say ranges. E.g. «2-5 7,9» to choose 2,3,4,5,7,9 from the list. If the second number in a range is omitted, all remaining patches are taken. E.g. «7-» to choose 7,8,9 from the list. You can say * to choose everything.
What you chose are then highlighted with *, like this:
After making the selection, answer with an empty line to stage the contents of working tree files for selected paths in the index.
This has a very similar UI to update, and the staged information for selected paths are reverted to that of the HEAD version. Reverting new paths makes them untracked.
This has a very similar UI to update and revert, and lets you add untracked paths to the index.
This lets you choose one path out of a status like selection. After choosing the path, it presents the diff between the index and the working tree file and asks you if you want to stage the change of each hunk. You can select one of the following options and type return:
After deciding the fate for all hunks, if there is any hunk that was chosen, the index is updated with the selected hunks.
This lets you review what will be committed (i.e. between HEAD and index).
EDITING PATCHES
Added content is represented by lines beginning with «+». You can prevent staging any addition lines by deleting them.
Removed content is represented by lines beginning with «-«. You can prevent staging their removal by converting the «-» to a » » (space).
Modified content is represented by «-» lines (removing the old content) followed by «+» lines (adding the replacement content). You can prevent staging the modification by converting «-» lines to » «, and removing «+» lines. Beware that modifying only half of the pair is likely to introduce confusing changes to the index.
There are also more complex operations that can be performed. But beware that because the patch is applied only to the index and not the working tree, the working tree will appear to «undo» the change in the index. For example, introducing a new line into the index that is in neither the HEAD nor the working tree will stage the new line for commit, but the line will appear to be reverted in the working tree.
Avoid using these constructs, or do so with extreme caution.
Content which does not differ between the index and working tree may be shown on context lines, beginning with a » » (space). You can stage context lines for removal by converting the space to a «-«. The resulting working tree file will appear to re-add the content.
modifying existing content
One can also modify context lines by staging them for removal (by converting » » to «-«) and adding a «+» line with the new content. Similarly, one can modify «+» lines for existing additions or modifications. In all cases, the new modification will appear reverted in the working tree.
You may also add new content that does not exist in the patch; simply add new lines, each starting with «+». The addition will appear reverted in the working tree.
There are also several operations which should be avoided entirely, as they will make the patch impossible to apply:
adding context (» «) or removal («-«) lines
deleting context or removal lines
modifying the contents of context or removal lines
Git и Github. Простые рецепты
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Самую первую версию отменить нельзя. Ее можно только исправить. Если вы хотите добавить изменения в последнюю версию, то после выполнения команды commit, добавляете необходимые изменения и вызываете:
Ключ —no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ —oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
До текущего момента мы работали с локальным репозиторием, который сохранялся в папке на компьютере. Если мы хотим иметь возможность сохранения проекта в интернете, создадим репозиторий на Github. Для начала нужно зарегистрироваться на сайте github.com под именем myuser (в вашем случае это может быть любое другое имя).
После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
