Что такое git push и как его использовать
В инструкции рассказываем о наиболее частых сценариях использования git push.
Эта инструкция — часть курса «Введение в Git».
Смотреть весь курс
Введение
Команда Git push позволяет отправлять локальную ветку на удаленный репозиторий. Она помогает разработчикам синхронизироваться в команде, а именно отправляет проделанные изменения. Если программист работает один, то пуш позволяет хранить код в облаке, например github, gitlab и не только, избавляя от риска потери данных на компьютере.
Дополнительно для синхронизации еще используют git pull для получения изменений с сервера и git remote, чтобы получить список удаленных подключений к репозиторию.
В этой инструкции мы расскажем, как запушить в удаленный git репозиторий. В статье под «пушем» будем подразумевать git push.
Отправка изменений в чистый репозиторий
Перед пушем надо связать локальный и удаленный репозитории. Делается это при помощи команды:
git remote add linkВместо repository_name нужно дать имя удаленному репозиторию. Далее в инструкции вместо этого параметра мы будем использовать origin, так как чаще всего используют это имя.
Вместо link — ссылка на удаленный репозиторий, она может выглядеть по-разному в зависимости от того используется ssh или https.
Для ssh, который обязателен для github и gitlab, потребуются сделать дополнительные манипуляции для создания ssh-ключа. Соответствующие инструкции есть на этих ресурсах.
Отправка изменений
Перед пушем надо зафиксировать текущие изменения, то есть сделать git commit.
Далее для отправки в терминале пишем:
git push origin
Вместо branch — имя ветки, которую надо отправить. Чаще всего используется master или main:
git push origin master Такое каждый раз писать слишком громоздко, для этого придумали git push по умолчанию. Для этого единожды набираем предыдущую команду с флагом -u:
git push -u origin masterПосле этого можно писать более коротко, так как git запомнил, что пушить надо на сервер origin ветку под именем master:
git pushТаким образом, git позволяет запушить ветку в удаленный репозиторий. Чтобы через git добавить ветку в удаленный репозиторий, надо запушить существующую локальную ветку.
Дополнительные опции публикации
Отправка ветки на сервер в ветку с другим именем
Для того чтобы сделать git push в другую ветку, есть специальный синтаксис, где после имени ветки через двоеточие пишется имя удаленной ветки:
git push origin branch:server_branchгде branch – имя локальной ветки, server_branch – имя удаленной ветки на сервере.
Отправка всех веток на сервер
Вместо имени ветки пишем флаг —all:
git push origin --allПосле этого все зафиксированные изменения в ветках отправятся в удаленный репозиторий.
Отправка текущей ветки
Удобный способ отправить текущую ветку с тем же именем на сервере.
git push origin HEAD HEAD указывает на текущую ветку (current branch). Тем самым, не надо запоминать имя ветки, на которой вы находитесь.
Принудительная публикация (git push —force …)
При отправке может произойти ошибка публикации:
To github.com:example/test.git ! [rejected] master -> master (fetch first) error: не удалось отправить некоторые ссылки в «github.com:example/test.git»Это так называемый git push rejected, он означает что пуш был отклонен. Правильнее всего — сделать то, что написано в подсказке к ошибке. Надо получить и смержить изменения, затем снова отправить.
Эта ошибка происходит, так как git проверяет, что новый коммит основан на предыдущих коммитах. Пока вы вносили изменения, кто-то мог запушить изменения того же, над чем вы работали. Поэтому git не может выполнить автоматическое слияние, ваш коммит был раньше и он не базируется на обновленных коммитах в удаленном репозиториие.
Флагом —force или сокращенной его версией -f отключается проверка коммитов и при необходимости выполняется перезапись истории.
git push --forceНужно быть аккуратными с этой командой, так как она стирает работу других людей. Эта команда оправдана лишь изредка, например, если вы почти сразу внесли изменения коммита с помощью git commit —amend и запушили до того, как кто-то сделал git pull.
Принудительная публикация с параметром (git push —force-with-lease …)
Это более безопасный, но так же нерекомендуемый вариант вариант принудительного пушинга. Он не перезапишет работу в удаленной ветке, если в нее были добавлены коммиты от других людей.
git push --force-with-leaseПринудительная публикация с этим параметром чревата появлением git push rejected у других людей
Как пушить в PhpStorm
При первом открытии PhpStorm потребуется создать новый проект.
В открытом проекте в правом верхнем углу среды разработки располагаются наиболее часто используемые команды git, в том числе пушинга.
Синяя стрелка означает git pull, зеленая галочка — git commit, зеленая стрелка — git push. При нажатии на зеленую стрелку (горячие клавиши Ctrl+Alt+K или ⌥ ⌘ K) открывается диалоговое окно с информацией об изменениях и настроках отправки.
Незапушенные коммиты
Самый простой способ узнать про них при помощи команды:
git status Вывод будет содержать имя текущей ветки и то, насколько она опережает версию сервера. Пример вывода:
On branch master Your branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)Для более подробной информации можно использовать:
git log Будет выведена история коммитов:
commit 0fcd9558b013f642a8c3b4a59a16a66de39c99bd (HEAD -> master) Author: Pavel Date: Sun Mar 27 18:57:14 2022 +0300 Local commit commit 289c650767d2c7c2e58486e27b8b3933c6442078 (origin/master, origin/HEAD) Author: Pavel Date: Fri Mar 25 19:41:47 2022 +0300 Pushed commit В скобках пишется где и какой коммит расположен.
HEAD -> master означает что текущая ветка (current branch) — это master и это последний локальный коммит в ней.
В нижнем коммите в скобках origin/master означает, что это последний опубликованный коммит на сервере в ветке master, а origin/HEAD, что коммит расположен на ветке, которая совпадает с локальной веткой HEAD.
Как пушить теги
Для создания тегов используют git tag, а для их отправки:
git push origin
Вместо tag_name — имя тега, который надо удалить на сервере.
Также можно сделать отправку всех тегов:
git push --tagsМы не рекомендуем выбирать этот способ, так как могут отправиться теги, которые были удалены на сервере.
Удаление ветки или тега на сервере
Чтобы удалить ветку на удаленном репозитории, используем уже привычную команду с флагом —delete:
git push --delete origin
remote_branch_or_tag_name — имя ветки или тега на сервере.
Для удаление локальной ветки:
git branch -d
А для удаления локального тега:
Git push — что это такое
Git push — это консольная команда, которая передаёт в удалённый репозиторий изменения, сделанные в локальном репозитории. С помощью этой консольной команды разработчики дорабатывают основную ветку, добавляя новые фичи и внося исправления найденных багов и уязвимостей. Это удобно и при работе в одиночку — можно хранить свой код в облаке.
Теперь раскроем тему более подробно.
Что есть Git
Git-репозиторий — это набор файлов, которые хранятся в папке .git. Просто набор файлов, и ничего более.
Git сохраняет в commit (коммит) содержимое всех файлов, сохраняя изменения в objects. Если файл не менялся, используется старый objects. Получается, что в коммит попадают только те файлы, в которые вносились исправления. Это экономит место в хранилище, ускоряет процесс обновления и позволяет в любой момент переключиться на нужный коммит, так как все коммиты видны в истории изменений.
Благодаря Git разработчикам проще откатить свой проект на более старую версию, если что-то пошло не так. Также они могут сравнивать, анализировать или выгружать сделанные изменения в удалённый репозиторий.
Аренда облачного сервера для разработки, хостинга, обученияПодробнее
Git push и все-все-все
Итак, команда git push необходима для передачи содержимого локального репозитория в центральный, к которому имеют доступ другие разработчики из команды. С ней нужно быть осторожным, пушить в репозиторий стоит лишь в том случае, когда вы твёрдо уверены том, что готовы перезаписать основную ветку. В обратном порядке работает команда git fetch: она импортирует коммиты из основного репозитория в локальные.
Если упростить, то процесс отправки пушей выглядит так:
git push origin master
- Действие: push, отправить
- Адресат: origin, сервер
- Объект: master, имя ветки
Как ещё можно использовать команду git push?
git remote add link
Начать нужно с организации связей между репозиториями. Эта команда связывает локальную и центральную ветки. Вместо repository_name указываете имя репозитория (как правило, это origin), а вместо link — URL-адрес. Только после этой команды ваш пуш будет уходить в нужную ветку.
Команда отправки на публикацию выбранной ветки в удалённый репозитории (включая все коммиты и внутренние объекты). При этом создаётся локальная ветка в конечном репозитории. В целях защиты коммитов от перезаписи Git не позволяет публиковать данные, если в конечном репозитории невозможно выполнить быстрое слияние веток.
Команда идентична приведённой выше с тем лишь отличием, что данные будут опубликованы в любом случае. Даже если ускоренное слияние выполнить невозможно. Используйте эту команду с осторожностью, так как принудительная перезапись способна удалить результат работы других людей.
Отправка всех локальных веток на публикацию в удалённом репозитории.
git branch -D branch_name или git push origin :branch_name
Чтобы навести порядок, репозитории иногда нужно чистить. Вы можете полностью стереть ветку branch_name в локальном репозитории при помощи первой команды. Или стереть удалённую ветку — введя в консоли вторую команду.
Git умеет и показывать незапушенные коммиты. Чтобы их посмотреть, введите команду
В ответ на эту команду терминал выдаст ответ вроде такого:
On branch master
Your branch is ahead of ‘origin/master’ by 3 commits.
(use «git push» to publish your local commits)
Это значит, что три коммита ещё не запушены, а предлагаемые в них изменения не внесены в репозиторий.
А что ещё можно делать с Git?
Удалять локальные данные и ветки, которых нет в центральном репозитории, добавлять и удалять теги на сервере, просматривать все удалённые репозитории, и каждый из них в отдельности. В Git есть большое количество инструментов, которые упрощают разработку и позволяют быстрее выкатывать конечный продукт. Чтобы увидеть весь перечень команд, поддерживаемых Git, введите в консоли команду
Чем опасен force push?
Чем так опасен git push -f ?
Некоторые говорят что никогда не делайте force push если работаете в команде. Хотя почему нет, никто не говорит.
Вот и задумался, возникла такая ситуация сделал git commit —ammed что бы изменить автора коммита и пришлось сделать git push —force, так как простой push не сработал.
Безопасно ли такую ветку обьединить с основным?
То есть от mastera создана ветка test в этой ветке последний коммит изменен с помошью ammed и сделан push -f.
- Вопрос задан более трёх лет назад
- 31698 просмотров
1 комментарий
Простой 1 комментарий
Некоторые и join боятся в SQL :—) Сейчас бы всяких бабок-повитух слушать.
Есть разные подходы, но я (и еще несколько человек в нашей команде) держат СВОИ ВЕТКИ в чистоте через rebase, соответственно фича-ветку ребейзите, и если она запушена была — запушить снова не получится, используют форс. ПОнятное дело — ребейз мастера или дев-веток «не желательно» делать :—)
Решения вопроса 1
Igor Deyashkin @Lobotomist
Software Developer
BD_ l3ftoverZ! ответил в принципе верно — можно затереть чужие изменения, но это не единственная опасность.
Проблема еще и в том, что старые версии коммитов кто-то получил. И если при форсед пуше в содержимое коммитов были внесены изменения (например, они были поменяны местами и в итоге «сумма изменений» осталась та же, но порядок изменился) при пулле возникнут конфликты при попытке отребэйзить (смерджить) старые версии коммитов на новые. И тут уже все зависит от опытности и внимательности разработчика, который с этим столкнулся. Если он достаточно опытен — он поймет в чем дело и правильно разрулит ситуацию. А если нет — он начнет решать конфликты, накосячит при их решении, при пуше не проверит что он пушит не только свои коммиты, которые собирался, но и старые версии коммитов отребэйзенные на новые версии и это будет. неприятно.
История из жизни.
Вот реальная ситуация, которая произошла у меня на работе. К сожалению, за давностью лет конкретные детали я помню смутно, но в целом все было примерно так. В какой-то момент появилась ошибка. Причем код, в котором она была был очень «говнокод», человек его написавший уже уволился и понять в каком месте этот говнокод написан неправильно, не понимая «логики» автора было очень сложно. С помощью git-bisect я нашел проблемный коммит и стал дальше раскручивать клубок. В итоге выяснилось, что было нарушено по крайней мере три важных правила работы с гитом (описанные во внутренней вики и обязательные к исполнению) и если бы хотя бы одно из них нарушено не было — все было бы ок.
1. Я сделал пуш в мастер и оперативно осознав, что что-то там не так быстренько поправил и залил форсед пушем исправления. Это было важно сделать именно так. Я решил, что во-первых, маловероятно, что кто-то успел сделать пулл, а во-вторых, даже если он и сделал — когда у него возникнут конфликты он либо сам все поймет, либо обратится ко мне. Первое нарушение. Мне следовало уведомить всех разработчиков об этом и объяснить как нужно правильно действовать.
2. Естественно, один разработчик успел сделать пулл и отребэйзил на старый мастер ветку этого уволившегося и стал доделывать таск. Когда спустя продолжительное время он стал ребэйзить эту ветку на мастер у него полезли конфликты. Он не понял из-за чего эти конфликты возникли. Но храбро все их решил. Етественно, не правльно, уже хотя-бы потому, что он вообще не должен был их решать. Нарушение второго правила — «решай конфликты только тогда, когда ты понимаешь почему они возникли». Обратись он ко мне — все было бы в порядке.
3. Когда он стал пушить свои изменения он нарушил третье правило: «Всегда проверяй список коммитов, которые ты пушишь». Он не заметил, что кроме «своих» коммитов, он так же пушит чужие, старые версии коммитов мастера, которые он отребэйзил на новые. Он должен был это заметить и забить тревогу — что такое, откуда эти коммиты, я их не делал. Опять же, обратись он ко мне — я бы на месте бы разобрался в чем дело, и исправил ситуацию.
Так что не надейтесь на авось (как я в данном случае).
- Это ветка по задаче, в которой работаешь только ты и согласно workflow никто не должен без твоего ведома брать из нее какие-то коммиты.
- Ты точно знаешь кто имеет доступ к ветке и уверен, что эти люди с ситуацией справятся корректно. Ты их предупредил и они знают что в таких ситуациях делать.
Что такое git push и как его использовать
По большому счету Git push используется для отправки локальной ветки на удаленный репозиторий. Таким образом упомянутая команда сильно облегчает процесс синхронизации в команде разработчиков, а если быть точнее, то пересылает совершенные апдейты. Если разработчик самостоятельно занимается проектом, то команда открывает возможность хранить имеющийся код в облаке, таком как github или же gitlab и прочие. Тем самым минимизируя риск потерять данные. Git pull также применяется в качестве инструмента синхронизации, который используется для получения изменений c git remote и удаленного сервера. Простыми словами разработчик может получить список удаленных подключений к репозиторию. Сейчас мы рассмотрим основные особенности запуска репозитория git. Для упрощения в статье будем использовать ”пуш”, имея в виду git push.
Отправка изменений в чистый репозиторий
Перед использованием команды git push потребуется создать связь между удаленным и локальным репозиторием. Для этого можно использовать следующую команду: git remote add
Отправка изменений
Перед пушем нужно сохранить изменения, используя git commit. После чего в терминале нужно будет прописать следующую команду: git push origin
Дополнительные опции публикации
Отправка ветки на сервер в ветку с другим именем
Git push можно назначить в другую ветку, что осуществляется с помощью готового синтаксиса. Он представляет собой имя удаленной ветки, которое указывается сразу после двоеточия: git push origin branch:server_branch В этом примере в качестве имени локальной ветки используется branch, а вот имя удаленной ветки на сервере указывается вместо server_branch.
Отправка всех веток на сервер
Просто пропишите вместо имени ветки — all: git push origin —all Затем все закомиченные апдейты во всех ветках переносятся в удаленный репозиторий.
Отправка текущей ветки
Существует очень простой и популярный метод для отправки текущей ветки с тем же именем на сервере, а именно: git push origin HEAD В данном примере на текущую ветку указывает “HEAD”. Использование такого метода убирает необходимость в запоминании имени ветки, в которой вы сейчас работаете.
Принудительная публикация (git push — force …)
При попытке отправить публикацию может возникнуть ошибка Git push rejected. Она указывает на то, что пуш отклонили. Лучше всего обратиться к подсказке к ошибке, получив и смержив изменения, а затем повторно их отправить. Данная проблема может появится в том случае, когда git проверяет, что созданный вами коммит формируется на базе предыдущих коммитов. В то время, как вы работали с частью кода, другие разработчики могли редактировать ту же часть, что и вы. Именно поэтому git не сможет провести автоматическое слияние, а ваш коммит существовал ранее и не базируется на измененных коммитах в удаленном репозитории. Для отключения проверки коммитов и при потребности в перезаписи истории используется флаг — force, или же его сокращенная версия — f: git push —force Важно! Эту команду нужно использовать с осторожностью и только иногда, так как в этом случае коммиты других разработчиков команды будут стерты.
Принудительная публикация с параметром (git push — force-with-lease …)
Более безопасный вариант принудительного пушинга изменений, но так же нежелательный. Особенность данного метода заключается в том, что он не перезаписывает изменения в удаленной ветке тогда, когда в нее были внесены коммиты от других разработчиков: git push —force-with-lease Но другие разработчики могут столкнуться с упомянутой выше ошибкой – Git push rejected
Как пушить в PhpStorm
Использовать пуш в PhpStorm достаточно просто. Изначально создайте новый проект, в правом углу среды разработки расположены распространенные команды git, среди которых команды для пушинга.
Незапушенные коммиты
Вы можете распознать коммиты, которые не запустились, следующим образом: git status В предоставленной информации будет находится название текущей ветки и то, превышает ли она версию сервера и насколько. Также можно посмотреть лог с историей коммитов с помощью команды: git log
Как пушить теги
Для создания тегов применяется git tag, а для отправки: git push origin
Удаление ветки или тега на сервере
Вы можете легко удалить ветку на удаленном репозитории с помощью команды: git push —delete origin Удалить локальную ветку можно с использованием данной команды: git branch —d Для того, чтобы удалить локальный тег: git tag —d
Продвинутые возможности
Удаление локальных данных (prune)
Удалить все имеющиеся локальные ветки, которые отсутствуют на сервере, можно с помощью следующей команды: git remote prune origin
Проверить, удастся ли пушинг (dry run option)
Данная функция фактически не произведет пушинг, однако покажет вам вывод будто он получился: git push —dry-run
Атомарный пушинг (atomic option)
Применяется, когда на сервер отправляется сразу множество веток с возможной опцией отклонения одних и успешного пушинга других. Если необходимо, чтобы отправились все ветки, либо все были отклонены используйте команду: git push —atomic origin branch1 branch2 …
Заключение
В данном обзоре мы разобрались с самыми популярными методами применения git push. Однако реальные возможности данной команды намного шире. Вы можете самостоятельно с ними ознакомится благодаря документации: git push —help