Git branch vv что это

3.3 Ветвление в Git — Управление ветками

Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.

Команда git branch делает несколько больше, чем просто создаёт и удаляет ветки. При запуске без параметров, вы получите простой список имеющихся у вас веток:

$ git branch iss53 * master testing

Обратите внимание на символ * , стоящий перед веткой master : он указывает на ветку, на которой вы находитесь в настоящий момент (т. е. ветку, на которую указывает HEAD ). Это означает, что если вы сейчас сделаете коммит, ветка master переместится вперёд в соответствии с вашими последними изменениями. Чтобы посмотреть последний коммит на каждой из веток, выполните команду git branch -v :

$ git branch -v iss53 93b412c Fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 Add scott to the author list in the readme

Опции —merged и —no-merged могут отфильтровать этот список для вывода только тех веток, которые слиты или ещё не слиты в текущую ветку. Чтобы посмотреть те ветки, которые вы уже слили с текущей, можете выполнить команду git branch —merged :

$ git branch --merged iss53 * master

Ветка iss53 присутствует в этом списке потому что вы ранее слили её в master . Те ветки из этого списка, перед которыми нет символа * , можно смело удалять командой git branch -d ; наработки из этих веток уже включены в другую ветку, так что ничего не потеряется.

Чтобы увидеть все ветки, содержащие наработки, которые вы пока ещё не слили в текущую ветку, выполните команду git branch —no-merged :

$ git branch --no-merged testing

Вы увидите оставшуюся ветку. Так как она содержит ещё не слитые наработки, попытка удалить её командой git branch -d приведёт к ошибке:

$ git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'.

Если вы действительно хотите удалить ветку вместе со всеми наработками, используйте опцию -D , как указано в подсказке.

Если в качестве аргумента не указан коммит или ветка, то опции —merged и —no-merged покажут что уже слито или не слито с вашей текущей веткой соответственно.

Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.

$ git checkout testing $ git branch --no-merged master topicA featureB

Переименование ветки

Не переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».

Предположим, у вас есть ветка с именем bad-branch-name , и вы хотите изменить её на corrected-branch-name , сохранив при этом всю историю. Вместе с этим, вы также хотите изменить имя ветки на удалённом сервере (GitHub, GitLab или другой сервер). Как это сделать?

Переименуйте ветку локально с помощью команды git branch —move :

$ git branch --move bad-branch-name corrected-branch-name

Ветка bad-branch-name будет переименована в corrected-branch-name , но это изменение пока только локальное. Чтобы все остальные увидели исправленную ветку в удалённом репозитории, отправьте её туда:

$ git push --set-upstream origin corrected-branch-name

Теперь проверим, где мы сейчас находимся:

$ git branch --all * corrected-branch-name main remotes/origin/bad-branch-name remotes/origin/corrected-branch-name remotes/origin/main

Обратите внимание, что текущая ветка corrected-branch-name , которая также присутствует и на удалённом сервере. Однако, старая ветка всё ещё по-прежнему там, но её можно удалить с помощью команды:

$ git push origin --delete bad-branch-name

Теперь старое имя ветки полностью заменено исправленным.

Изменение имени главной ветки

Предупреждение

Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.

Переименуйте локальную ветку master в main с помощью следующей команды:

$ git branch --move master main

После этого, локальной ветки master больше не существует, потому что она была переименована в ветку main .

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

$ git push --set-upstream origin main

В итоге, состояние репозитория становится следующим:

$ git branch --all * main remotes/origin/HEAD -> origin/master remotes/origin/main remotes/origin/master

Ваша локальная ветка master исчезла, так как она заменена веткой main . Ветка main доступна в удалённом репозитории. Старая ветка master всё ещё присутствует в удалённом репозитории. Остальные участники будут продолжать использовать ветку master в качестве основы для своей работы, пока вы не совершите ряд дополнительных действий.

Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:

• Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.
• Обновите конфигурацию всех запускаемых тестов.
• Исправьте скрипты сборки и публикации артефактов.
• Поправьте настройки репозитория на сервере: задайте новую ветку по умолчанию, обновите правила слияния, а также прочие настройки, которые зависят от имени веток.
• Обновите документацию, исправив ссылки, указывающие на старую ветку.
• Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.

После того, как вы выполнили все эти задачи и уверены, что ветка main работает так же, как ветка master , вы можете удалить ветку master :

$ git push origin --delete master

3.5 Ветвление в Git — Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространённым способом является использование веток слежения.

Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удалённым репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.

Имена веток слежения имеют вид / . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .

Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.

Примечание
«origin» — это не специальное название

Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .

Рисунок 30. Серверный и локальный репозитории после клонирования

Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.

Рисунок 31. Локальная и удалённая работа может расходиться

Для синхронизации ваших изменений с удалённым сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.

Рисунок 32. git fetch обновляет ветки слежения

Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add , как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.

Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки

Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone , которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin , Git ничего не получит, но создаст ветку слежения с именем teamone/master , которая будет указывать на тот же коммит, что и ветка master на сервере teamone .

Рисунок 34. Ветка слежения teamone/master

Отправка изменений

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

Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.

Примечание
Не вводите каждый раз свой пароль

Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.

Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .

Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.

Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b / . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .

Если у вас уже есть локальная ветка и вы хотите настроить её на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Примечание
Сокращение Upstream

Если у вас настроена отслеживаемая ветка, вы можете ссылаться на неё с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .

Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удалённую ветку.

Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:

$ git fetch --all; git branch -vv

Получение изменений

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

Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.

Удаление веток на удалённом сервере

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

Работа с ветками в GIT

Чтобы исправить баг или сделать новую фитчу в проекте, обычно создают новую ветку. Зачем? Чтобы избежать путаницы. Если бы все делалось в основной ветке, в проекте было бы сложно разобраться, особенно если над ним одновременно работает много людей.
Поэтому только по окончании работы над задачей изменения в ветке сливают в основную ветку master.

Создание ветки

Чтобы создать новую ветку testing локально, выполним команду:

$ git branch testing

На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.

Переключение на ветку

Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:

$ git checkout testing

Имейте в виду, что GIT не позволит перейти на другую ветку, если в текущей ветке — в которой мы находимся — есть изменения, которые не зафиксированы (commit) либо не спрятаны (stash). Это нормально, ведь при смене ветке в текущем каталоге сменятся файлы, и git-у надо знать, как быть с текущими изменениями.

Создание и переключение единой командой

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

$ git checkout –b testing

Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.

Как переключиться на чью-то ветку из удаленного репозитория

Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой — вы создаете локальную копию чужой ветки, и над ней уже работаете.

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

git fetch

Теперь можно посмотреть, какие ветки есть в удаленном репозитории:

git branch -v -a

Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:

git checkout -b dev1 origin/dev1

Вообще-то можно было написать проще:

git checkout dev1

1. Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
2. Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:

git checkout -b mydev1 origin/dev1

Как создать подветку ветки

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

Предыдущая команда, с помощью которой мы создавали ветку:

$ git branch testing

создает ответвление от основной ветки master.

Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:

$ git checkout testing $ git checkout -b subbranch_of_testing testing

Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.

Как посмотреть ветки

Чтобы увидеть все созданные локально ветки, выполним команду:

$ git branch

Появится список веток. Текущая ветка будет выделена звездочкой.

Как переименовать ветку

Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.

Локальную

Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

Чтобы переименовать локальную ветку, выполним команду:

$ git branch -m

Например, переименуем ветку testing в ветку test:

$ git branch –m testing test

Чтобы переименовать текущую ветку, выполним команду:

$ git branch -m

Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

$ git branch –m subbranch

Удаленную

Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:

$ git push origin :old-name new-name

здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),
old-name — имя ветки локальной ветки,
new-name — новое имя ветки в удаленном репозитории.

Например, надо переименовать ветку testing в test:

$ git push origin :testing test

Удаление локальной ветки

Чтобы удалить локальную ветку, выполните одну из команд:

$ git branch -d branch_name $ git branch -D branch_name

Флаги:
-D сокращение для —delete –force удаляет ветку независимо от того, слиты ли ее изменения
-d сокращение для —delete
Например, удалим локальную ветку test:

$ git branch –d test

Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.

Удаление ветки из удаленного репозитория

Чтобы удалить удаленную ветку, можно использовать две записи.
Либо через двоеточие, как мы уже делали при переименовании ветки:

$ git push origin :branch_name

Например, удалим ветку test из удаленного репозитория origin:

$ git push origin :test

Либо с флагом —delete, так понятнее:

$ git push origin --delete test

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

Как слить ветки

Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):

$ git checkout master

А затем выполним слияние. Допустим, в ветку master надо слить ветку test :

$ git merge test

Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.

Итог

В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.

Автор sysout Опубликовано 12.07.2018 11.07.2021 Рубрики Git

Добавить комментарий Отменить ответ

Прошу прощения: на комментарии временно не отвечаю.

23 команды Git, которые должен знать каждый разработчик

Перед вами небольшая статья-шпаргалка, которая включает в себя команды удобные, но не всем знакомые команды Git, которые могут стать вашими постоянными спутниками в разработке.

Вести разработку, кстати, удобно в нашем кластере Kubernetes.

1. git init

Эта команда используется для инициализации проекта как репозитория git.

2. git clone

Эта команда клонирует репозиторий в новую директорию.

git config — это удобная функция, которая используется для настройки значений конфигурации Git на глобальном и локальном уровнях проекта. Примеры команд:

git config —local user.name «Name»

git config —global user.name «Name»

Если надо скопировать только файлы:

git clone —depth=1 git://someserver/somerepo dirformynewrepo

3. git remote add

Эта команда используется для добавления или подключения к удаленному репозиторию.

4. git remote -v

Эта команда используется для просмотра подключенных удаленных репозиториев.

5. git status

Эта команда используется для просмотра статуса файлов в вашем локальном репозитории. Отслеживаются ли файлы? Не отслеживается? Изменены ли они?

Пример: git add index.html

git add index.html style.css style.scss

Эта команда переносит все новые и измененные файлы в раздел проиндексированных файлов

Эта команда используется для индексирования ВСЕХ неустановленных файлов.

для конкретного файла

7. git reset

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

отмена неотправленного коммита: git reset —hard HEAD^

отмена отправленного коммита ( возврат к состояние коммита 7880ae2 )

git reset —hard f7880ae2

git push origin -f

8. git commit

Эта команда совершает коммит — «закрепляет» промежуточные результаты.

git commit -m “Text message”

Пример: git commit -m «added navigation bar»

Команда -m позволяет указать commit message без обращения к редактору

git commit —amend

Команда —amend вносит в предыдущий коммит изменения, которые подготовлены к коммиту. Используется и для редактирования предыдущего commit message, если в нём допущены ошибки.

9. git push -u origin

Ключ -u (полный вариант —set-upstream ) создаёт в удалённом репозитории ветку, соответствующую локальной и связывает их.

Пример: git push -u origin master

Эта команда используется для отправки закоммиченных файлов в удаленный репозиторий (также известный как GitHub) в указанной ветке. Используйте эту команду, когда вы впервые отправляете файлы в удаленный репозиторий. Он зафиксирует место, куда вы отправляете эти файлы. И в следующий раз можно будет использовать команду git push.

10. git fetch

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

Бесплатный тестовый доступ к облаку на 30 днейПолучить

11. git pull

Эта команда используется для извлечения только что полученной информации и ее загрузки в локальный репозиторий. git pull запускает немедленное обновление локального репозитория.

12. git branch Эта команда используется для создания, просмотра переименования и удаления ветки, на которой вы сейчас находитесь.

Эта команда используется для предварительного просмотра всех веток в удаленном репозитории.

Эта команда используется для предварительного просмотра всех веток на сервере.

13. git checkout

Пример: git checkout master или git checkout develop

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

git checkout — ещё один вариант использования

14. git merge

Эта команда используется для объединения двух веток. Для этого укажите ветку, которую вы хотите унаследовать изменения. И имя ветки, которое вы будете использовать вместе с этой командой, — это ветка, которая предоставит изменения.

Пример: git merge develop

Здесь основная ветка наследует код из ветки разработки.

15. git merge — abort

Эта команда используется для отмены слияния.

Если нет ошибок, слияния будут успешными. Следовательно, это прерывание можно использовать только в ситуациях, когда слияние не удалось. Как понять, что нужно использовать эту команду? Ваш терминал скажет, что слияние не удалось. Он также может предложить вам исправить конфликты слияния.

Вот ещё один признак: ~/NextCloud/Documents/Web Projects/Cloud4Y (master)

Посмотрите в самый конец строки. В скобках написано (master). Это потому, что мы находимся в основной ветке. Если вы находитесь в ветке разработки, это будет означать (develop). Если смерджить не получилось, появится надпись (master|merging) или что-то в этом роде.

git merge -X theirs

Пример: git merge -X theirs develop

Эта команда используется для объединения двух веток. И если есть конфликты слияния, эта команда просто предположит, что вы предпочитаете изменения, сделанные в указанной ветке (а не в текущей).

16. git reset — hard HEAD

Эта команда удалит все изменения, внесенные вами в ваш локальный репозиторий, и обновит его до последней версии, которая была закоммичена на GitHub.

17. git reset HEAD^

Эта команда перемещает текущую ветку назад на два коммита, эффективно удаляя два снапшота, которые мы только что создали, из истории проекта. Он отменяет случайное закоммичивание и сохраняет изменения.

18. git clean -f

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

Эта команда используется для удаления неотслеживаемых директорий в вашем локальном репозитории. Вы также можете объединить его с git clean -fd, чтобы сделать и то, и другое.

19. git rm -r — cached

Пример: git rm -r —cached config.js

Эта команда используется для удаления файла из удаленного репозитория (GitHub), не удаляя его в локальном репозитории.

20. git bisect

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

21. git diff

git diff — частое использование

Эта команда используется сравнения изменений.

22. git rebase

Полезно, если вы работали с веткой, но затем вам нужно объединить изменения, сделанные в этой ветке, с другой. С помощью git rebase вы можете «переместить» свою ветку поверх последней версии. Это также полезно, если команда следует общепринятым соглашениям о коммитах, таким как объединение коммитов вместе или разделение «больших» коммитов на «меньшие». Это используется в основном для «реорганизации» ваших коммитов.

git rebase -i HEAD~N

Склеить коммиты, переписав историю с момента HEAD~N, т.е. с того, что было N коммитов назад. -i — означает в интерактивном режиме.

23. git stash

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

git stash pop позволяет применить ранее отложенные изменения.