Changes to be committed что значит

8. Коммит изменений

01 Закоммитьте изменения

Достаточно об индексации. Давайте сделаем коммит того, что мы проиндексировали, в репозиторий.

Когда вы ранее использовали git commit для коммита первоначальной версии файла hello.html в репозиторий, вы включили метку -m , которая делает комментарий в командной строке. Команда commit позволит вам интерактивно редактировать комментарии для коммита. Теперь давайте это проверим.

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору. Редактор выбирается из следующего списка (в порядке приоритета):

• переменная среды GIT_EDITOR
• параметр конфигурации core.editor
• переменная среды VISUAL
• переменная среды EDITOR

У меня переменная EDITOR установлена в emacsclient (доступен для Linux и Mac).

Сделайте коммит сейчас и проверьте состояние.

Выполните:

Вы увидите в вашем редакторе:

Результат:

В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора (для этого в редакторе по умолчанию (Vim) вам нужно нажать клавишу ESC, ввести :wq и нажать Enter). Вы увидите…

Результат:

Строка «Waiting for Emacs…» получена из программы emacsclient , которая посылает файл в запущенную программу emacs и ждет его закрытия. Остальные выходные данные – стандартные коммит-сообщения.

02 Проверьте состояние

В конце давайте еще раз проверим состояние.

Выполните:

Результат:

Рабочий каталог чистый, можете продолжить работу.

Источник

Git commit

Коммит в Git и коммит в SVN

Несмотря на одинаковое название, команда git commit не имеет ничего общего с командой svn commit . Этот общеупотребительный термин может запутать новичков в Git, имеющих опыт работы с SVN, поэтому важно подчеркнуть разницу. Разница между git commit и svn commit — это разница между моделью централизованного приложения (SVN) и моделью распределенного приложения (Git). В SVN при выполнении коммита изменения передаются из локального клиента SVN в общий централизованный удаленный репозиторий SVN. В Git репозитории распределены, коммиты снимков состояния выполняются в локальный репозиторий, и для этого совершенно не нужно взаимодействовать с другими репозиториями Git. Позже коммиты Git можно будет передать в любой удаленный репозиторий.

Порядок действий

Не вдаваясь в подробности, Git можно рассматривать как утилиту управления временной шкалой. Коммиты — основные конструктивные элементы временной шкалы проекта Git. Их можно рассматривать как снимки состояния или контрольные точки на временной шкале проекта Git. Коммиты создаются с помощью команды git commit , которая делает снимок состояния проекта на текущий момент времени. Коммиты снимков состояния Git всегда выполняются в локальный репозиторий. В этом и заключается фундаментальное отличие от SVN, где коммит рабочей копии выполняется в центральный репозиторий. Git же, напротив, не принуждает вас взаимодействовать с центральным репозиторием до тех пор, пока вы не будете к этому готовы. Как раздел проиндексированных файлов является буфером между рабочим каталогом и историей проекта, так и локальный репозиторий разработчика является буфером между его вкладом в проект и центральным репозиторием.

Снимки состояния, а не различия

Помимо различий между SVN и Git с практической точки зрения, их базовая реализация также основывается на совершенно разных концепциях проектирования. SVN отслеживает различия в файле, тогда как модель управления версиями Git базируется на снимках состояния. Например, в коммите SVN содержатся различия исходного файла и файла, добавленного в хранилище. А Git записывает в каждом коммите все содержимое каждого файла.

Такой подход позволяет выполнять многие операции в Git намного быстрее, чем в SVN, поскольку конкретную версию файла не нужно «собирать» из его различий — во внутренней базе данных Git находится уже готовая редакция каждого файла.

Модель снимков состояния Git влияет практически на все аспекты модели управления версиями, от инструментов ветвления и слияния до рабочих процессов при совместной работе.

Распространенные опции

Коммит проиндексированного состояния кода. Эта команда откроет текстовый редактор с предложением ввести комментарий к коммиту. После ввода комментария сохраните файл и закройте текстовый редактор, чтобы выполнить коммит.

Выполнение коммита состояния со всеми изменениями в рабочем каталоге. Эта команда включает только изменения отслеживаемых файлов (тех, которые были в какой-то момент добавлены в историю с помощью команды git add ).

Быстрая команда, которая создает коммит с указанным комментарием. По умолчанию команда git commit открывает локально настроенный текстовый редактор с предложением ввести комментарий к коммиту. При передаче параметра -m текстовый редактор не открывается, а используется подставленный комментарий.

Команда для опытных пользователей с параметрами -a и -m . Эта комбинация параметров создает коммит всех проиндексированных изменений и добавляет к коммиту подставленный комментарий.

Этот параметр добавляет команде commit новый уровень функциональности. При передаче этого параметра будет изменен последний коммит. Вместо создания нового коммита проиндексированные изменения будут добавлены в предыдущий коммит. Кроме того, эта команда откроет настроенный текстовый редактор системы с предложением изменить указанный ранее комментарий к коммиту.

Примеры

Сохранение изменений с помощью команды commit

В следующем примере предполагается, что вы изменили содержимое файла hello.py в текущей ветке и готовы сделать коммит в историю проекта. Прежде всего, необходимо проиндексировать файл с помощью команды git add , после чего можно будет сделать коммит проиндексированного снимка состояния.

Эта команда добавит файл hello.py в раздел проиндексированных файлов Git. Проверить результат выполнения команды можно с помощью git status .

Окрашенный зеленым цветом вывод «new file: hello.py » сообщает о том, что файл hello.py будет сохранен при выполнении следующего коммита. Коммит выполняется с помощью указанной ниже команды.

Эта команда откроет текстовый редактор (настраиваемый через git config ) для ввода комментария к коммиту и покажет список файлов, которые будут зафиксированы в этом коммите:

Особых требований для комментариев к коммиту в Git нет, но обычно первая строка содержит описания коммита длиной до 50 символов, затем следует пустая строка и детальное пояснение того, что было изменено. Пример:

Обычно первая строка комментария к коммиту аналогична теме электронного письма. Остальная часть комментария считается телом сообщения и используется для детального описания набора изменений в коммите. Многие разработчики предпочитают использовать в комментариях настоящее время. Так комментарий становится больше похож на список действий в репозитории, благодаря чему многие операции перезаписи истории становятся более интуитивно понятными.

Обновление коммита (параметр amend)

Продолжим работу с файлом hello.py из приведенного выше примера. Давайте внесем в файл hello.py новые изменения и запустим следующие команды:

Снова откроется настроенный текстовый редактор. Но на этот раз он будет содержать комментарий к коммиту, который мы уже вводили ранее. Это указывает на то, что мы не создаем новый коммит, а редактируем последний.

Резюме

Модели коммитов в SVN и в Git существенно отличаются, но из-за общей терминологии часто возникает путаница. Если вы начинаете работу в Git, имея опыт работы с SVN, вам будет полезно знать, что коммиты в Git — простая операция, которую следует выполнять часто. В SVN коммит — сложная операция, связанная с выполнением удаленного запроса, тогда как в Git коммиты выполняются локально и по более эффективному алгоритму.

Готовы изучить Git?

Ознакомьтесь с этим интерактивным обучающим руководством.

Источник

Введение в 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 config , которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git’а, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:

• Файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр —system , то параметры будут читаться и сохраняться именно в этот файл.
• Файл

/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра —global .

Файл config в каталоге Git’а (т.е. .git/config ) в том репозитории, который вы используете в данный момент, хранит настройки конкретного репозитория.

Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig .

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME ( C:\Users\$USER для большинства пользователей).

Имя пользователя

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

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

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

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config —list , чтобы показать все настройки, которые Git найдёт:

Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например, из /etc/gitconfig и

/.gitconfig ). В этом случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config :

Как получить помощь?

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

Например, так можно открыть руководство по команде config

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

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

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

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

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

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

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

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

Эта команда создаёт директорию libgit2 , инициализирует в ней поддиректорию .git , скачивает все данные для этого репозитория и создаёт рабочую копию последней версии.

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

Эта команда делает всё то же самое, что и предыдущая, только результирующий каталог будет назван mylibgit .

Запись изменений в репозиторий

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

Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged).

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

Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения (commit).

Определение состояния файлов

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

Это означает, что у вас чистый рабочий каталог, другими словами – в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. Наконец, команда сообщает вам на какой ветке вы находитесь и сообщает вам, что она не расходится с веткой на сервере.

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

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

Отслеживание новых файлов

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

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

Вы можете видеть, что файл проиндексирован по тому, что он находится в секции «Changes to be committed». Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния.

Команда git add принимает параметром путь к файлу или каталогу; если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.

Индексация изменённых файлов

Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл CONTRIBUTING.md и после этого снова выполните команду git status , то результат будет примерно следующим:

Файл CONTRIBUTING.md находится в секции «Changes not staged for commit» — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Выполним git add , чтобы проиндексировать CONTRIBUTING.md , а затем снова выполним git status :

Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

Что за чёрт? Теперь CONTRIBUTING.md отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add .

Если вы выполните коммит сейчас, то файл CONTRIBUTING.md попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:

Сокращенный вывод статуса

Вывод команды git status довольно всеобъемлющий и многолословный. Git также имеет флаг вывода сокращенного статуса, так что вы можете увидеть изменения в более компактном виде. Если вы выполните git status -s или git status —short вы получите гораздо более упрощенный вывод.

Новые, неотслеживаемые файлы помечены ?? слева от них, файлы добавленные в отслеживаемые помечены A , отредактированные файлы помечены M и так далее. В выводе содержится два столбца (с именем файла — три). В первом указывается статус файла, а во втором модифицирован ли он после этого.

• M README – файл модифицирован, но не проиндексирован
• MM Rakefile – файл модифицирован, проиндексирован и еще раз модифицирован
• A lib/git.rb – новый файл в проекте
• M lib/simplegit.rb – модифицирован, проиндексирован
• ?? LICENSE.txt – новый неотслеживаемый файл

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

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

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

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

К шаблонам в файле .gitignore применяются следующие правила:

• Пустые строки, а также строки, начинающиеся с #, игнорируются.
• Можно использовать стандартные glob шаблоны.
• Можно начать шаблон символом слэша (/) чтобы избежать рекурсии.
• Можно заканчивать шаблон символом слэша (/) для указания каталога.
• Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.

Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ (*) соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса (?) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом (9), соответствуют любому символу из интервала (в данном случае от 0 до 9). Вы также можете использовать две звёздочки, чтобы указать на вложенные директории: a/**/z соответствует a/z, a/b/z, a/b/c/z, и так далее.

Вот ещё один пример файла .gitignore:

Коммит изменений

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

Эта команда откроет выбранный вами текстовый редактор (устанавливается системной переменной $EDITOR — обычно это vim или emacs, хотя вы можете установить ваш любимый с помощью команды git config —global core.editor ).

В редакторе будет отображён следующий текст (это пример окна Vim’а):

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

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

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

Индексация в момент коммита

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

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

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

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

Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :

Затем, если вы выполните команду git rm, удаление файла попадёт в индекс:

После следующего коммита файл исчезнет и больше не будет отслеживаться.

Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске, и убрать его из-под бдительного ока Git. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами. Чтобы сделать это, используйте опцию —staged (или —cached ):

В команду git rm можно передавать файлы, каталоги или glob-шаблоны. Это означает, что вы можете вытворять что-то вроде:

Обратите внимание на обратный слэш (\) перед *. Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы имеющие расширение .log находящиеся в директории log/. Или же вы можете сделать вот так:

Эта команда удаляет все файлы, чьи имена заканчиваются на

Переименование файлов

Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:

Это эквивалентно выполнению следующих команд:

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

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

Эта команда использует для дополнения коммита ваш индекс (staged). Если вы ничего не меняли с момента последнего коммита (например, команда запущена сразу после предыдущего коммита), то снимок состояния останется в точности таким же, а изменится лишь комментарий к коммиту.

Запустится тот же редактор комментария к коммиту, но уже с комментарием к предыдущему коммиту. Комментарий можно отредактировать точно так же, как обычно, просто он заменит собой предыдущий.

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

В итоге получится единый коммит — второй коммит заменит результаты первого.

Удаление файла из индекса

Cкажем, вы изменили два файла, и хотите закоммитить их двумя раздельными изменениями, но случайно набрали git add . , и добавили оба в индекс (staging area). Как отменить добавление одного из них? Команда git status напомнит вам:

Прямо под текстом «Changes to be committed» говорится: git reset HEAD . для отмены добавления в индекс. Давайте последуем этому совету, и отменим индексирование файла CONTRIBUTING.md :

Файл CONTRIBUTING.md изменен, но снова не добавлен в индекс.

Отмена изменения измененного файла

Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md ? Как можно просто «разызменить» его — вернуть к тому виду, который был в последнем коммите? Нам повезло, что git status рассказывает и это тоже. В последнем примере вывод git status был таким:

Здесь довольно ясно указано, как отбросить сделанные изменения. Давайте так и сделаем:

Как видите, откат изменений выполнен.

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

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

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

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум «origin» — имя по умолчанию для исходного репозиториясразу после клонирования:

Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

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

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

Для того, чтобы добавить удалённый репозиторий и присвоить ему имя ( shortname ), просто выполните команду git remote add [shortname] [url] :

Теперь вместо указания полного пути вы можете использовать pb. Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :

Ветка master из репозитория Пола сейчас доступна вам под именем pb/master .

Получение изменений из удалённого репозитория

Для получения данных из удалённых проектов, следует выполнить:

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

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

Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если у вас есть ветка, настроенная на отслеживание удалённой ветки, то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветви и слить их со своей текущей ветвью. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master ).

Выполнение git pull , как правило, извлекает ( fetch ) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить ( merge ) их с кодом, над которым вы в данный момент работаете.

Отправка изменений в удаленный репозиторий

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

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

Просмотр удаленного репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [remote-name] . Выполнив эту команду с некоторым именем, например, origin, вы получите результат, аналогичный следующему:

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master , выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

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

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

Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как pb/master , теперь стало paul/master .

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

Источник