Git stash зависит от ветки или для всего репозитория?

2 ответа

Лучший ответ

Перед фиксацией ваши изменения находятся на диске («рабочая копия») или после «промежуточной области». Ни один из них не принадлежит к определенной ветви. Когда вы переключаете ветки, незафиксированные изменения сохраняются. Если изменение ветки приведет к перезаписи незафиксированных изменений, Git не позволит вам переключиться.

Когда у вас есть работа и вы хотите переключить ветки, вы должны поместить ее в тайник, используя . См. Раздел Хранение и очистка в Pro Git.

В качестве альтернативы вы можете зафиксировать незавершенную работу, а затем использовать для добавления в фиксацию. См. историю перезаписи в Pro Git.

3

Schwern
19 Авг 2020 в 23:29

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

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

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

2 — Вы можете создать временную ветку для ваших изменений. Обычно (т.е. если ваши изменения не включают удаление файлов) вы можете использовать форму , чтобы вернуть изменения позже.

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

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

4 — Вы можете проверить другую ветвь на новом рабочем дереве и индексировать. (Напомним, что наличие только одного рабочего дерева и индекса — вот что требует поведения git по умолчанию; поэтому, если вы этого не хотите, вы можете создать больше рабочих деревьев.) https://git-scm.com/docs/git-worktree

5 — Вы можете отменить свои изменения. Это может редко быть тем вариантом, который вам нужен, но его достаточно легко сделать, если вы этого хотите.

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

1

Mark Adelsberger
19 Авг 2020 в 23:44

6 ответов

Лучший ответ

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

First of all what is HEAD?

— это просто ссылка на текущий коммит (последний) в текущей ветке. В любой момент времени может быть только один (исключая ).

Содержимое хранится внутри и содержит 40 байтов SHA-1 текущего коммита.

detached HEAD

Если вы не используете последнюю фиксацию — это означает, что указывает на предыдущую фиксацию в истории, она называется detached HEAD.

В командной строке это будет выглядеть так — SHA-1 вместо имени ветви, поскольку не указывает на кончик текущей ветви:

Несколько вариантов того, как восстановить систему с отключенной HEAD:

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

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

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

Это вернет вас к желаемой фиксации

«Переместите» ГОЛОВУ назад к желаемому коммиту.

Примечание. (Начиная с Git 2.7) вы можете также используйте git rebase —no-autostash.

«Отменить» данный диапазон фиксации или фиксации. Команда сброса «отменит» любые изменения, сделанные в данном коммите. Новый коммит с патчем отмены будет зафиксирован, в то время как оригинальный коммит останется в истории.

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

439

Community
20 Июн 2020 в 09:12

Сначала локально:

Чтобы убедиться, что вы на правильной позиции, проверьте:

Вы увидите что-то вроде:

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

29

Abel
25 Июл 2020 в 20:57

Сегодня я по ошибке проверил фиксацию и начал работать над ней, сделав несколько коммитов в состоянии отсоединения HEAD. Затем я перешел в удаленную ветку с помощью следующей команды:

Затем

Затем

Наконец-то я получил все изменения в своей ветке, которые я сделал при отсоединении HEAD.

Peter Mortensen
27 Янв 2020 в 02:18

Когда вы запускаете команду , тогда HEAD отсоединяется от , и ветвь становится доступной дольше.

Вернитесь в предыдущее место, выполните пошаговую команду —

1. (скажите хозяин)

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

Peter Mortensen
27 Янв 2020 в 02:16

Вопрос можно прочитать так:

Я был в отключенном состоянии с в и набрал (потому что я хотел раздавить). Теперь я передумал, как мне вернуться к в ?

Прямой ответ:

Но я задал этот вопрос, потому что мне надоело набирать (копировать и вставлять) хеши коммитов или их аббревиатуры каждый раз, когда я хотел сослаться на предыдущий и искал в Google, есть ли какие-нибудь сокращения.

Оказывается, есть!

(или в моем случае )

Кстати, это было то же самое, что вернуться в предыдущий текущий каталог в * nix! Итак, ура, я выучил две вещи одним выстрелом.

4

Peter Mortensen
27 Янв 2020 в 02:14

Самое быстрое решение (всего 1 шаг)

Используйте

Вы увидите . Подтвердите, что это нужная ветка.

Краткое объяснение: эта команда вернет HEAD в последнее положение. См. Примечание о результатах в конце этого ответа.

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

Более методичное решение (2 шага, но запоминающееся)

Быстрый подход решает вопрос ОП. Но что, если ваша ситуация немного отличается: скажем, вы перезапустили Bash, а затем обнаружили, что HEAD отключен. В таком случае, вот 2 простых, легко запоминающихся шага.

Используйте

Вы видите список существующих местных филиалов. Выберите название ветки, которое вам подходит.

Используйте

Вы увидите . Успех!

Результаты

С помощью любого метода вы можете продолжить добавление и фиксацию своей работы, как и раньше: ваши следующие изменения будут отслеживаться .

Обратите внимание, что и , и дадут дополнительные инструкции, если вы зафиксировали изменения, когда HEAD был отключен. 13

Kay V
13 Фев 2020 в 16:51

13

Kay V
13 Фев 2020 в 16:51

git reset

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

git reset 1ea3e

Или на один коммит назад ( — , — родительский коммит):

git reset @~

Флаг —hard с reset

— жесткий : передвигает ветку на указанный коммит и обновляет рабочую директорию с индексом на момент указанного коммита ().

git reset --hard 1ea3e

Как вернуть коммит, убранный reset

Что если нам потребуется вернуть коммит, который был удален командой . Для этого находим коммит по (см. описание к ):

git reflog master
git branch feature 'HEAD@{6}'

Или когда мы перемещаем ветку при помощи команды , то Git записывает предыдущее значение в файл и мы можем использовать его в качестве ссылки:

git reset --hard ORIG_HEAD

Флаг —soft с reset

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

Подведем итог: мягкий отменяет коммит, но оставляет все подготовленные для коммита данные.

git reset --soft @~

Флаг —mixed (по умолчанию) с reset

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

git reset @~

git reset HEAD

или

git reset

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

————остановился (для reset)————

Флаг —amend

Флаг позволяет исправить последний коммит — это быстрая замена текущего коммита, то есть эта команда берет область индексирования () и включает в текущий коммит всю обнаруженную там информаци. Предположим последний коммит содержит ошибки. Мы должны исправить файлы в рабочей директории. Правим файлы и добавляем их в индекс:

git add .

Для замены коммита запускаем:

git commit --amend

Команда сделала следующие два действия:

git reset --soft @~
git reset -c ORIG_HEAD

Основы ветвления

Предположим, вы работаете над проектом и уже имеете несколько коммитов.

Рисунок 18 – Простая история коммитов

Вы решаете, что теперь вы будете заниматься проблемой #53 из вашей системы отслеживания ошибок. Чтобы создать ветку и сразу переключиться на нее, можно выполнить команду с параметром :

Это то же самое что и:

Рисунок 19 – Создание нового указателя ветки

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

Рисунок 20 – Ветка двигается вперед

Тут вы получаете сообщение об обнаружении уязвимости на вашем сайте, которую нужно немедленно устранить. Благодаря Git, не требуется размещать это исправление вместе с тем, что вы сделали в . Вам даже не придется прилагать усилий, чтобы откатить все эти изменения для начала работы над исправлением. Всё, что вам нужно – переключиться на ветку .

Но перед тем как сделать это – имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе «Припрятывание и очистка» главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку :

С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением

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

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

Рисунок 21 – Ветка основана на ветке

Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так – выполнить слияние ветки с веткой для включения изменений в продукт. Это делается командой :

Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4, на который указывает слитая ветка , был прямым потомком коммита C2, на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться двигаясь по истории прямо, Git упрощает слияние просто перенося указатель ветки вперед, поскольку расхождений в изменениях нет. Это называется «fast-forward».

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

Рисунок 22 – перемотан до

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

Для удаления ветки выполните команду с параметром :

Теперь вы можете переключиться обратно на ветку и продолжить работу над проблемой #53:

Рисунок 23 – Продолжение работы над iss53

Стоит обратить внимание на то, что все изменения из ветки не включены в вашу ветку. Если их нужно включить, вы можете влить ветку в вашу ветку командой , или же вы можете отложить слияние этих изменений до завершения работы, и затем влить ветку в

11 ответов

Лучший ответ

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

292

Armel
7 Фев 2020 в 07:42

Чтобы убедиться, что ваша локальная ветка FixForBug не опережает удаленную ветку, FixForBug извлекает и объединяет изменения перед отправкой.

70

mhatch
9 Сен 2016 в 14:45

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

Вы можете использовать эту команду для принудительного внесения изменений на сервер с помощью local repo ().

С тегом вы замените своим кодом.

63

Talha Rafique
27 Июл 2020 в 08:43

Если вы хотите избежать использования , вы можете использовать просто

Вместо того

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

Без использования .

20

Greg Hewgill
8 Сен 2016 в 22:07

Команда, которую я использовал с Azure DevOps, когда я обнаружил сообщение «обновления были отклонены, потому что верхняя часть вашей текущей ветки отстает», была / является следующей командой:

Мастер происхождения git pull

(или можно начать с новой папки и сделать клонирование) ..

Этот ответ не касается поставленного вопроса, в частности, Кейф ответил на него выше, но он отвечает на заголовок / текст заголовка вопроса, и это будет распространенный вопрос для пользователей Azure DevOps.

Я заметил комментарий: «Вы всегда должны быть уверены, что делаете тягу, прежде чем толкать» в ответе Кейфа выше!

Я также использовал инструмент Git Gui в дополнение к инструменту командной строки Git.

(Я не был уверен, как сделать эквивалент команды командной строки «git pull origin master» в Git Gui, поэтому я вернулся в командную строку, чтобы сделать это).

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

6

Allan F
12 Сен 2019 в 05:29

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

Если git rebase прошла успешно, тогда хорошо. В противном случае вы разрешаете все конфликты слияния локально и продолжаете его до тех пор, пока перебазирование с удаленным не будет успешным.

4

thatguy
27 Авг 2020 в 11:29

Установить текущее имя ветки как master

Или название филиала разработать

4

Golam Sorwar
15 Сен 2020 в 18:07

У меня возникла эта проблема при попытке нажать после перезагрузки через Visual Studio Code, моя проблема была решена путем простого копирования команды из окна вывода git и выполнения ее из окна терминала в Visual Studio Code.

В моем случае команда была примерно такой:

1

HoloLady
7 Май 2020 в 06:53

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

M.Erkan Çam
13 Ноя 2020 в 14:52

Я помогу дальше:

1

Alex Reuka
2 Сен 2020 в 10:17

Вы, должно быть, добавили новые файлы в свои коммиты, которые не были отправлены. Проверьте файл и снова нажмите этот файл, и попробуйте потянуть / нажать, он будет работать. Это сработало для меня ..

Rahul Parab
3 Авг 2020 в 07:06

Удаленный репозиторий

Команда позволяет просмотреть удаленные репозитории

git remote -v

параметр позволяет увидеть URL-адреса.

git remote add (добавляем уд. реп., для работы локально)

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

git remote add  

git remote add alias_repo 

— теперь вместо полного URL-адреса в командную строку можно вводить имя

В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку :

git remote add interview https://github.com/asdasd/interview.git
git pull interview master

Пример использования:

• Иниц. пустой реп.
• Добавляем реп.
• извлекаем все данные ()
• и стягиваем ветку из реп.

git init
git remote add kuku https://github.com/denzLLL/test.git
git fetch kuku
git pull kuku master

git fetch (Извлечение данных из уд. реп.)

Извлечение данных из удаленного репозитория выполняется командой:

git fetch 

После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.

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

git fetch origin

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

$ git pull

git push (проталкиваем изменения на уд. сервер)

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

git push  

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

git push origin master

Или, что тоже самое:

git push origin master:master

git push -u origin master

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

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

git push origin master:masterB

Посредством : разделяем локальную ветку и удаленную ветку .

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

git push origin --delete 

git pull (скачиваем изменения)

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

git remote show (получаем инфо. об уд. реп.)

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

git remote show 
git remote show origin

Команда также оповестит вас о том, что, если находясь на ветке master вы запустите , то ветка на удаленном репо. будет автоматически c вашей локальной веткой .

Удаленные ветки

Удаленные ветки — это ссылки на состояние веток в удаленных репозиториях.

Структура наименования удаленной ветки — (имя удаленного репозиория)/ветка. Например, .

Если вам потребуется своя локальная ветка (), аналогичная удаленной ветки, то можно воспользоваться командой:

git checkout -b name_branch origin/name_branch

Этим мы также говорим, что ветка следит за удаленной веткой .

Данную операцию можно реализовать при помощи параметра :

git checkout --track origin/name_branch

Будет создана локальная ветка , которая следит за удаленной веткой .

Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:

git checkout -b test-master origin/master

Локальная ветка ‘смотрит’ на удаленную ветку .

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

git branch -u origin/test-git

Текущая ветка начнет следить за удаленной

Параметр позволяет увидеть ветки наблюдения (локальная информация):

git branch -vv

Чтобы увидеть актуальные ветки наблюдения:

git fetch --all
git branch -vv

Работаем с bitbucket.org

1. кликаем по

2. клонируем

3. создадим ветку (на основе удаленной ветки )

4. и внесем в нее какие-либо изменения

5. Фиксация изменений

6. Отправка новой ветки в ветку на bitbucket

git push origin test-git-fork

Далее переходи на bitbucket

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

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

8. Принимаем

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

Обычно мы ответвляемся от основной ветки 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.

4 ответа

Лучший ответ

Чтобы увидеть текущий стек тайника:

Чтобы выбрать конкретный тайник из стека, обратитесь к нему с помощью , показанного выше.

Если вы хотите, чтобы поведение было для каждой ветки, вы можете просто сделать фиксацию (или несколько коммитов) в ветке. Вы всегда можете «отменить» фиксацию (и) позже (например, с помощью , либо , либо ; см. git reset documentation ; или с помощью , чтобы сохранить только возможные» настоящие «фиксации ) при отказе от временных).

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

48

torek
11 Дек 2013 в 18:06

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

Итак, вот рабочий процесс тайника:

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

(если вам не нужно собственное сообщение, просто используйте ).

Когда вы вернетесь в филиал, проверьте тайник

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

Однако, если вы находитесь в ветке , вы должны сначала применить тайник 1 , а затем удалить тайник 1 из стека .

Это оно!

17

Adam
9 Апр 2021 в 09:44

не для каждой ветки.

• Вместо (который можно легко потерять, если у вас много тайников и веток)
• Я предлагаю сделать , чтобы сохранить незаконченный код в своей ветке, и когда вы будете готовы закончить код, сделайте , чтобы вернуть незаконченный код.
• и при правильном использовании вместе могут имитировать для определенной ветви

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

• вы работаете над функциональной веткой X, и ваш код даже не компилируется и не проходит тесты
• есть ошибка, имеющая более высокий приоритет, чем текущая новая функция, поэтому вы должны немедленно начать работу над исправлением ошибки
• вместо того, чтобы делать git stash (и тайник теряется в миксе, потому что у вас много тайников и много веток)
• вы можете сделать в функциональной ветке X
• проверить новую ветку Y для исправления
• завершить оперативное исправление в ветке Y (выполнить запрос на слияние, чтобы получить оперативное исправление в базовой линии и удалить ветку оперативного исправления)
• затем снова проверьте ветку функций X
• чтобы вытащить незаконченную работу, которая не была скомпилирована и не прошла тестирование -> просто сделайте

(К вашему сведению, значение по умолчанию для — )

21

Trevor Boyd Smith
13 Июл 2018 в 14:06

Нет и нет. Git stash предназначен для каждого репозитория.

Вот хорошая страница о том, как его использовать.

59

abasterfield
11 Дек 2013 в 17:55

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

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

Локальную

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

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

$ git branch -m <old-name> <new-name>

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

$ git branch –m testing test

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

$ git branch -m <new-name>

Например, текущая ветка у нас 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 хранятся на windows в файле . каждого конкретного репозитория приоритетен.

Команды

git config

Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:

git config –global user.name "firstName  lastName"
git config –global user.email "email@mail.ru"

Git позволяет ставить настройки общесистемные (), на уровне конкретного пользователя (), на уровне проекта ().

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

git config --list

Узнаем подробности о том, как работает команда, например, :

git help 
git help log

Пример файла

    name = name_user
    email = mail_user@mail.ru

    default = matching

    postBuffer = 524288000

    st = status
    ci = commit
    br = branch
    co = checkout
    df = diff
    lg = log -p

Псевдонимы (алиасы) в GIT

Команда позволяет создавать псевдонимы:

git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'