Что означает статус файла 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); знак вопроса (?) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом (8), соответствуют любому символу из интервала (в данном случае от 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-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (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
Основные сообщения в консоли:
Снимки состояний как основа
Большинство систем хранят информацию как список изменений, связанных с файлами (Subversion).
GIT же делает снимок файлов в конкретный момент времени и сохраняется ссылка на этот снимок. Для увелечения эффективности на неизмененные файлы делается ссылка на их раннее сохраненные версии.
Контрольная сумма
3 состояния для файлов
Файлы в GIT могут находиться в 3 состояниях:
Как строится процесс работы в Git
Настройки
Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:
Узнаем подробности о том, как работает команда, например, log :
Пример файла .git/config
Псевдонимы (алиасы) в GIT
Команда git config позволяет создавать псевдонимы:
.gitignore
Игнорируем имена файлов:
Звезда означает фрагмент в имени:
Указываем диапозон (для игнорирования файлов):
Игнорируем от корня проекта:
При этом данные конструкции работают одинаково:
** используются, чтобы обозначить произвольное количество фрагментов пути:
! используется, когда требуется игнорировать все кроме чего-либо конкретного:
Жизненный цикл состояния файлов
Основные команды в Git
git init
Чтобы проинициализировать (создать) пустой Git репозиторий введите команду:
git clone
Получаем копию существующего репозитория, клонировав удаленный, например, с gitHub.
Эта команда аналогично предыдущей, но все файлы перемещаются в папку [name_folder]
git status
Команда, показывающая статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (Отслеживание новых файлов)
Данная команда может работать как «Добавление файлов к проекту» (добавляем в индекс).
Чтобы сообщить git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью команды:
git add (Индексация изменённых файлов)
Также данная команда может работать как «Добавление содержимого к следующему коммиту».
Давайте модифицируем файл, уже находящийся под версионным контролем. Чтобы проиндексировать его, необходимо выполнить команду:
git reset (Отмена индексирования)
Примечательно, что команда git status покажет, как отменить индексирование:
git commit
При каждой фиксации мы сохраняем снимок проекта, к которому можно вернуться в любой момент, или чтобы сравнить с текущим состоянием.
git rm
Чтобы удалить директорию:
git amend (Изменение последнего коммита)
Если вы что-то не сделали в последнем коммите, то отредактировать его не сложно. Все, что нужно это добавить изменения в индекс обычным образом:
Эта команда берет индексированный файлы и включает в коммит всю обнаруженную там информацию.
Чтобы изменить название коммита выполните:
git checkout (Отмена изменение в файле)
С подсказкой опять поможет команда git status :
Итак, файлы могут быть возвращены в состояние последнего коммита с помощью команды:
git checkout (Получаем предыдущие версии файлов, не трогая остальные)
Допустим нам нужно вернуть версию файла, которая была два коммита назад. При этом нам требуется откатить лишь один файл.
Восстановим файл index.html на момент конкретного коммита ( 0b335 ):
Или откатим версию файла до состояния из текущего коммита (откатим изменения, которые нас не устраивают):
git clone
Очистка проекта от всех изменений (git clean)
Команда git clean предназначена для удаления только неотслеживаемых файлов и директорий
Просмотр (diff)
Команда git diff используется для сравнения коммитов или файлов.
Сравниваем с текущим состоянием
Покажем изменения в рабочей директории с момента последнего коммита:
Но при этом обе приведенные выше команды игнорируют неотслеживаемые файлы.
Ограничим сравнение по пути:
Сравним состояние 2-х коммитов
Сравним состояние 2-х веток
сравним, что сделано в feature по сравнению с веткой master :
Сравниваем файлы из разных коммитов
Сравнение по словам
Чтобы включить отличия по словам:
Удаленный репозиторий
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп., для работы локально)
Добавление удаленных репозиториев под коротким именем:
— теперь вместо полного URL-адреса в командную строку можно вводить имя alias_repo
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master :
git fetch (Извлечение данных из уд. реп.)
Извлечение данных из удаленного репозитория выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.
git push (проталкиваем изменения на уд. сервер)
Отправляем изменения в удаленный репозиторий:
Отправим ветку master на удаленный репозиторий master :
Или, что тоже самое:
Отправим ветку master на удаленный репозиторий masterB :
git push (удаляем удаленные ветки)
Удаляем ветку в удаленном репозитории:
git pull (скачиваем изменения)
git remote show (получаем инфо. об уд. реп.)
Удаленные ветки
Если вам потребуется своя локальная ветка ( name_branch ), аналогичная удаленной ветки, то можно воспользоваться командой:
Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:
Текущая ветка начнет следить за удаленной origin/test-git
Чтобы увидеть актуальные ветки наблюдения:
Ветвление
Ветки в Git всего лишь указатели на предыдущие коммиты, перед каждым коммитом указатель автоматически сдвигается вперед.
git branch (создаем ветку)
При создании новой ветки создается новый указатель, который, как отмечалось выше, автоматически сдвигается вперед (при каждом коммите).
Указатель HEAD указывает на текущую локальную ветку.
Узнаем указатели веток:
Обратите внимание. Узнаем указатели веток, историю коммитов, точки расхождения:
git branch (управление ветками)
Отобразим все ветки:
* указывает на ветку с указатедем HEAD(текущая).
Отобразим ветку с информацией о коммите:
Ветки слитые с текущей:
Ветки не слитые с текущей:
git checkout (смена веток)
Перейдем в существующую ветку:
Создадим и сразу перейдем в нее:
Переносим коммиты в другую ветку или Передвигаем (Откатываем) коммиты
Создадим ветку ( feature ) от текущей:
Теперь нам нужно передвинуть master на то количество коммитов, которое нам необходимо.
Или, пусть master указывает туда же куда и new_f :
Создадим ветку master на указанном коммите и переключимся на нее:
git merge
Объединяем текущую локальную ветку с удаленной:
Создаем новую ветку на основе изменений в другой ветке
Бывают ситуации, когда вы начинаете работать на какой-либо ветке, но изменения становится настолько большими, что вам хотелось бы перенести их в новую ветку. Это сделать довольно просто:
—ours к файлу
Допустим, после merge ветки feature в master в файле index.html появились конфликты, при этом мы уверены, что код на ветке master правильный. Чтобы разрешить конфликты в этом случае нам поможет команда:
—theirs к файлу
Если нам нужно взять версию из сливаемой ( feature ) ветки:
—merge к файлу
Вернуться к версии с маркерами конфликта:
Отменяем слияние и сбрасываем конфликты
reflog
Для адекватного вывода reflog используют команду, например, для ветки master :
Или без аргументов выведет reflog для HEAD :
Зачем нужен reflog:
Восстановим ветку по коммиту (под windows потребуются »):
Выводим reflog с датой:
2. Переходим на предыдущую ветку, с которой был checkout на текущую ветку:
Как работает: по reflog ищет ближайший checkout на текущую ветку.
git stash (сохраняем изменения)
Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно.
Для таких случае существует команда stash. Команда stash собирает незакоммиченные изменения, удаляет их из файлов и в специальном виде архивирует в Git.
git stash pop
Восстановить(вернуть) изменения поможет следующая команда:
Ошибки при git stash
Иногда мы можем сделать git stash pop не на той ветке, где сохранили изменения, это может привести к ошибке.
Просмотр истории и старых версий
git log
Для просмотра изменений (истории коммитов) используется команда
, которая покажет список последних коммитов и их хеши SHA1. Первыми показываются последние коммиты.
Или можно использовать
Или для конкретной ветки
У git log множество возможностей, например, мы можем выводить историю в более удобном формате:
Ограничивать коммиты по времени:
Показывать разницу, внесенную каждым коммитом:
Выведем коммиты достижимые из всех ссылок:
Просмотр коммитов (кроме)
Просмотр коммитов (И различий) по файлу
Выведем коммиты, в которых менялся файл index.html :
Выведем конкретные различия, в которых менялся файл index.html :
Флаги-фильтры для log (поиск изменений в файлах)
Поиск всех коммитов в описании которых есть слово word :
Найдем вызов функции:
Найдем объявление функции:
Не забывайте, что function doAny\( это регулярное выражение.
Выводи все коммиты с n-й по n-ю строку, например, выведем с 3-й по 7-ю строку:
Или найдем фрагмент кода по регулярному выражению:
Возможность очень полезная, так как позволяет отследить изменения любого блока кода в файле.
git show
git show используется для того чтобы проанализировать коммит, по хэшу:
git show (Смотрим на коммит родителя/предыдущий)
смотрит на 2 коммита вниз (
Тоже самое можно указать через число:
Как посмотреть на файл в предыдущем коммите
Флаг HEAD можно заменить @ :
Посмотрим на файл index.html в ветке master :
Смотрим на текущую (проиндексированную) версию файла
Ищем коммит по описанию (слову)
Кто написал эту строку? git blame
Вывести информацию о том, кто написал каждую строку в package.json:
Сократим дату и выведем только те строки, которые нас интересуют (например, с 5-й по 8-ю):
git reset
Как вернуть коммит, убранный reset
Подведем итог: мягкий reset отменяет коммит, но оставляет все подготовленные для коммита данные.
Передвигает ветку, сбрасывает индекс, но не трогает рабочую директорию. То есть изменения останутся в рабочей директории, но не будут проиндексированы. Пример использования:
reset переносит ветку, но так как HEAD указывает на текущий коммит, то ветка переносится туда же, где и сейчас, то есть ничего не происходит. Однако есть второй полезный момент: сброс индекса на состояние соответствующего коммита ( HEAD ), сами изменени останутся в рабочей директории, то есть очистка от всех изменений.
Для замены коммита запускаем:
Конфликты в Git
Команда git status позволяет увидеть файлы с конфликтами.
cherry-pick
Команда cherry-pick используется, чтобы переместить какой-либо коммит (по хешу) из одной ветки в другую.
Например, поместим коммит 268510c2f в ветку master (текущая).
rebase
Перенос веток
Отказ от переноса
Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:
Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:
Отмена rebase
Отмена rebase после того как rebase завершился.
Или (что более надежно).
Работаем с bitbucket.org
1. кликаем по this repository Fork
3. создадим ветку (на основе удаленной ветки test-git )
4. и внесем в нее какие-либо изменения
5. Фиксация изменений
6. Отправка новой ветки в ветку на bitbucket
Далее переходи на bitbucket
7. Находим нужную ветку и делаем Create pull request (запрос на включение): где вы можете выбрать как проекты, так и ветки куда пойдет запрос на слияние.
Владелец проекта может выделить часть кода и написать к нему комментарий. Как только это произойдет пользователь, открывший запрос на включение получит уведомление. Пользователь вносит правки и отправляет его.
8. Принимаем pull request
Полезные приемы
Как в git заменить ветку master полностью другой веткой?
Я имею две ветки в моем репо:
2. seotweaks (создана от master )