что означает статус файла modified в выводе команды git status
Работа в команде с использованием Git¶
Общие сведения¶
Для организации командной работы над проектом может быть использована система контроля версий файлов Git. Использование Git имеет ряд преимуществ перед другими способами организации совместной работы:
сохранение полной истории изменений файлов с возможностью возврата к предыдущим версиям
синхронизация изменений между пользователями и автоматическое слияние изменений
возможность работы с бинарными файлами большого объёма
Типичный рабочий процесс¶
В ходе работы в локальных репозиториях создаются, изменяются или удаляются файлы.
По завершении некоторого логического этапа работы возникает необходимость фиксации изменений (коммит) и/или синхронизации с коллегами.
Локальные изменения загружаются в общее хранилище и становятся доступными для коллег.
Далее описывается ограниченный набор команд Git, рекомендуемых к использованию при создании приложений и графических ресурсов.
Перед выполнением команд необходимо перейти в репозиторий, например:
Индивидуальные настройки¶
Новый пользователь может установить имя и почтовый адрес командами:
Установленные данные будут использоваться в логе изменений.
Проверка статуса¶
Перед началом, в процессе или после выполнения любых операций рекомендуется проверять текущее состояние репозитория.
Проверить статус можно командой:
Перед коммитом¶
Проверка изменений (текстовых файлов)¶
Перед совершением коммита в случае текстовых файлов рекомендуется просмотреть внесенные изменения.
Проверить, что изменилось, во всей директории:
или только в определенном файле:
Возможный результат команды git diff для текстового файла:
Восстановление файлов¶
Если файл был изменен или удален, но его необходимо восстановить (до состояния, зафиксированного последним коммитом), следует использовать команду:
Внесенные изменения будут отменены, поэтому эту команду необходимо выполнять с осторожностью.
Посторонние файлы¶
Если файл значится в списке Untracked files (команда git status ), но контроль версий для него не нужен, его следует удалить или переместить за пределы рабочей директории.
Подготовка к коммиту¶
Добавление файлов¶
Если изменения устраивают, добавить нужные измененные и/или новые файлы для коммита:
Снова проверить статус:
Возможный результат команды git status после добавления некоторых файлов командой git add :
Удаление файлов¶
Коммит¶
Выполнить коммит командой:
Появится окно текстового редактора (например, nano или vim), в котором нужно ввести комментарий к коммиту на английском языке.
Сохранить изменения и выйти из редактора (в nano Ctrl+O, затем Ctrl+X; в vim ZZ, или ESC :wq).
Синхронизация между репозиториями¶
После того как все коммиты сделаны, необходимо загрузить изменения из удаленного (“общего”) репозитория в локальный:
При желании можно посмотреть, какие изменения были внесены коллегами, командой:
Также можно просмотреть лог изменений:
Команда git pull не всегда приводит к успешной синхронизации. Результат команды git pull в случае наличия конфликтов:
Порядок действий при возникновении конфликтов описан далее.
Затем нужно загрузить изменения из локального репозитория в удаленный (“общий”), чтобы локальные изменения стали доступными для коллег.
Разрешение конфликтов¶
Общие сведения¶
Конфликты синхронизации происходят, если выполнены оба условия
один и тот же файл был изменен как в локальном, так и в удаленном репозитории, и
автоматическое слияние изменений не произошло, поскольку изменения находятся в одном и том же месте файла.
бинарный файл (текстура, blend-файл) независимо изменен двумя участниками разработки
в текстовой файл в одной и той же строке были внесены разные изменения
Порядок действий¶
Не рекомендуется производить какие-либо действия с файлами (изменять, удалять), пока репозиторий находится в конфликтном состоянии.
Дальнейший порядок действий различен для бинарных и текстовых файлов.
Бинарные файлы¶
На данном этапе конфликтующие бинарные файлы находятся в том состоянии, в котором они находились в локальном репозитории до попытки синхронизации. Файлы полностью функциональны (например, открываются графическими редакторами).
В итоге необходимо остановиться на нужной версии файла. При угрозе потери работы можно сохранить отбрасываемую версию файла вне репозитория.
Текстовые файлы¶
На данном этапе в конфликтующие текстовые файлы Git’ом вносятся как локальные, так и удаленные изменения одновременно, в особом формате. Такие текстовые файлы как правило, не работоспособны.
В случае конфликта текстовых файлов можно поступить следующим образом. Файлы, содержащие исходный код, необходимо отредактировать с учетом или без учета внесенных обеими сторонами изменений. В то же время экспортированные текстовые файлы сцен (заканчивающиеся на .json) проще повторно экспортировать.
Корректирующий коммит¶
После выбора нужных файлов или редактирования изменений, добавить их для коммита:
Возможный результат выполнения git status после добавления конфликтующих файлов для коммита:
Выполнить коммит, комментарий рекомендуется оставить предложенный по умолчанию:
Тэги (метки) предназначены для указания на определенный коммит, например, с целью обозначения стабилизированной версии продукта.
Просмотреть список тэгов:
Создать тэг для релиза от 3 июня 2013 г., указывающий на коммит со стабильной версией проекта:
Введение в Git
Три состояния
Git имеет три основных состояния, в которых могут находиться ваши файлы: зафиксированном (committed), изменённом (modified) и подготовленном (staged). «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.
Мы подошли к трём основным секциям проекта Git: Git-директория (Git directory), рабочая директория (working directory) и область подготовленных файлов (staging area).
Git-директория — это то место, где Git хранит метаданные и базу объектов вашего проекта. Это самая важная часть Git, и это та часть, которая копируется при клонировании репозитория с другого компьютера.
Рабочая директория является снимком версии проекта. Файлы распаковываются из сжатой базы данных в Git-директории и располагаются на диске, для того чтобы их можно было изменять и использовать.
Область подготовленных файлов — это файл, располагающийся в вашей Git-директории, в нём содержится информация о том, какие изменения попадут в следующий коммит. Эту область ещё называют «индекс».
Базовый подход в работе с Git выглядит так:
Если определённая версия файла есть в Git-директории, эта версия закоммичена. Если файл изменён и добавлен в индекс, значит, он будет добавлен в следующий коммит. И если файл был изменён с момента последнего распаковывания из репозитория, но не был добавлен в индекс, он считается изменённым.
Первоначальная настройка Git
Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git’ом под себя. Это нужно сделать только один раз — при обновлении версии Git’а настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.
Имя пользователя
Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
Проверка настроек
Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например, из /etc/gitconfig и
/.gitconfig ). В этом случае Git использует последнее значение для каждого ключа.
Также вы можете проверить значение конкретного ключа, выполнив git config :
Как получить помощь?
Если вам нужна помощь при использовании Git, есть три способа открыть страницу руководства по любой команде Git:
Например, так можно открыть руководство по команде config
Создание Git-репозитория
Для создания Git-репозитория вы можете использовать два основных подхода. Во-первых, cоздание репозитория в существующей директории. Во-вторых, клонирование существующего репозитория с другого сервера.
Создание репозитория в существующей директории
Если вы собираетесь начать использовать Git для существующего проекта, то вам необходимо перейти в директорию проекта и в командной строке ввести
Клонирование существующего репозитория
Запись изменений в репозиторий
Каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые).
Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged).
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения (commit).
Определение состояния файлов
Это означает, что у вас чистый рабочий каталог, другими словами – в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. Наконец, команда сообщает вам на какой ветке вы находитесь и сообщает вам, что она не расходится с веткой на сервере.
Отслеживание новых файлов
Команда git add принимает параметром путь к файлу или каталогу; если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов.
Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ (*) соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса (?) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом (9), соответствуют любому символу из интервала (в данном случае от 0 до 9). Вы также можете использовать две звёздочки, чтобы указать на вложенные директории: a/**/z соответствует a/z, a/b/z, a/b/c/z, и так далее.
Коммит изменений
Теперь, когда ваш индекс находится в таком состоянии, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Простейший способ зафиксировать изменения — это набрать git commit :
В редакторе будет отображён следующий текст (это пример окна Vim’а):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита (463dc4f), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Индексация в момент коммита
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
Затем, если вы выполните команду git rm, удаление файла попадёт в индекс:
После следующего коммита файл исчезнет и больше не будет отслеживаться.
В команду git rm можно передавать файлы, каталоги или glob-шаблоны. Это означает, что вы можете вытворять что-то вроде:
Эта команда удаляет все файлы, чьи имена заканчиваются на
Переименование файлов
Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
Это эквивалентно выполнению следующих команд:
Операции отмены
Эта команда использует для дополнения коммита ваш индекс (staged). Если вы ничего не меняли с момента последнего коммита (например, команда запущена сразу после предыдущего коммита), то снимок состояния останется в точности таким же, а изменится лишь комментарий к коммиту.
Запустится тот же редактор комментария к коммиту, но уже с комментарием к предыдущему коммиту. Комментарий можно отредактировать точно так же, как обычно, просто он заменит собой предыдущий.
Например, если вы фиксируете изменения, и понимаете, что забыли проиндексировать изменения в файле, который хотели включить в коммит, можно сделать примерно так:
В итоге получится единый коммит — второй коммит заменит результаты первого.
Удаление файла из индекса
Файл CONTRIBUTING.md изменен, но снова не добавлен в индекс.
Отмена изменения измененного файла
Здесь довольно ясно указано, как отбросить сделанные изменения. Давайте так и сделаем:
Как видите, откат изменений выполнен.
Работа с удалёнными репозиториями
Удалённые репозитории представляют собой версии проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи.
Просмотр удалённых репозиториев
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Добавление удалённых репозиториев
Для того, чтобы добавить удалённый репозиторий и присвоить ему имя ( shortname ), просто выполните команду git remote add [shortname] [url] :
Теперь вместо указания полного пути вы можете использовать pb. Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :
Получение изменений из удалённого репозитория
Для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные ( push ) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch ).
Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если у вас есть ветка, настроенная на отслеживание удалённой ветки, то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветви и слить их со своей текущей ветвью. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master ).
Отправка изменений в удаленный репозиторий
Просмотр удаленного репозитория
Удаление и переименование удалённых репозиториев
Если по какой-то причине вы хотите удалить ссылку, вы можете использовать git remote rm :
Работа с git
Содержание
Что такое git? Основные понятия
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.
Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией.
Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта.
Рассмотрим пример: У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.
Запись изменений в репозиторий (commit)
Допустим, у вас имеется репозиторий Git и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать состояния этих изменений (commit) в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить. Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (не отслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть не измененными, измененными или подготовленными к коммиту (staged). Все изменения в них, будут отслеживаться. Не отслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемые и не измененные, потому что вы только взяли их из хранилища и ничего пока не редактировали. Как только вы отредактируете файлы, Git будет рассматривать их как измененные, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете (делаете коммит) все индексированные изменения.
Что такое ветка?
Ветка (или «branch») — это своеобразное «место» разработки. Например, после клонирования репозитория мы по-умолчанию находимся в ветке master, создаём ветку test (в которую будет всё слито из master), затем делаем в ней какие-то изменения, делаем коммит, а потом переключиться обратно в ветку master. С помощью команды
Работа с git-репозиториями, сведения для начинающих
Настройка git
Первым делом настроим ваше имя и адрес почты. Имя вводите на английском.
После этого нужно настроить доступ
Работа с локальным репозиторием
Клонирование репозитория
Чтобы начать работать с репозиторием, следует создать копию проекта со всей его историей локально. Нужно создать каталог Projects, перейти в него, а затем клонировать удалённый репозиторий:
то у вас не будет прав на запись, т.е. вы не сможете пушить (опубликовывать) коммиты.
Определение состояния файлов
Основная команда, используемая для определения какие файлы в каком состоянии находятся — это команда git status. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
Это означает, что у вас чистый рабочий каталог, другими словами — в нем нет ни отслеживаемых, ни измененных файлов. Git также не обнаружил не отслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь.
Предположим, вы добавили новый файл в ваш проект, простой README файл. Если этого файла раньше не было, и вы выполните git status, вы увидите не отслеживаемый файл как-то так:
Вы можете видеть, что новый файл README не отслеживаемый, т.к. он находится в секции “Untracked files”. Не отслеживаемый файл обычно означает, что Git нашел файл, отсутствующий в предыдущем коммите. Git не станет добавлять его в ваши коммиты, пока вы явно ему это не укажете. Это предохраняет вас от случайного добавления в репозиторий сгенерированных каких-либо других файлов, которые вы и не думали добавлять.
Добавление файлов в индекс
Для добавления файлов в индекс (временное хранилище изменений) используется команда git add. Чтобы добавить файл README в индекс и начать его отслеживание, выполните:
Если вы снова выполните команду git status, то увидите, что файл README теперь отслеживаемый и индексированный:
Вы можете видеть, что файл проиндексирован по тому, что он находится в секции “Changes to be committed”. Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add, будет добавлена в историю коммитов (git log).
Отредактируйте какой-нибудь .cpp файл, добавьте в него, например, комментарий и сохраните. Выполнив команду git status вы увидите, что ваш отредактированный файл находится в секции “Changed but not updated” — это означает, что отслеживаемый файл был изменен в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду
вносит в индексе все изменения, включая все обновлённые и новые файлы
Удаление файлов из индекса. Добавление удалённых файлов в индекс
После неё текущее состояние вашего файл останется низменным, но он не будет занесён в индекс.
Отмена текущих изменений в файле
Если вы поняли, что не хотите оставлять изменения внесённые в файл, то вернуть то состояние, в котором находился файл во время последнего коммита, выполните:
Будьте осторожны, т.к. все сделанные вами изменения в этом файле пропадут.
Просмотр (не)индексированных изменений
Если вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff. Допустим, вы снова изменили «.cpp» файл без индексирования (без git add). Чтобы увидеть, что же вы изменили, но пока не проиндексировали, выполните:
Вы увидите изменения, которые вы внесли в файл. Чтобы просмотреть изменения в файлах, которые вы уже добавили в индекс, выполните:
Работа с ветками
Просмотр списка веток
Чтобы просмотреть список веток, выполните:
после чего, вы увидите имеющиеся ветки
Создание веток
Когда вы создаёте ветку, то она создаёт независимый клон вашей текущей ветки (не индексируемые изменения не клонируются)
Чтобы создать ветку test, не переключаясь в неё, выполните:
Чтобы создать ветку test и переключиться в неё, выполните:
Перемещение по веткам
Чтобы перейти в ветку master, выполните:
Сохранение не индексированных изменений в текущей ветке и переход в другую
Если вы не хотите делать коммит, но вам нужно перейти в другую ветку, не теряя текущих изменений вы должны сделать:
После этого в git diff пропадут ваши изменения и вы можете перейти в другую ветку
Для просмотра сохранённых изменений:
Чтобы применить сохраненные изменения и вернуть рабочее состояние, выполните:
Чтобы удалить конкретный сохранённый стэш, выполните:
Чтобы удалить все сохранённые стэши, выполните:
Удаление ветки
Если у вас нет не индексированных изменений (изменили что-то, но ещё не добавляли в индекс с помощью git add),то удалить ветку можно так:
Если вы хотите удалить ветку, и потерять текущие изменения, то выполните:
Переименование ветки
Переименовать ветку можно так:
Слияние веток и конфликты
Команда попробует объединить текущую ветку и ветку test:
Иногда процесс слияния не идет гладко. Если вы изменили одну и ту же часть файла по-разному в двух ветках, которые собираетесь объединить, Git не сможет сделать это чисто и выдаст конфликт слияния:
Git не создал новый коммит для слияния. Он приостановил этот процесс до тех пор, пока вы не разрешите конфликт. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), можете выполнить команду git status:
Всё, что имеет отношение к конфликту слияния и что не было разрешено, отмечено как unmerged. Git добавляет стандартные маркеры к файлам, которые имеют конфликт, так что вы можете открыть их вручную и разрешить эти конфликты. Ваш файл содержит секцию, которая выглядит примерно так:
В верхней части блока (всё что выше =======) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё что находится в нижней части ― версия в ветке test. Чтобы разрешить конфликт вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Отредактируйте и удалите ====== и >>>>>>>. Затем выполните git add. Индексирование будет означать для Git, что все конфликты в файле теперь разрешены.
Работа с коммитами
Добавление нового коммита, просмотр истории
После этого откроется текстовой редактор и будет отображено что-то вроде этого:
Вам нужно будет ввести комментарий для коммита, после чего сохраниться.
Есть ещё другой способ, который позволит ввести комментарий сразу из командной строки:
Есть ещё команда, которая автоматически проиндексирует изменения во всех изменённых файлах проекта. Новые файлы при этом индексироваться не будут, но удаление файлов будет учтено. Т.е. вы можете обойтись без git add.
Можно без параметра «-m», чтобы посмотреть файлы, которые ввойдут в коммит.
Чтобы просмотреть историю коммитов, выполните уже знакомую команду:
Чтобы просмотреть изменения, сделанные в последнем коммите, выполните:
Так же во многих командах можно указывать номер коммита, начиная от верхнего, либо его собственный номер, который можно посмотреть в git log. Например, эта команда покажет третий сверху коммит:
Как видите, в данном случае число в HEAD
, обозначает номер коммита, не учитывая самый последний (верхний).
Создание отменяющего коммита
Если вы сделали коммит с ошибкой, то можно его отредактировать (как это сделать, мы разберём дальше), но делать это нужно лишь в том случае, если вы не опубликовали его в какой-нибудь удалённый репозиторий, с которым работают другие люди. В ином случае лучше создать коммит, который отменит предыдущий и вернёт вас в старое состояние. Как это сделать:
Если вам нужно отменить четвёртый коммит, то выполните:
Сброс состояния проекта, отмена, удаление последних коммитов
Помимо работы с индексом, git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В таком случае вместе с командой используются различные ключи (soft, hard и т.п.).
Команда отменит последний коммит и вернёт вас к тому состоянию, когда вы добавили все нужные изменения в индекс (git add), но ещё не совершили коммит. Команда не сбрасывает текущие индекс и не индексированные изменения. Если до выполнения reset вы добавляли в индекс какие-то файлы, то они войдут в секцию «Changes to be committed»!
Если состояние сбрасывается на несколько коммитов, то плюс ко всему будут добавлены в индекс и их изменения (секция «Changes to be committed»).
удалит два последних коммита и вернёт вас к такому состоянию проекта, если бы вы только что совершили третий сверху коммит.
Команда работает в том случае, если у вас нет не индексированных изменений тех файлов, которые изменяются в двух последних коммитах.
Отменяются два последних коммита. Сбрасывается индекс и обновляются файлы в директории до состояния третьего коммита сверху. При этом сохраняются изменения в файлах, которые не добавлялись в индекс (не git add).
Редактирование последнего коммита
Если сразу после совершения коммита, вы ничего не добавляли в индекс (git add), то следуйте инструкции. В ином случае, вам придётся удалить из него ненужные файлы:
Редактирование нескольких или какого-то одного коммита из истории
Допустим, вам надо отредактировать 3 последних коммита, выполните:
Команда выполнится в интерактивном режиме. Можно заметить, что в данном случае, число в команде HEAD
включает в себя самый верхний коммит. Откроется редактор, который отобразит нечто подобное:
Обратите внимание, что первым идёт коммит, который является самым старым из выбранных вами коммитов!
Для того, чтобы отредактировать нужный коммит, замените перед номером коммита слово pick на edit. Когда вы сохраните изменения и выйдите из редактора, Git вернёт вас к первому из тех коммитов, которые вы хотите отредактировать. В итоге вы увидите такое:
После чего, Git автоматически применит следующие коммиты. Если у вас несколько редактируемых коммитов, то вам снова придётся выполнить то, о чем я писал выше. В итоге Git покажет всё ли удачно применилось.
Редактирование комментария к коммиту
Если, например, надо исправить комментарий к 6 сверху коммиту, то выполняем:
Затем меняем у нужного коммита pick на reword. Исправляем комментарий, сохраняемся, выходим. Git автоматически должен всё поменять.
Изменение порядка коммитов. Удаление коммитов
Меняем строчки нужных коммитов местами, только не забудьте что первыми идут более старые коммиты, сохраняемся и выходим.
Чтобы удалить ненужный коммит, просто удаляем строчку с коммитом.
Слияние коммитов в один
Затем меняем pick на squash у нужных коммитов, сохраняем, выходим и видим что-то наподобие:
Если хотите, можно оставить только один комментарий, который будет у нового коммита, для этого нужно оставить комментарий после
а в остальных коммит мессаджах убрать.
Разбиение коммита на несколько
Предположим, что вы хотите разбить какой-то коммит в последних шести на несколько. Как всегда, выполняем:
Меняем у нужного коммита pick на edit. После этого делаем:
Эта команда отменяет коммит, который вы собираетесь разбивать и убирает из индекса все изменённые файлы. Вам остаётся только добавить файлы с нужными изменениями (git add), затем сделать коммит. Потом снова добавить нужные файлы, и снова сделать коммит. И так до тех пор, пока вы не разобьёте свой коммит на необходимое колличество коммитов. После этого нужно выполнить:
Всё это будет выглядеть примерно так:
Перенос коммитов из другой ветки
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера; либо сам разработчик совершал в ней коммиты. В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков. Предположим, имеется две ветки: master и test, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки test и накладывает их на последний коммит ветки master: вариант, в котором явно указывается, что и куда прикладывается
А здесь на master накладывается ветка, активная в настоящий момент :
После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой
Альтернативными выходами будут команды
пропустить наложение коммита и перейти к следующему или
отмена работы команды и всех внесенных изменений.
Работа с удалённым репозиторием
Удалённый репозиторий — это модификация проекта, которая хранится в интернете или ещё где-то в сети. УР обычно доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя помещение (push) и получение (pull) данных и из них тогда, когда нужно обменяться результатами работы.
Отображение удалённых репозиториев
Чтобы просмотреть какие удалённые серверы у вас уже настроены, следует выполнить команду
Она перечисляет весь список имён-сокращений (псевдонимов) удалённых репозиториев, созданных в текущем репозитории. Если вы склонировали ваш репозиторий, у вас должен отобразиться по крайней мере origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали.
Если у вас больше одного удалённого репозитория, команда покажет их все.
Создание и добавление удалённого репозитория
Создадим пустой удалённый репозиторий:
Имя лучше указывать такое же как у репозитория, который вы cклонировали.
Чтобы добавить УР под именем-сокращением, выполните:
Так же можно указывать адрес локального репозитория.
Забрать изменения из удалённого репозитория
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты. Ветка master теперь доступна локально как ПСЕВДОНИМ/master. Вы можете слить (merge) её в одну из ваших веток, или можете перейти на эту ветку и просмотреть её.
Когда вы клонируете репозиторий, команда git clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками, и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Она автоматически извлекает и затем сливает данные из удалённой ветки в вашу текущую ветку. Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull как правило извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Запушить изменения в удалённый репозиторий
Когда ваш проект достигает момента, когда вы хотите поделиться наработками, вам необходимо отправить (push) их в удалённый репозиторий. Команда для этого действия простая:
Чтобы отправить вашу ветку master на сервер origin, вы можете выполнить следующую команду:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то запушить не получится. Вам придётся сначала забрать изменения (pull) и объединить с вашими. Только после этого вам будет позволено выполнить push.
Получение информации об удалённом репозитории
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду
Если вы выполните эту команду с именем origin, вы получите что-то подобное:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что, если вы находясь на ветке master, выполните git pull, ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок. В некоторых случаях команда может показать какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push. Она также показывает каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере. И для нескольких веток показано какие удалённые ветки будут в них влиты при выполнении git pull.
Переименовывание удалённого репозитория
Например, если вы хотите переименовать псевдоним удалённого репозитория test в etersoft, вы можете сделать это следующим образом:
Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как test/master, стало etersoft/master.
Если вы хотите переименовать сам удалённый репозиторий, который вы создали, а он обычно размещается по адресу: http://git.etersoft.ru/people/ВАШ_НИК/packages/ИМЯ_РЕПОЗИТОРИЯ.git
то выполните команду:
Удаление удалённого репозитория
Если по какой-то причине вы хотите удалить ссылку (псевдоним), вы можете использовать:
Если вы хотите удалить сам репозиторий, то выполните:
Работа с удалёнными ветками
Удалённые ветки ― это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним. Они выглядят как (имя удал. репоз.)/(ветка). Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master.
Просмотр удалённых веток
Чтобы просмотреть список удалённых веток, вам нужно выполнить команду:
Удаление ветки в удалённом репозитории
Чтобы удалить ветку, выполните:
Слияние ветки из удалённого репозитория
Чтобы слить наработки в вашу текущую рабочую ветку, можете выполнить:
Если вы хотите иметь собственную ветку, над которой вы сможете работать, можете создать её на основе удалённой ветки:
Отслеживание веток
Получение локальной ветки с помощью git checkout из удалённой ветки автоматически создаёт то, что называется отслеживаемой веткой. Отслеживаемые ветки это локальные ветки, которые напрямую связаны с удалённой веткой. Если находясь на отслеживаемой ветке, вы наберёте git push, Git автоматически знает на какой сервер и в какую ветку отправлять изменения. Аналогично, выполнение git pull на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой. При клонировании репозитория, как правило, автоматически создаётся ветка master, которая отслеживает origin/master. Вот почему git push и git pull работают и не требуют других аргументов. Однако, если хотите, можете настроить другие отслеживаемые ветки — те, которые не отслеживают ветки в origin, и те, которые не отслеживают ветку master. Простой случай это тот пример, который вы видели выше — выполнение:
Так же можно использовать ключ —track. В общем в Git должно отобразиться сообщение, что ветка будет отслеживаться.
Работа с патчами
ID – идентификатор предыдущего коммита. Коммиты, более новые, чем указанный, будут записаны в файлы. В результате мы должны увидеть:
Посмотреть сделанные коммиты можно через:
Пример, в первой строчке – ID коммита:
В результате получится нечто вроде:
Сгенерированные патчи можно отправить по почте с помощью команды
Для подключения(приложения) патча следует пользоваться командой
Если в процессе приложения патча произошла ошибка, то при обновлении репозитория (pull) может появиться ошибка:
Для избежания этой ошибки после неудачного приложения патча следует осуществить следующую команду: