Push all branches git: version control — Set up git to pull and push all branches

Git push | Atlassian Git Tutorial

Команда git push используется для выгрузки содержимого локального репозитория в удаленный репозиторий. Она позволяет передать коммиты из локального репозитория в удаленный. Эта команда симметрична команде git fetch: при извлечении с помощью fetch коммиты импортируются в локальные ветки, а при публикации с помощью push коммиты экспортируются в удаленные ветки. Настроить удаленные ветки можно с помощью команды git remote. Команда push может перезаписать изменения, поэтому при ее использовании следует соблюдать осторожность. Эти проблемы обсуждаются ниже.

Использование git push

git push <remote> <branch>

Публикация указанной ветки в удаленном репозитории вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, Git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние.

git push <remote> --force

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

git push <remote> --all

Публикация всех локальных веток в указанном удаленном репозитории.

git push <remote> --tags

При публикации ветки или использовании опции --all теги не публикуются автоматически. Флаг --tags отправляет все локальные теги в удаленный репозиторий.

Обсуждение git push

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

На рисунке выше показано, что происходит, когда ваша локальная ветка master изменяет предыдущие коммиты ветки master центрального репозитория и вы публикуете изменения с помощью команды git push origin master. Обратите внимание, что команда git push по сути аналогична команде git merge master, запущенной из удаленного репозитория.

Git push и синхронизация

Команда git push — это один из многих компонентов, которые используются в общем процессе синхронизации в Git. Команды синхронизации работают с удаленными ветками, которые настраиваются с помощью команды git remote. Команду git push можно рассматривать как команду «выгрузки», а команды git fetch и git pull — как команды «загрузки». После того как наборы изменений перемещены посредством «загрузки» или «выгрузки», в месте назначения можно интегрировать изменения, выполнив их слияние командой git merge.

Публикация в чистые репозитории

В настоящее время в качестве центрального исходного репозитория Git часто используют удаленно размещенный чистый (--bare) репозиторий. Этот исходный репозиторий размещается за пределами рабочего места у доверенной третьей стороны, например в Bitbucket. Поскольку при публикации нарушается структура удаленных веток, наиболее безопасный и распространенный вариант публикации — это публикация в репозиторий, созданный с флагом --bare. Чистые репозитории не имеют рабочего каталога, поэтому при публикации содержимое рабочего каталога не изменяется. Дополнительную информацию о создании чистых репозиториев см. в документации по команде git init.

Принудительная публикация

Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, если нельзя выполнить их ускоренное слияние. Так, если история удаленного репозитория отличается от вашей истории, необходимо загрузить удаленную ветку командой pull и выполнить ее слияние с локальной веткой командой merge, а затем попробовать выполнить команду push еще раз. Это похоже на то, как в SVN необходимо синхронизироваться с центральным репозиторием с помощью команды svn update перед тем, как сделать коммит набора изменений.

Флаг --force отменяет это поведение и подгоняет ветку удаленного репозитория под вашу локальную ветку, удаляя любые вышестоящие изменения, которые могли быть внесены с момента последнего выполнения вами команды pull. Принудительное использование команды push оправдано лишь в том случае, когда вы понимаете, что только что опубликованные вами коммиты были не совсем правильными и вы исправили их с помощью команды git commit --amend или интерактивного перебазирования. При этом прежде, чем использовать опцию --force, вы должны быть абсолютно уверены в том, что никто из участников вашей команды не забирал эти коммиты с помощью команды pull.

Примеры

Команда git push по умолчанию

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

git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master

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

Принудительная команда push при исправлении коммитов

Команда git commit имеет опцию --amend, которая позволяет обновить предыдущий коммит. В коммиты часто вносятся исправления, чтобы обновить сообщение коммита или добавить новые изменения. Если коммит был исправлен, то при выполнении команды git push произойдет сбой, так как Git воспримет исправленный и удаленный коммиты как разнородное содержимое. Опция --force позволит выполнить команду push и опубликовать измененный коммит.

# make changes to a repo and git add
git commit --amend
# update the existing commit message
git push --force origin master

В приведенном выше примере предполагается, что он выполняется в существующем репозитории с историей коммитов. Команда git commit --amend используется для обновления предыдущего коммита. Затем исправленный коммит принудительно публикуется с помощью команды push с опцией --force.

Стирание удаленной ветки или тега

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

git branch -D branch_name
git push origin :branch_name

Первая команда сотрет локальную ветку с именем branch_name. Если в команде git push перед именем ветки поставить двоеточие, будет стерта удаленная ветка.

В чем разница между git push.default=current и push.default=upstream?

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

Например, если вы работаете в нескольких репозиториях или на нескольких общих пультах разработчика, вы часто отслеживаете разные ветви одной и той же ветви, такие как allen-master или susan-master , которые отслеживают ветвь master в репозиториях Аллена и Сьюзен соответственно. В этом случае current будет неправильной настройкой, потому что эти имена ветвей не существуют на их пультах дистанционного управления. upstream, однако, будет работать просто отлично.

Более практичным примером может быть отслеживание как репозитория development , так и репозитория production . Ваш рабочий процесс может использовать разные ветви магистрали для каждого из них, но это может привести к путанице. Предположим, вы являетесь интегратором кода и хотите отслеживать ветви master обоих репозиториев отдельно.

git checkout -b production --track production/master
git checkout -b development --track development/master

Теперь у вас есть две ветви, которые отслеживают свои соответствующие репозитории, ни одна из которых вообще не использует соглашение об именовании master . В названиях ветвей нет никакой путаницы: они явно описывают то, что отслеживают. Тем не менее, push.default = current не имеет никакого смысла, поскольку ни один пульт дистанционного управления не содержит ветви development или production .

git — Как восстановить происхождение из локального хранилища

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

Затем происходит сбой сервера, и не было резервной копии, зеркального отображения и т. Д. Итак, центральное хранилище потеряно.

Можно ли восстановить центральный репозиторий со всеми ветками из моего локального репозитория?

Что-то вроде git init --bare --shared=group . /repo.git на сервере, а затем git please --recover --with=allbraches mylocal.repository to ssh://...

2

vaso123

25 Фев 2017 в 13:44

3 ответа

Лучший ответ

Из вашего локального репо, git push origin --all. Я предполагаю, что новый репо на восстановленном сервере имеет тот же URL. Если URL-адрес изменился, сначала выполните git remote set-url origin <new URL>.

2

Code-Apprentice
25 Фев 2017 в 11:02

Делать эти команды

# Check remote Git server.
git remote -v

# If Git server changed or doesn't exist.
git remote set-url origin your_remote_git_server

# For example. 
git remote set-url origin https://github.com/donhuvy/elasticsearch.git

# Check your permission on Git server. You must be master user.
# Force push all branches to remote Git server.
git push origin --all --force

# Force push all tags to remote Git server.
git push origin --tags --force

# Check result after the above steps by few command.
git status
git branch --all
git log --oneline -10
git log --oneline --graph --decorate --all

2

Code-Apprentice
25 Фев 2017 в 15:26

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

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

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

#!/bin/bash

# update the new origin 
# (or leave the same one if its the same as the original)

git remote set-url origin <new-url> 
# loop over all the original branches
# 1. check them out as local branches 
# 2. set the origin as the track branch
for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master `; do
    git branch --track ${branch#remotes/origin/} $branch
done

# now push all branches and tags
git push origin --all    
git push origin --tags

Что делает скрипт?

git branch -a сильный >
получить список всех местных отделений

| grep remotes сильный > Имена ветвей: «remotes / origin /», так что это удалит удаленные из имен веток

| grep -v HEAD | grep -v master сильный >
удалить мастер (текущую ветку) и HEAD, который является псевдонимом последнего коммита

1

Community
23 Май 2017 в 12:00

github — git push все ветки с одного пульта на другой удаленный

github — git push все ветки с одного пульта на другой — qaru

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

Спросил
4 года, 11 месяцев назад

Просмотрено
20к раз

У меня два пульта: восходящий и исходный.восходящий поток — это то, на что я не могу настаивать origin — мое собственное репо. Как я могу получить все ветки из апстрима, а затем отправить их в источник?
Я пробовал:

  git fetch восходящий поток
git push - все происхождение
  

Но не работает.

Беньямин Джафари

15. 6k1414 золотых знаков8282 серебряных знака117117 бронзовых знаков

Создан 17 июн.

Тао ХуанТао Хуан

77111 золотой знак77 серебряных знаков1414 бронзовых знаков

2

Вы можете попробовать клонировать свое исходное репо с опцией --mirror , а затем нажать на новый пульт с опцией --mirror

У вас будет следующий поток:

  git clone  --mirror
cd 
git remote add  
git push <имя-пульта> --mirror
  

⚠ Будьте очень осторожны с push --mirror , так как он удалит веток, которые находятся на вашем

Деннис

19. 3k33 золотых знака6060 серебряных знаков7878 бронзовых знаков

Создан 26 июн.

Нико ГлэйрНико Глэйр

911 золотой знак99 серебряных знаков2020 бронзовых знаков

6

Мне просто нужно было скопировать один репозиторий из Bitbucket в GitHub, это шаги, предполагающие, что ваш пульт называется origin, все ветки и теги будут скопированы:

  git remote добавить новый исходный URL-адрес в новый-удаленный
git push neworigin --tags refs / remotes / origin / *: refs / Heads / *
  

Хорошо то, что файлы в вашей рабочей копии не будут изменены.

Создан 15 янв.

jose.ariasjose.arias

33133 серебряных знака55 бронзовых знаков

4

Один полный ответ клонирования из одного (чистого) репозитория в другой (чистый) репозиторий с использованием ВСЕХ ветвей, а не только проверенных, — это клонирование локального чистого репозитория в качестве посредника.Затем все ветви вытягиваются как часть клона, и git push —all выталкивает их все. Пример, выполненный в Windows с github на gitlab:

1. git clone —bare [email protected]: robe070 / cookbooks.git
2. cd cookbooks.git
3. git remote добавить gitlab [email protected]: robe071 / cookbookstest2.git
4. git push —force —all gitlab
5. git push —force —tags gitlab

Результат: 25 веток отправлены в gitlab

Обратите внимание, git checkout не требуется для всех веток и в любом случае не имеет смысла для простого репо.

Создан 31 янв.

RobGRobG

59555 серебряных знаков1414 бронзовых знаков

1

Когда вы git push --all или git push --tags , все ветки и теги будут перемещаться из вашей локальной истории в REMOTE.Таким образом, если вы хотите, чтобы протолкнул все ветки и теги с удаленного (например, origin ) (не только вашу локальную историю) на другой удаленный (например, upstream ) , выполните следующую процедуру:

1. Получить все ветки и теги из источника и удалить несовпадающие ветки в вашей локальной истории с помощью удаленного источника:
2. Добавить новый удаленный URL:
3. Теперь ваш локальный компьютер синхронизирован. Затем вы можете отправить все ветки и теги на новый пульт:

кл; DR

  git fetch --prune
git branch -r | grep -v '\ ->' | при чтении удаленного; сделать git branch --track "$ {remote # origin /}" "$ remote"; Выполнено
git fetch - все
git remote add upstream <путь-url-удаленного.git>
git push - все вверх по течению
git push --tags вверх по течению
  

Создан 30 окт.

Беньямин Джафари

15.6k1414 золотых знаков8282 серебряных знака117117 бронзовых знаков

UI Method:
Вы также можете сделать это через Github.Пользовательский интерфейс com — частные и публичные репозитории работают.

1. Создайте новое репо в своей организации на github.com — нажмите зеленую кнопку «Создать репозиторий».

2. На следующем экране последняя из перечисленных опций позволяет клонировать ваше старое репо на Github. (см. Выделение синим)

3. Затем введите свой старый URL-адрес репозитория bitbucket, как показано ниже.
   (да, частное репо в порядке — продолжайте читать — следующий шаг — auth: p)

4. Наконец, он попросит ваши учетные данные для входа, введите их и пойдите сварить кофе.Честно говоря, это не займет много времени.

БАМ — и готово. Лично я просто использую CLI + Mirror, который по иронии судьбы является общепринятым ответом, но на днях один разработчик спросил меня об этом в моей команде и подумал, что было бы полезно иметь альтернативу.

Создан 20 янв.

Надеюсь, это поможет:

  git remote добавить URL-адрес вашего нового источника в репо / репо.мерзавец
git push --all your-new-origin // выталкивает все ветки
git push --tags your-new-origin // выталкивает все теги
  

Создан 01 дек.

Ахилешнаира

1,17711 золотых знаков1111 серебряных знаков1818 бронзовых знаков

1

Stack Overflow лучше всего работает с включенным JavaScript

Ваша конфиденциальность

Нажимая «Принять все файлы cookie», вы соглашаетесь с тем, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в ​​отношении файлов cookie.

Принимать все файлы cookie

Настроить параметры

Git — документация git-push

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

Git поддерживает протоколы ssh, git, http и https (кроме того, ftp,
и ftps можно использовать для загрузки, но это неэффективно и
устарело; не используйте это).

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

С ними можно использовать следующие синтаксисы:

• ssh: // [пользователь @] host. xz [: порт] / путь / к / репо.git /

• git: //host.xz [: порт] /path/to/repo.git/

• http [s]: //host.xz [: порт] /path/to/repo.git/

• ftp [s]: //host.xz [: порт] /path/to/repo.git/

Альтернативный scp-подобный синтаксис также может использоваться с протоколом ssh:

Этот синтаксис распознается только в том случае, если перед
первое двоеточие. Это помогает различать локальный путь, содержащий
двоеточие. Например, локальный путь foo: bar можно указать как
абсолютный путь или ./ foo: bar , чтобы избежать ошибочной интерпретации как ssh
URL.

Протоколы ssh и git дополнительно поддерживают расширение имени пользователя:

• ssh: // [пользователь @] host.xz [: порт] / ~ [пользователь] /path/to/repo.git/

• git: //host.xz [: порт] / ~ [пользователь] /path/to/repo.git/

• [пользователь @] host.xz: / ~ [пользователь] /path/to/repo.git/

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

Эти два синтаксиса в основном эквивалентны, за исключением случаев клонирования, когда
первое подразумевает параметр —local.См. Git-clone [1] для
подробности.

git clone , git fetch и git pull , но не git push , также будут
принять подходящий файл пакета. См. Git-bundle [1].

Когда Git не знает, как обрабатывать определенный транспортный протокол, он
пытается использовать удаленный помощник remote- , если он
существуют. Чтобы явно запросить удаленный помощник, следующий синтаксис
можно использовать:

, где <адрес> может быть путем, сервером и путем или произвольным
URL-подобная строка, распознаваемая конкретным удаленным помощником
вызван.См. Подробности в gitremote-helpers [7].

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

 [url "<фактическая база URL>"]
Вместо этого = <база других URL> 

 [url "git: //git.host.xz/"]
вместо этогоOf = host.xz: / путь / к /
Вместо этого = работа: 

URL типа «работа: репо.git «или вроде» host.xz: /path/to/repo.git «будет
переписывается в любом контексте, который принимает URL как «git: //git.host.xz/repo.git».

Если вы хотите переписать URL-адреса только для push, вы можете создать
конфигурационный раздел формы:

 [url "<фактическая база URL>"]
pushInsteadOf = <база других URL> 

 [url "ssh: //example.org/"]
pushInsteadOf = git: //example.org/ 

URL-адрес вида «git: //example.org/path/to/repo.git» будет заменен на
«ssh: // пример.org / path / to / repo.git «для пуша, но тяги все равно
используйте исходный URL.

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

Понравилась статья? Ознакомьтесь с 5 нашими лучшими советами и приемами Git

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

Это возможно, если ваша рабочая копия содержит ветки отслеживания со старого пульта дистанционного управления (origin / branch2, origin / branch2 и т. Д.). Если вы это сделаете, у вас будет все репо и история.

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

Я выделил два варианта:

Вариант 1. Оформить заказ в каждом филиале и нажать

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

Вариант 2. Нажмите, не меняя рабочую копию

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

Если ваш старый, уже не активный пульт называется «oldremote», а новый пульт называется «newremote», вы можете нажать только ветки удаленного отслеживания с помощью этой команды:

 git push newremote refs / remotes / oldremote / *: ссылки / головы / * 

В некоторых случаях также можно отправить только подмножество ветвей.Если имена веток отмечены косой чертой (например, oldremote / features / branch4, oldremote / features / branch5 и т. Д.), Вы можете отправлять только ветки удаленного отслеживания с именами, начинающимися с «oldremote / features»:

 git push newremote refs / remotes / oldremote / features / *: refs / Heads / features / * 

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

Для получения дополнительной информации по теме ознакомьтесь с этой веткой на Stack Overflow.

Git Push | Учебник Atlassian Git

Команда git push используется для загрузки содержимого локального репозитория в удаленный репозиторий. Отправка — это то, как вы переносите коммиты из локального репозитория в удаленное репо. Это аналог git fetch , но в то время как выборка импорта фиксируется в локальных ветвях, отправка экспорта фиксируется в удаленные ветки.Удаленные ветки настраиваются с помощью команды git remote . Нажатие может привести к перезаписи изменений, при отправке следует соблюдать осторожность. Эти вопросы обсуждаются ниже.

Использование push-уведомлений Git

  git push <удаленный> <ветка>  

Отправьте указанную ветку вместе со всеми необходимыми фиксациями и внутренними объектами. Это создает локальную ветку в целевом репозитории. Чтобы вы не перезаписывали коммиты, Git не позволит вам нажать, когда это приведет к слиянию без перемотки вперед в целевом репозитории.

  git push <удаленный> --force  

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

  git push <удаленный> - все  

Переместите все ваши локальные ветки на указанный удаленный компьютер.

  git push <удаленный> - теги  

Теги не помещаются автоматически, когда вы нажимаете ветку или используете опцию --all .Флаг --tags отправляет все ваши локальные теги в удаленный репозиторий.

Обсуждение Git push

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

На приведенной выше диаграмме показано, что происходит, когда ваш локальный master прошел мимо master центрального репозитория и вы публикуете изменения, запустив git push origin master .Обратите внимание, что git push по сути то же самое, что запуск git merge master из удаленного репозитория.

Git push и синхронизация

git push — один из многих компонентов, используемых в общем процессе «синхронизации» Git. Команды синхронизации работают с удаленными ветвями, которые настраиваются с помощью команды git remote . git push можно рассматривать как команду «загрузить», тогда как git fetch и git pull можно рассматривать как команды «загрузки».После того, как наборы изменений были перемещены посредством загрузки или выгрузки, в месте назначения может быть выполнено слияние git для интеграции изменений.

Отправка в голые репозитории


Часто используемая современная практика Git состоит в том, чтобы иметь удаленно размещенный репозиторий --bare , выступающий в качестве центрального репозитория источника. Этот исходный репозиторий часто размещается за пределами сайта у доверенной третьей стороны, такой как Bitbucket. Поскольку отправка приводит к путанице со структурой удаленной ветки, наиболее безопасным и распространенным является отправка в репозитории, созданные с помощью флага --bare .У голых репозиториев нет рабочего каталога, поэтому push не изменит содержимое текущего рабочего каталога. Для получения дополнительной информации о создании чистого репозитория прочитайте о git init .

Force Pushing (принудительное толкание)


Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, когда они приводят к слиянию без быстрой перемотки вперед. Итак, если удаленная история отличается от вашей истории, вам нужно вытащить удаленную ветку и объединить ее с вашей локальной, а затем попробовать нажать еще раз.Это похоже на то, как SVN заставляет вас синхронизироваться с центральным репозиторием через svn update перед фиксацией набора изменений.

Флаг --force отменяет это поведение и заставляет ветвь удаленного репозитория соответствовать вашей локальной, удаляя любые изменения восходящего потока, которые могли произойти с момента последнего извлечения. Единственный раз, когда вам когда-либо понадобится принудительное нажатие, это когда вы поймете, что коммиты, которыми вы только что поделились, были не совсем правильными, и вы исправили их с помощью git commit --amend или интерактивной перебазировки.Однако вы должны быть абсолютно уверены, что ни один из ваших товарищей по команде не выполнил эти коммиты, прежде чем использовать опцию --force .

Примеры


git push по умолчанию


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

  git checkout master 
 git fetch origin master 
 git rebase -i origin / master 
 # Сквош фиксирует, исправляет сообщения фиксации и т. Д. 
 git push origin master  

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

Толчок с измененной силой


Команда git commit принимает параметр --amend , который обновляет предыдущую фиксацию. В фиксацию часто вносят поправки, чтобы обновить сообщение фиксации или добавить новые изменения. После изменения фиксации git push завершится ошибкой, потому что Git увидит измененную фиксацию и удаленную фиксацию как расходящийся контент. Параметр --force должен использоваться для отправки измененного коммита.

  # внести изменения в репо и git add 
 git commit --amend 
 # обновить существующее сообщение фиксации 
 git push --force origin master  

В приведенном выше примере предполагается, что он выполняется в существующем репозитории с историей фиксации. git commit --amend используется для обновления предыдущего коммита. Затем измененная фиксация принудительно проталкивается с использованием параметра --force .

Удаление удаленной ветви или тега


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

  git branch -D имя_ ветки 
 git push origin: имя_ ветки  

Приведенное выше удалит удаленную ветку с именем branch_name, передав имя ветки с префиксом двоеточие в git push удалит удаленную ветку.

Описание команды Git Push

Команда git push позволяет отправлять (или push ) коммиты из локальной ветки в локальном репозитории Git в удаленный репозиторий.

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

Синтаксис этой команды следующий:

  git push <имя репо> <имя ветки>  

Существует ряд различных параметров, которые вы можете передать с помощью команды, вы можете узнать больше о них в документации Git или запустите git push --help .

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

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

  # После клонирования репо вы будете работать внутри ветки по умолчанию (по умолчанию это `master`)
git clone https://github.com//  && cd 
# вносим изменения и обрабатываем ваши файлы (повторяйте команду `git add` для каждого файла или используйте` git add .`, чтобы обработать все)
git add <имя файла>
# теперь зафиксируйте свой код
git commit -m "добавил некоторые изменения в мое репо!"
# отправляем изменения из ветки `master` в github
git push origin master  

Чтобы узнать больше о ветвях, просмотрите ссылки ниже:

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

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

  git push --all   

, в котором:

• --all - это флаг, который сигнализирует о том, что вы хотите отправить все ветки в удаленный репозиторий
• REMOTE-NAME - это имя удаленного репозитория, на которое вы хотите нажать

Нажмите на определенную ветвь с параметром force

Если вы хотите игнорировать локальные изменения, внесенные в репозиторий Git на Github (который большинство разработчиков делают исправления для сервера разработки), то вы можете использовать команду —force, чтобы протолкнуть, игнорируя эти изменения.

  git push --force    

, в котором:

• REMOTE-NAME - это имя удаленного репозитория, в который вы хотите отправить изменения в
• BRANCH-NAME - это имя удаленной ветки, в которую вы хотите отправить свои изменения.

Push, игнорируя обработчик предварительного нажатия Git

По умолчанию git push вызовет переключатель --verify . Это означает, что git выполнит любой клиентский скрипт pre-push, который мог быть настроен.Если сценарии предварительной загрузки не работают, git push. (Перехватчики Pre-Push хороши для таких вещей, как проверка того, соответствуют ли сообщения фиксации стандартам компании, запускают модульные тесты и т. Д.). Иногда вы можете проигнорировать это поведение по умолчанию, например. в сценарии, когда вы хотите отправить свои изменения в ветку функций, чтобы другой участник мог их вытащить, но ваши незавершенные изменения нарушают модульные тесты. Чтобы игнорировать ловушку, просто введите команду push и добавьте флаг --no-verify

  git push --no-verify  

Дополнительная информация:

Перемещение репозитория git и всех его веток, тегов в новый удаленный репозиторий с сохранением истории коммитов · GitHub

Перемещение репозитория git и всех его веток, тегов в новый удаленный репозиторий с сохранением истории коммитов · GitHub

Мгновенно делитесь кодом, заметками и фрагментами.

Перемещение репозитория git и всех его веток, тегов в новый удаленный репозиторий с сохранением истории коммитов

.


Вы не можете выполнить это действие в настоящее время.

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

Git Push to Remote Branch - Как отправить локальную ветку в Origin

Основная команда для отправки локальной ветки в удаленный репозиторий - это git push .

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

Как отправить локальную ветку Git в Origin

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

Общая форма команды следующая:

  $ git push    

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

Если ваша текущая ветка - main , команда git push предоставит два параметра по умолчанию - фактически запустит git push origin main .

В приведенном ниже примере origin remote - это репозиторий GitHub, а текущая ветка - main :

  (main) $ git remote -v
origin [email protected]: johnmosesman / burner-repo.git (выборка)
origin [email protected]: johnmosesman / burner-repo.git (нажать)

(основной) $ git push
Перебор объектов: 4, готово.Подсчет объектов: 100% (4/4), готово.
Дельта-сжатие с использованием до 16 потоков
Сжатие объектов: 100% (2/2), готово.
Запись объектов: 100% (3/3), 274 байта | 274.00 КБ / с, готово.
Всего 3 (дельта 0), повторно используется 0 (дельта 0)
На github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6 main -> main
  

Из выходных данных видно, что локальная ветвь main была перенесена на удаленную main ветку :

  На github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6 main -> main
  

Как принудительно нажать ветку в Git

Обычно вы нажимаете ветку и добавляете ее в историю фиксации.

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

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

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

Второй и более распространенный сценарий - после действия, такого как rebase - , которое изменяет историю фиксации:

Внутри Git выполняет [rebase], создавая новые коммиты и применяя их к указанной базе.Очень важно понимать, что хотя ветка выглядит так же, она состоит из совершенно новых коммитов.

Перебазирование создает полностью новых коммитов.

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

  (моя функция) $ git push
На github.com:johnmosesman/burner-repo.мерзавец
 ! [отклонено] моя-функция -> моя-функция (без перемотки вперед)
ошибка: не удалось отправить некоторые ссылки на '[email protected]: johnmosesman / burner-repo.git'
Подсказка: обновления были отклонены, потому что верхушка вашей текущей ветки отстает
подсказка: его удаленный аналог. Интегрируйте удаленные изменения (например,
подсказка: 'git pull ...') перед повторным нажатием.
Подсказка: подробности см. в «Примечании о быстрой перемотке вперед» в «git push --help».
  

Здесь вы можете выполнить команду git pull , чтобы объединить различия, но если вы действительно хотите перезаписать удаленный репозиторий, вы можете добавить флаг --force в свой push:

  (my-feature ) $ git push --force origin my-feature
Перебор объектов: 1, готово.Подсчет объектов: 100% (1/1), готово.
Запись объектов: 100% (1/1), 184 байта | 184.00 КБ / с, готово.
Всего 1 (дельта 0), повторно используется 0 (дельта 0)
На github.com:johnmosesman/burner-repo.git
 + edb64e2 ... 52f54da my-feature -> my-feature (принудительное обновление)
  

( Примечание: вы можете использовать -f в качестве сокращения вместо --force .)

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

Принудительная отправка с арендой

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

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

Чтобы предотвратить этот сценарий, вы можете использовать параметр --force-with-lease .

Снова из документации:

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

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

Если вы сотрудничаете с другими участниками своего филиала, было бы хорошо либо избегать использования --force , либо хотя бы использовать --force-with-lease , чтобы предотвратить потерю изменений, внесенных другими сотрудниками.

Как отправить в ветку с другим именем в Git

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

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

Например, если вы хотите отправить ветку с именем some-branch на my-feature :

  (some-branch) $ git push origin some-branch: my-feature
Всего 0 (дельта 0), повторно используется 0 (дельта 0)
На github.com:johnmosesman/burner-repo.мерзавец
 + 728f0df ... 8bf04ea some-branch -> my-feature  

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

Вам не нужно очень часто толкать все ветки с вашего локального компьютера, но если вы это сделаете, вы можете добавить флаг --all :

  (основная) ветка $ git
* основной
  моя особенность

(основной) $ git push - все
...
На github.com:johnmosesman/burner-repo.git
   b7f661f..6e36148 главная -> главная
 * [новая ветка] my-feature -> my-feature
  

Заключение

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