git add
В Git и других системах управления версиями концепция сохранения проработана более детально, чем в текстовых процессорах или других традиционных приложениях для редактирования файлов. Традиционный термин «сохранение» в программировании синонимичен понятию коммита в Git. Коммит в Git является эквивалентом сохранения. Традиционное сохранение — это операция файловой системы, которая используется для перезаписи существующего файла или записи нового. В отличие от нее, коммит Git выполняется над набором файлов и каталогов.
Процессы сохранения в Git и SVN также отличаются. Коммиты, или «фиксации», в SVN — это операции передачи на централизованный удаленный сервер. Это означает, что для «сохранения» изменений в проекте коммитам SVN необходим доступ в Интернет. Коммиты Git можно создавать и выполнять локально, а затем по мере необходимости отправлять на удаленный сервер с помощью команды git push -u origin main . Различие этих двух методов объясняется фундаментальными отличиями в архитектуре. В Git реализована модель распределенного приложения, а в SVN — модель централизованного приложения. Обычно распределенные приложения более устойчивы, поскольку не имеют единой точки отказа, такой как централизованный сервер.
В Git имеется дополнительный механизм сохранения, который называется «stash». Stash — это временная область для хранения изменений, не готовых к коммиту. Команда stash работает с рабочим каталогом (первым из трех деревьев) и имеет множество вариантов применения. Подробнее см. на странице команды git stash .
Репозиторий Git можно настроить на игнорирование определенных файлов или каталогов. В этом случае Git не будет сохранять изменения в игнорируемом контенте. В Git имеется несколько способов настройки для управления списком игнорирования. Более подробно настройка игнорирования в Git рассматривается на странице git ignore .
git add
Команда git add добавляет изменение из рабочего каталога в раздел проиндексированных файлов. Она сообщает Git, что вы хотите включить изменения в конкретном файле в следующий коммит. Однако на самом деле команда git add не оказывает существенного влияния на репозиторий: изменения регистрируются в нем только после выполнения команды git commit .
Наряду с этими командами вам понадобится команда git status , которая показывает состояние рабочего каталога и раздела проиндексированных файлов.
Порядок действий
Команды git add и git commit составляют основу рабочего процесса Git. Эти две команды должен изучить и понимать каждый пользователь Git, независимо от модели совместной работы, принятой в его команде. Эти команды используются для записи версий проекта в историю репозитория.
Работа над проектом ведется по стандартной схеме «редактирование — индексирование — коммит». Сначала вы редактируете файлы в рабочем каталоге. Когда вы будете готовы сохранить копию текущего состояния проекта, вы индексируете изменения командой git add . Затем вы вызываете команду git commit , которая добавляет проиндексированный снимок состояния в историю проекта. Для отмены коммита или проиндексированного снимка состояния используется команда git reset .
Для полноценного процесса совместной работы в Git помимо git add и git commit необходима третья команда — git push . git push используется для отправки подтвержденных изменений в удаленные репозитории для совместной работы, чтобы к набору сохраненных изменений могли получить доступ другие участники команды.
Команду git add не следует путать с командой svn add , которая добавляет файл в репозиторий. git add работает на более абстрактном уровне изменений. Это означает, что команду git add необходимо вызывать при каждом изменении файла, тогда как svn add вызывается для каждого файла только один раз. Это может показаться избыточным, но такой рабочий процесс облегчает поддержание порядка в проекте.
Раздел проиндексированных файлов
Основное назначение команды git add состоит в переносе ожидающих изменений из рабочего каталога в раздел проиндексированных файлов Git . Раздел проиндексированных файлов — это уникальная возможность Git, и если вы прежде работали с SVN (или даже с Mercurial), вам потребуется некоторое время, чтобы освоить ее. Этот раздел удобно рассматривать как буфер между рабочим каталогом и историей проекта. Раздел проиндексированных файлов является одним из «трех деревьев» Git, наряду с рабочим каталогом и историей коммитов.
Вместо того чтобы подтверждать все изменения, внесенные после последнего коммита, вы можете сгруппировать связанные изменения в определенные снимки состояний в разделе проиндексированных файлов, прежде чем выполнять их коммит в историю проекта. Это означает, что вы можете внести различные изменения в несвязанные файлы, а затем вернуться назад и разбить их на логические коммиты (добавляя в раздел проиндексированных файлов связанные изменения и поэтапно выполняя коммиты для отдельных групп изменений). В Git, как и в любой системе контроля версий, важно создавать мелкие коммиты, чтобы можно было легко отслеживать ошибки и отменять изменения с минимальным влиянием на остальной проект.
Распространенные опции
Проиндексировать все изменения в файле file> для следующего коммита.
Проиндексировать все изменения в каталоге directory> для следующего коммита.
Начать интерактивный сеанс индексирования, во время которого вы сможете выбрать части файла, которые будут добавлены в следующий коммит. Команда представит фрагмент изменений и предложит вам ввести команду. Введите y , чтобы проиндексировать фрагмент; n , чтобы игнорировать фрагмент; s , чтобы разбить его на более мелкие фрагменты; e , чтобы вручную отредактировать фрагмент; q , чтобы завершить работу с командой.
Примеры
Когда вы только начинаете новый проект, команда git add выполняет ту же функцию, что и svn import . Чтобы создать первичный коммит текущего каталога, используйте следующие две команды:
После того как начнется работа над проектом, можно будет добавить новые файлы, указав путь в команде git add :
Приведенную выше команду можно также использовать для регистрации изменений в существующих файлах. Вспомним, что Git не различает индексацию изменений в новых файлах и в файлах, которые уже добавлены в репозиторий.
Резюме
Подведем итоги. Команда git add — это первая команда в цепочке операций, предписывающей Git «сохранить» снимок текущего состояния проекта в истории коммитов. Когда git add используется как отдельная команда, она переносит ожидающие изменения из рабочего каталога в раздел проиндексированных файлов. Команда git status проверяет текущее состояние репозитория; с ее помощью можно убедиться, что команда git add добавила нужные изменения. Команда git reset используется для отмены команды git add . Команда git commit сохраняет снимок состояния из раздела проиндексированных файлов в истории коммитов репозитория.
Работа с git
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.
Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией.
Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта.
Рассмотрим пример: У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.
Запись изменений в репозиторий (commit)
Допустим, у вас имеется репозиторий Git и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать состояния этих изменений (commit) в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить. Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (не отслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть не измененными, измененными или подготовленными к коммиту (staged). Все изменения в них, будут отслеживаться. Не отслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемые и не измененные, потому что вы только взяли их из хранилища и ничего пока не редактировали. Как только вы отредактируете файлы, Git будет рассматривать их как измененные, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете (делаете коммит) все индексированные изменения.
Что такое ветка?
Ветка (или «branch») — это своеобразное «место» разработки. Например, после клонирования репозитория мы по-умолчанию находимся в ветке master, создаём ветку test (в которую будет всё слито из master), затем делаем в ней какие-то изменения, делаем коммит, а потом переключиться обратно в ветку master. С помощью команды
в каждой из веток, можно будет посмотреть все коммиты. В ветке master вы увидите, что ваш коммит из test на ветку не распространяется, и те файлы, которые вы изменили в ветке test будут возвращены к состоянию последнего коммита в ветке master. Таким образом ветка — это что-то вроде текущего состояния вашей разработки.
Работа с git-репозиториями, сведения для начинающих
Настройка git
Первым делом настроим ваше имя и адрес почты. Имя вводите на английском.
Ключ —global задаёт сохранение данных для всех репозиториев. Без —global настройки будут сохранены в текущем репозитории. Затем настроим правильное отображение цветов:
После этого нужно настроить доступ
Работа с локальным репозиторием
Клонирование репозитория
Чтобы начать работать с репозиторием, следует создать копию проекта со всей его историей локально. Нужно создать каталог Projects, перейти в него, а затем клонировать удалённый репозиторий:
После этой процедуры репозиторий скопируется в папку wine-test (можно не указывать, тогда репозиторий скопируется в папку, соответствующую названию перед «.git» — в нашем случае это будет wine-public-tests). Если выполнять клонирование с помощью:
то у вас не будет прав на запись, т.е. вы не сможете пушить (опубликовывать) коммиты.
Определение состояния файлов
Основная команда, используемая для определения какие файлы в каком состоянии находятся — это команда 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 add — многофункциональная команда, она используется для добавления отслеживаемых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния.
вносит в индексе все изменения, включая все обновлённые и новые файлы
Удаление файлов из индекса. Добавление удалённых файлов в индекс
- Удаление файла из индекса: Если вы внесли изменения в два файла и хотите сделать коммит с одним из них, но случайно набрали git add . и проиндексировали оба файла, то вам поможет команда git reset:
После неё текущее состояние вашего файл останется низменным, но он не будет занесён в индекс.
- Добавление удалённого файла: Если вы просто удалите файл из каталога, он будет показан в секции “Changed but not updated” команды git status, т.е. он будет не проиндексирован. Чтобы добавить удаление в индекс Git, то после удаления файла, выполните команду:
- Если у вас большое количество удалённых, но не добавленных в индекс файлов, то вы можете добавить их командой:
- Если вы хотите удалить файл из индекса и сделать его не отслеживаемым, но при этом оставить его в каталоге, то выполните:
Отмена текущих изменений в файле
Если вы поняли, что не хотите оставлять изменения внесённые в файл, то вернуть то состояние, в котором находился файл во время последнего коммита, выполните:
Будьте осторожны, т.к. все сделанные вами изменения в этом файле пропадут.
Просмотр (не)индексированных изменений
Если вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff. Допустим, вы снова изменили «.cpp» файл без индексирования (без git add). Чтобы увидеть, что же вы изменили, но пока не проиндексировали, выполните:
Вы увидите изменения, которые вы внесли в файл. Чтобы просмотреть изменения в файлах, которые вы уже добавили в индекс, выполните:
Работа с ветками
Просмотр списка веток
Чтобы просмотреть список веток, выполните:
после чего, вы увидите имеющиеся ветки
Создание веток
Когда вы создаёте ветку, то она создаёт независимый клон вашей текущей ветки (не индексируемые изменения не клонируются)
Чтобы создать ветку test, не переключаясь в неё, выполните:
Чтобы создать ветку test и переключиться в неё, выполните:
Перемещение по веткам
Чтобы перейти в ветку master, выполните:
Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке, то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f:
Сохранение не индексированных изменений в текущей ветке и переход в другую
Если вы не хотите делать коммит, но вам нужно перейти в другую ветку, не теряя текущих изменений вы должны сделать:
После этого в git diff пропадут ваши изменения и вы можете перейти в другую ветку
Для просмотра сохранённых изменений:
Чтобы применить сохраненные изменения и вернуть рабочее состояние, выполните:
Чтобы удалить конкретный сохранённый стэш, выполните:
Чтобы удалить все сохранённые стэши, выполните:
Удаление ветки
Если у вас нет не индексированных изменений (изменили что-то, но ещё не добавляли в индекс с помощью git add),то удалить ветку можно так:
Если вы хотите удалить ветку, и потерять текущие изменения, то выполните:
Переименование ветки
Переименовать ветку можно так:
Слияние веток и конфликты
Команда попробует объединить текущую ветку и ветку test:
Иногда процесс слияния не идет гладко. Если вы изменили одну и ту же часть файла по-разному в двух ветках, которые собираетесь объединить, Git не сможет сделать это чисто и выдаст конфликт слияния:
Git не создал новый коммит для слияния. Он приостановил этот процесс до тех пор, пока вы не разрешите конфликт. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), можете выполнить команду git status:
Всё, что имеет отношение к конфликту слияния и что не было разрешено, отмечено как unmerged. Git добавляет стандартные маркеры к файлам, которые имеют конфликт, так что вы можете открыть их вручную и разрешить эти конфликты. Ваш файл содержит секцию, которая выглядит примерно так:
В верхней части блока (всё что выше =======) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё что находится в нижней части ― версия в ветке test. Чтобы разрешить конфликт вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Отредактируйте и удалите ====== и >>>>>>>. Затем выполните git add. Индексирование будет означать для Git, что все конфликты в файле теперь разрешены.
Работа с коммитами
Добавление нового коммита, просмотр истории
Теперь, когда ваш индекс настроен так как вам и хотелось, вы можете зафиксировать ваши изменения — сделать коммит. Запомните: всё, что до сих пор не проиндексировано — любые файлы, созданные или измененные вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Выполните команду:
После этого откроется текстовой редактор и будет отображено что-то вроде этого:
Вам нужно будет ввести комментарий для коммита, после чего сохраниться.
Есть ещё другой способ, который позволит ввести комментарий сразу из командной строки:
Есть ещё команда, которая автоматически проиндексирует изменения во всех изменённых файлах проекта. Новые файлы при этом индексироваться не будут, но удаление файлов будет учтено. Т.е. вы можете обойтись без git add.
Можно без параметра «-m», чтобы посмотреть файлы, которые ввойдут в коммит.
Чтобы просмотреть историю коммитов, выполните уже знакомую команду:
Чтобы просмотреть изменения, сделанные в последнем коммите, выполните:
Так же во многих командах можно указывать номер коммита, начиная от верхнего, либо его собственный номер, который можно посмотреть в git log. Например, эта команда покажет третий сверху коммит:
Как видите, в данном случае число в HEAD
, обозначает номер коммита, не учитывая самый последний (верхний).
Создание отменяющего коммита
Если вы сделали коммит с ошибкой, то можно его отредактировать (как это сделать, мы разберём дальше), но делать это нужно лишь в том случае, если вы не опубликовали его в какой-нибудь удалённый репозиторий, с которым работают другие люди. В ином случае лучше создать коммит, который отменит предыдущий и вернёт вас в старое состояние. Как это сделать:
Если вам нужно отменить четвёртый коммит, то выполните:
Сброс состояния проекта, отмена, удаление последних коммитов
Помимо работы с индексом, git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В таком случае вместе с командой используются различные ключи (soft, hard и т.п.).
- —soft :
Команда отменит последний коммит и вернёт вас к тому состоянию, когда вы добавили все нужные изменения в индекс (git add), но ещё не совершили коммит. Команда не сбрасывает текущие индекс и не индексированные изменения. Если до выполнения reset вы добавляли в индекс какие-то файлы, то они войдут в секцию «Changes to be committed»!
Если состояние сбрасывается на несколько коммитов, то плюс ко всему будут добавлены в индекс и их изменения (секция «Changes to be committed»).
- —hard : Удаляет коммит и в любом случае сбросит все индексированные и не индексированные изменения, а так же обновит файлы в директории до состояния нужного коммита, т.е. команда:
удалит два последних коммита и вернёт вас к такому состоянию проекта, если бы вы только что совершили третий сверху коммит.
- —mixed : (она же просто git reset): Тоже самое, что и soft, только при этом сбрасываются изменения занесённые в индекс (git add)
- —merge :
Команда работает в том случае, если у вас нет не индексированных изменений тех файлов, которые изменяются в двух последних коммитах.
Отменяются два последних коммита. Сбрасывается индекс и обновляются файлы в директории до состояния третьего коммита сверху. При этом сохраняются изменения в файлах, которые не добавлялись в индекс (не git add).
Редактирование последнего коммита
- Если вы что-то напутали с комментарием к последнему коммиту, выполните команду и поменяйте комментарий:
Если сразу после совершения коммита, вы ничего не добавляли в индекс (git add), то следуйте инструкции. В ином случае, вам придётся удалить из него ненужные файлы:
- Если вы сделали не все изменения, или забыли добавить в коммит какие-то файлы, то выполните нужные действия, а потом добавьте эти файлы в индекс (git add), затем снова выполните $ git commit —amend и сохраните изменения.
Редактирование нескольких или какого-то одного коммита из истории
Допустим, вам надо отредактировать 3 последних коммита, выполните:
Команда выполнится в интерактивном режиме. Можно заметить, что в данном случае, число в команде HEAD
включает в себя самый верхний коммит. Откроется редактор, который отобразит нечто подобное:
Обратите внимание, что первым идёт коммит, который является самым старым из выбранных вами коммитов!
Для того, чтобы отредактировать нужный коммит, замените перед номером коммита слово pick на edit. Когда вы сохраните изменения и выйдите из редактора, Git вернёт вас к первому из тех коммитов, которые вы хотите отредактировать. В итоге вы увидите такое:
Далее делаем нужные изменения, добавляем изменения в индекс (git add), а затем выполняем, как указано в инструкции, команду git commit —amend. После этого, выполняем:
После чего, Git автоматически применит следующие коммиты. Если у вас несколько редактируемых коммитов, то вам снова придётся выполнить то, о чем я писал выше. В итоге Git покажет всё ли удачно применилось.
Редактирование комментария к коммиту
Если, например, надо исправить комментарий к 6 сверху коммиту, то выполняем:
Затем меняем у нужного коммита pick на reword. Исправляем комментарий, сохраняемся, выходим. Git автоматически должен всё поменять.
Изменение порядка коммитов. Удаление коммитов
Изменение порядка коммитов в некоторых случаях может привести к большим проблемам, поэтому стоит задуматься — так уж необходимо менять коммиты местами?
Выбираем нужный диапазон коммитов, например — последние шесть ,и делаем:
Меняем строчки нужных коммитов местами, только не забудьте что первыми идут более старые коммиты, сохраняемся и выходим.
Чтобы удалить ненужный коммит, просто удаляем строчку с коммитом.
Слияние коммитов в один
Выбираем нужный диапазон коммитов, например — последние 6, и решаем слить три каких-нибудь коммита в один:
Затем меняем pick на squash у нужных коммитов, сохраняем, выходим и видим что-то наподобие:
Если хотите, можно оставить только один комментарий, который будет у нового коммита, для этого нужно оставить комментарий после
а в остальных коммит мессаджах убрать.
Разбиение коммита на несколько
Предположим, что вы хотите разбить какой-то коммит в последних шести на несколько. Как всегда, выполняем:
Меняем у нужного коммита pick на edit. После этого делаем:
Эта команда отменяет коммит, который вы собираетесь разбивать и убирает из индекса все изменённые файлы. Вам остаётся только добавить файлы с нужными изменениями (git add), затем сделать коммит. Потом снова добавить нужные файлы, и снова сделать коммит. И так до тех пор, пока вы не разобьёте свой коммит на необходимое колличество коммитов. После этого нужно выполнить:
Всё это будет выглядеть примерно так:
Перенос коммитов из другой ветки
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера; либо сам разработчик совершал в ней коммиты. В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков. Предположим, имеется две ветки: master и test, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки test и накладывает их на последний коммит ветки master: вариант, в котором явно указывается, что и куда прикладывается
А здесь на master накладывается ветка, активная в настоящий момент :
После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой
Альтернативными выходами будут команды
пропустить наложение коммита и перейти к следующему или
отмена работы команды и всех внесенных изменений.
С ключом -i (—interactive) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.
Работа с удалённым репозиторием
Удалённый репозиторий — это модификация проекта, которая хранится в интернете или ещё где-то в сети. УР обычно доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя помещение (push) и получение (pull) данных и из них тогда, когда нужно обменяться результатами работы.
Отображение удалённых репозиториев
Чтобы просмотреть какие удалённые серверы у вас уже настроены, следует выполнить команду
Она перечисляет весь список имён-сокращений (псевдонимов) удалённых репозиториев, созданных в текущем репозитории. Если вы склонировали ваш репозиторий, у вас должен отобразиться по крайней мере origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали.
Чтобы посмотреть какому URL соответствует сокращённое именя в Git, можно указать команде опцию -v:
Если у вас больше одного удалённого репозитория, команда покажет их все.
Создание и добавление удалённого репозитория
Создадим пустой удалённый репозиторий:
Имя лучше указывать такое же как у репозитория, который вы cклонировали.
Чтобы добавить УР под именем-сокращением, выполните:
Так же можно указывать адрес локального репозитория.
Забрать изменения из удалённого репозитория
- Например, если вы хотите извлечь (fetch) всю информацию, которая есть в каком-то удалённом репозитории, но нет в вашем, вы можете выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты. Ветка 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 коммита:
Если надо, чтобы в тему письма включался номер патча в серии, можно использовать параметр -n:
В результате получится нечто вроде:
Слово патч можно заменить на любое другое с помощью параметра —subject-prefix:
Сгенерированные патчи можно отправить по почте с помощью команды
Для подключения(приложения) патча следует пользоваться командой
Если в процессе приложения патча произошла ошибка, то при обновлении репозитория (pull) может появиться ошибка:
Для избежания этой ошибки после неудачного приложения патча следует осуществить следующую команду:
Простое руководство по работе с git
Ваш локальный git репозиторий состоит из трех «сущностей». Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area), содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали.
Подготовка и коммит
Чтобы подготовить изменения (добавить их в Индекс), используйте
git add <имя_файла>
git add *
Это первый шаг в основном рабочем процессе. Сделать коммит подготовленных изменений можно командой
git commit -m «Описание коммита»
Теперь изменения закреплены в локальном репозитории, и на них указывает HEAD, но еще не в удаленном репозитории.
Отправка изменений
Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните
git push origin master
Можно изменить master на любую другую ветвь, чтобы отправить изменения на неё.
Если вы еще не клонировали существующий репозиторий и хотите подключить ваш к удаленному, вам нужно добавить его, выполнив
git remote add origin <адрес_сервера>
Теперь вы можете отправлять изменения на удаленный репозиторий
Ветвление
Ветки используются для разработки функциональности, изолированной от остальной. Ветка master используется по умолчанию, когда вы создаете репозиторий. Используйте другие ветки для разработки и слияние в master, когда разработка завершена.
Создать новую ветку с названием «feature_x» и переключиться на неё можно командой
git checkout -b feature_x
переключиться обратно на master
git checkout master
удалить ветку
git branch -d feature_x
ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием, пока вы не отправите её туда
git push origin <имя_ветки>
Обновление и слияние
Обновить ваш локальный репозиторий можно командой
git pull
которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
Для того чтобы слить другую ветку с активной (например master), используйте команду
git merge <имя_ветки>
В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов, путем ручного редактирования файлов, указанных git. После изменений вам надо пометить их как слитые
git add <имя_файла>
перед слиянием вы можете предварительно посмотреть на изменения
git diff <имя_ветки> <имя_другой_ветки>
Метки
Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая также используется в SVN. Создать новую метку с именем 1.0.0 можно, выполнив
git tag 1.0.0 1b2e1d63ff
1b2e1d63ff это первые десять цифр уникального идентификатора (id), с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
git log
Можно использовать меньшее количество символов в качестве идентификатора, с учетом того, что он является уникальным.
Замена локальных изменений
В случае, если вы сделали что-то не то, вы можете заменить локальные изменения, используя команду
git checkout — <имя_файла>
произойдет замена изменений в вашем рабочем каталоге, на то, что сейчас находится в HEAD. Изменения, уже внесенные в индекс, также как и новые файлы, будут сохранены.
Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
git fetch origin
git reset —hard origin/master
Начало работы с Git: подробный гайд для новичков
Привет тебе, будущий Senior Software Engineer. Сегодня поговорим о системе контроля версий, а именно о Git (читается как ГИТ, а не ДЖИТ, как могло бы показаться из грамматики английского языка). Да-да, я знаю что есть еще и Mercurial, SVN… Но будем откровенны: их время уже ушло, и тратить ваше драгоценное время на них не собираюсь. Чтобы вы понимали важность знания гита в наше время, скажу так: без знания/понимания этого вам делать в программировании нечего. Но прелесть в том, что для постоянной работы не нужно держать в голове все команды и возможности. Нужно знать набор команд, которые помогут понимать всё, что происходит.
Основы Git
Установка Git
Установка для Windows
Как обычно, нужно скачать exe файл и запустить его. Здесь все просто: жмем на первую ссылку гугла, устанавливаем и всё. Для работы будем использовать bash консоль, которую они предоставляют. Чтобы работать в виндоусе, нужно запустить Git Bash. Вот как он выглядит в меню пуск: 
И это уже консоль, в которой можно работать. Чтобы не переходить каждый раз в папку с проектом, чтобы там открыть гит, можно в папке правой кнопкой мыши открыть консоль с нужным нам путем: 
Установка для Linux
Установка на macOS
Настройка гита
Немного теории…
- гит репозиторий (git repository);
- коммит (commit);
- ветка (branch);
- смерджить (merge);
- конфликты (conflicts);
- спулить (pull);
- запушить (push);
- как игнорировать какие-то файлы (.gitignore).
Состояния в Гит
- неотслеживаемое (untracked);
- измененное (modified);
- подготовленное (staged);
- закомиченное (committed).
Как это понимать?
- Файл, который создан и не добавлен в репозиторий, будет в состоянии untracked.
- Делаем изменения в файлах, которые уже добавлены в гит репозиторий — находятся в состоянии modified.
- Из тех файлов, которые мы изменили, выбираем только те (или все), которые нужны нам (например, скомпилированные классы нам не нужны), и эти классы с изменениями попадают в состояние staged.
- Из заготовленных файлов из состояния staged создается коммит и переходит уже в гит репозиторий. После этого staged состояние — пустое. А вот modified еще может что-то содержать.
Что такое коммит
- уникальный идентификатор коммита, по которому можно его найти;
- имя автора коммита, который создал его;
- дата создания коммита;
- комментарий, который описывает, что было сделано во время этого коммита.
Что такое ветка
Ветка — это указатель какого-то коммита. Так как коммит знает, какой коммит был до него, когда ветка указывает на какой-то коммит, к ней относятся и все те предыдущие. Исходя из этого можно сказать, что веток, указывающих на один и тот же коммит, может быть сколько угодно много. Работа происходит в ветках, поэтому когда создается новый коммит, ветка переносит свой указатель на более новый коммит.
Начало работы с Гитом
Работа с гитом в локальном репозитории
- git add -A — добавить все файлы из состояния в staged;
- git add . — добавить все файлы из этой папки и все внутренних. По сути тоже самое, что и предыдущее;
- git add <имя файла> — добавляет только конкретный файл. Здесь можно пользоваться регулярными выражениями, чтобы добавлять по какому-то шаблону. Например, git add *.java: это значит, что нужно добавить только файлы с расширением java.
Работа с .gitignore
- первая строка — это игнорирование всех файлов с расширением .class;
- вторая строка — это игнорирование папки target и всего, что она содержит;
- третья строка — это игнорирование всех файлов с расширением .iml;
- четвертая строка — это игнорирование папки .idea.
Работа с ветками и иже с ним
- создать новую ветку на основе той, на которой находимся (99% случаев);
- создать ветку на основе конкретного коммита (1%).
Создаем ветку на основе конкретного коммита
Опираться будем на уникальный идентификатор коммита. Чтобы найти его, напишем: 
Я выделил коммит с комментарием “added hello world…”. У него уникальный идентификатор — “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Я хочу создать ветку development начиная с этого коммита. Для этого напишу: Создается ветка, в которой будут только первые два коммита из ветки master. Чтобы проверить это, мы сперва убедимся, что перешли в другую ветку и посмотрим на количество коммитов ней: 
И правда: получилось, что у нас два коммита. Кстати, интересный момент: в этой ветке еще нет файла .gitignore, поэтому наш скомпилированный файл (GitTest.class) теперь подсвечивается в untracked состоянии. Теперь можем провести еще раз ревизию наших веток, написав: 
Видно, что есть две ветки — master и development — и сейчас стоим на development.
Создаем ветку на основе текущей
- git checkout master — переходим на ветку master;
- git status — проверяем, точно ли на мастере.
Резолвим конфликты
- между “<<<<<<< HEAD” и “=======” находятся изменения мастер, которые были в этой строке в мастер ветке.
- между “=======” и “>>>>>>> feature/add-header” находятся изменения, которые были в feature/add-header ветке.
Работа с удаленными репозиториями
GitHub — это крупнейшее хранилище для репозиториев и совместной разработки. Я уже описывал его в предыдущих статьях.
Подписывайтесь на мой гитхаб аккаунт. Я часто выставляю там свои наработки в тех сферах, которые изучаю во время работы.
GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайн и другими функциями.
После новости о том, что Microsoft купила GitHub, некоторые разработчики продублировали свои наработки в GitLab.
BitBucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git. Одно время имел большое преимущество перед GitHub в том, что у него были бесплатные приватные репозитории. В прошлом году GitHub также открыл эту возможность для всех бесплатно.