git push force что делает
Git push
Использование git push
Публикация указанной ветки в удаленном репозитории вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, Git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние.
Публикация всех локальных веток в указанном удаленном репозитории.
Обсуждение git push
Команда git push чаще всего используется для публикации выгружаемых локальных изменений в центральном репозитории. Для того чтобы поделиться изменениями, внесенными в локальный репозиторий, с удаленными участниками команды, необходимо выполнить команду push.
Git push и синхронизация
Публикация в чистые репозитории
Принудительная публикация
Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, если нельзя выполнить их ускоренное слияние. Так, если история удаленного репозитория отличается от вашей истории, необходимо загрузить удаленную ветку командой pull и выполнить ее слияние с локальной веткой командой merge, а затем попробовать выполнить команду push еще раз. Это похоже на то, как в SVN необходимо синхронизироваться с центральным репозиторием с помощью команды svn update перед тем, как сделать коммит набора изменений.
Примеры
Команда git push по умолчанию
Поскольку мы уже убедились, что локальная главная ветка была обновлена, должно произойти ускоренное слияние, а команда git push не должна сообщать о каких-либо описанных выше проблемах, связанных с невозможностью выполнения такого слияния.
Принудительная команда push при исправлении коммитов
Стирание удаленной ветки или тега
Иногда ветки необходимо чистить для наведения порядка. Чтобы полностью стереть ветку, ее необходимо стереть как в локальном репозитории, так и в удаленном.
Первая команда сотрет локальную ветку с именем branch_name. Если в команде git push перед именем ветки поставить двоеточие, будет стерта удаленная ветка.
Git push, git pull, git fetch — в чем разница? Шпаргалка по git-командам
Git — это распределенная система контроля версий. Она позволяет хранить данные обо всех изменениях кода в конкретных папках на жестком диске и обеспечивает удобную командную работу.
Git push
Команда git push в ходе выполнения переносит все изменения, внесенные юзером, в удаленный репозиторий (например, такой как GitHub):
Вынужденная команда push при корректировке коммитов:
Git pull
Команда git pull отвечает за скачивание данных с сервера. Процесс очень похож на клонирование репозитория, но здесь скачиваются не все коммиты, а только новые.
По сути, git pull — это сочетание команд git fetch (загружает коммиты, ссылки, файлы из удаленного репозитория в локальный) и git merge (объединяет несколько коммитов в один общий).
Git pull для удаленной ветки
Git fetch
Синхронизация с командой git fetch origin
Это отобразит ветки, которые уже были загружены:
Git merge
Команда git merge связывает ряд коммитов в одно целое. В свою очередь git создает коммит слияния, где и объединяются изменения обеих последовательностей.
Конфликт в слиянии
По завершению слияния, выполните команду git add : таким образом вы проинформируете, что причина конфликта разрешена. Важно запомнить, что конфликты допустимы только в трехслойном слиянии и никогда не возникают при ускоренном.
Разница между командами git
Условно говоря, git pull – это последовательность двух команд: git fetch (прием изменений от сервера) и git merge (слияние).
В свою очередь, git push переносит ветвь разработки в удаленную исходную точку, а git merge — объединяет изменения из разработки в локальную ветку.
Шпаргалка по git-командам
git init — создание новых репозиториев;
git clone — клонирование удаленного репозитория;
git rm — удаление файла;
git log — просмотр истории коммитов;
git branch
— создание новой ветки;
git branch –d
— удаление ветки;
git merge
— слияние веток;
git push
— отправка ветки на удаленный сервер;
git push :
— удаление ветки на удаленном сервере;
git tag — просмотр меток;
git push — обмен метками;
git remote — отображение удаленных репозиториев;
git pull
— получение данных из удаленного репозитория и слияние с локальным;
git push
— отправка локальных изменений на удаленный сервер.
Я слышал, что умение ответить на этот вопрос на собеседовании в некоторых компаниях является критерием прохождения собеседования на сеньорские позиции. Но чтобы лучше понять ответ на него, нужно разобраться, почему вообще плохо переписывание истории?
Для этого, в свою очередь, нам понадобится быстрый экскурс в физическую структуру git-репозитория. Если вы точно уверены, что знаете об устройстве репо всё, то можете пропустить эту часть, но даже я в процессе выяснения узнал для себя довольно много нового, а кое-что старое оказалось не вполне релевантным.
На самом низком уровне git-репо представляет собой набор объектов и указателей на них. Каждый объект имеет свой уникальный 40-значный хэш (20 байт, записанные в 16-ричной системе), который вычисляется на основе содержимого объекта.
Основные типы объектов — это blob (просто содержимое файла), tree (набор указателей на blobs и другие trees) и commit. Объект типа commit представляет собой только указатель на tree, на предыдущий коммит и служебную информацию: дата/время, автор и комментарий.
Где здесь ветки и тэги, которыми мы привыкли оперировать? А они не являются объектами, они являются просто указателями: ветка указывает на последний коммит в ней, тэг — на произвольный коммит в репо. То есть когда мы в IDE или GUI-клиенте видим красиво нарисованные веточки с кружочками-коммитами на них — они строятся на лету, пробегая по цепочкам коммитов от концов веток вниз к «корню». Самый первый коммит в репо не имеет предыдущего, вместо указателя там null.
Итак, почему же переписывание истории репозитория вредно?
Итак, развеяв опасения перед изменением истории репозитория, можно, наконец, перейти к главному вопросу: зачем оно нужно и когда оправдано?
Но это тривиальный случай. Давайте рассмотрим более интересные.
Допустим, вы сделали большую фичу, которую пилили несколько дней, отсылая ежедневно результаты работы в репозиторий на сервере (4-5 коммитов), и отправили свои изменения на ревью. Двое-трое неутомимых ревьюверов закидали вас крупными и мелкими рекомендациями правок, а то и вовсе нашли косяки (ещё 4-5 коммитов). Затем QA нашли несколько краевых случаев, тоже требующих исправлений (ещё 2-3 коммита). И наконец при интеграции выяснились какие-то несовместимости или попадали автотесты, которые тоже надо пофиксить.
Но бывает также, что к код-ревью вы уже подошли с историей репо, напоминающей салат «Оливье». Такое бывает, если фича пилилась несколько недель, ибо была плохо декомпозирована или, хотя за это в приличных коллективах бьют канделябром, требования изменились в процессе разработки. Вот, например, реальный merge request, который приехал ко мне на ревью две недели назад:
У меня рука машинально потянулась к кнопке «Report abuse», потому что как ещё можно охарактеризовать реквест из 50 коммитов с почти 2000 изменённых строк? И как его, спрашивается, ревьюить?
Честно говоря, у меня ушло два дня просто на то, чтобы заставить себя приступить к этому ревью. И это нормальная реакция для инженера; кто-то в подобной ситуации, просто не глядя, жмёт Approve, понимая, что за разумное время всё равно не сможет сделать работу по обзору этого изменения с достаточным качеством.
Но есть способ облегчить жизнь товарищу. Помимо предварительной работы по лучшей декомпозиции задачи, уже после завершения написания основного кода можно привести историю его написания в более логичный вид, разбив на атомарные коммиты с зелёными тестами в каждом: «создал новый сервис и транспортный уровень для него», «построил модели и написал проверку инвариантов», «добавил валидацию и обработку исключений», «написал тесты».
Каждый из таких коммитов можно ревьюить по отдельности (и GitHub, и GitLab это умеют) и делать это набегами в моменты переключения между своими задачами или в перерывах.
50 (подставьте вместо “50” вашу цифру).
Кстати, если вы в процессе работы над задачей подливали к себе ветку master, то сначала надо будет сделать rebase на эту ветку, чтобы merge-коммиты и коммиты из мастера не путались у вас под ногами.
Вооружившись знаниями о внутреннем устройстве git-репозитория, понять принцип действия rebase на master будет несложно. Эта команда берёт все коммиты в нашей ветке и меняет родителя первого из них на последний коммит в ветке master. См. схему:
Иллюстрации взяты из книги Pro Git
Если изменения в C4 и C3 конфликтуют, то после разрешения конфликтов коммит C4 изменит своё содержание, поэтому он переименован на второй схеме в C4’.
Да, и кстати, вы можете поменять коммиты местами. Возможно, это создаст конфликты, но в целом процесс rebase редко обходится совсем уж без конфликтов. Как говорится, снявши голову, по волосам не плачут.
Вы можете повторять rebase несколько раз, затрагивая только части истории, и оставляя остальные нетронутыми при помощи pick, придавая своей истории всё более и более законченный вид, как гончар кувшину. Хорошим тоном, как я уже написал выше, будет сделать так, что тесты в каждом коммите будут зелёными (для этого отлично помогает edit и на следующем проходе — squash).
Поначалу вы, скорее всего, будете тратить на этот процесс (включая первоначальный rebase на master) час, а то и два, если фича реально развесистая. Но даже это намного лучше, чем ждать два дня, когда ревьювер заставит себя наконец взяться за ваш реквест, и ещё пару дней, пока он сквозь него продерётся. В будущем же вы, скорее всего, будете укладываться в 30-40 минут. Особенно помогают в этом продукты линейки IntelliJ со встроенным инструментом разрешения конфликтов (full disclosure: компания FunCorp оплачивает эти продукты своим сотрудникам).
Последнее, от чего хочется предостеречь, — не переписывайте историю ветки в процессе код-ревью. Помните, что добросовестный ревьюер возможно клонирует ваш код к себе локально, чтобы иметь возможность смотреть на него через IDE и запускать тесты.
Спасибо за внимание всем, кто дочитал до конца! Надеюсь, что статья будет полезна не только вам, но и коллегам, которым ваш код попадает на ревью. Если у вас есть клёвые хаки для git — делитесь ими в комментариях!
Как стать Git-мастером: 7 советов по повышению производительности
Oct 25, 2019 · 4 min read
Автозаполнение команд Git в терминале
Git предоставляет сценарий автозаполнения, который нужно скачать для использования этой функции. Запустите следующую команду для скачивания сценария в домашнюю директорию:
Этот фрагмент выполняет поиск сценария автозаполнения в домашней директории и, при наличии запускает его при каждом входе в bash.
Локальное удаление ветки в удаленном репозитории
С помощью команды push можно быстро удалить ветку в удаленном репозитории из локальной системы. Предположим, что у вас уже есть доступ к удаленному репозиторию.
Force Push без рисков
Отмена изменений в Git
Несмотря на определенную пользу Git в большинстве случаев, иногда необходимо внести изменения в некоторые операции. В этом разделе мы обсудим отмену трех типов изменений — отслеживание файла, внесение изменений и создание коммита.
Чтобы отменить процесс отслеживания файла с Git, запустите следующую команду:
Для отмены внесения изменений в файл с момента последнего коммита выполните следующее:
Эта команда отменяет статус репозитория до N коммитов перед HEAD и не приводит к изменениям в файлах.
Сохранение незафиксированных изменений с помощью stash
Представьте, что вы работаете с новой функцией, а начальник спрашивает о ходе выполнения предыдущего задания. Текущая функция еще не завершена, поэтому создание коммита не имеет логического смысла. Что же нужно сделать?
На помощь приходят Git stash. Следующая команда сохраняет все незафиксированные изменения и возвращается к состоянию репозитория при последнем коммите.
Чтобы возобновить работу над этой функцией, используйте следующую команду для проверки всех stashes:
Эта команда показывает список всех сохраненных stash с отметками времени. Применить N-й stash из списка stash можно с помощью следующей команды:
Выборочная фиксация изменений из файла
Обработка больших файлов с помощью Git LFS
Git хорошо справляется с текстовыми файлами, однако не способен эффективно обрабатывать двоичные файлы. Документы Excel, проекты Photoshop и другие исполняемые файлы — примеры таких двоичных файлов.
На помощь приходит Git LFS! Это open source расширение для Git, которое управляет большими двоичными файлами, помещая текстовые указатели в Git и сохраняя содержимое файла на удаленном сервере. В результате повышается эффективность процесса управления репозиторием, в то время как удаленный сервер обрабатывает большие двоичные файлы при внесении изменений.
После загрузки и установки в локальной системе инициализируйте Git LFS для каждого репозитория с помощью следующей команды:
Чтобы отследить один тип расширения файла (например, PSD), выполните следующую команду:
Бонусный совет: отладка с помощью Git
Знаете ли вы, что Git — очень эффективный инструмент для устранения проблем в кодовой базе? Git Blame помогает тщательно проанализировать историю файла, а процесс Bisect инициирует бинарный поиск по коммитам.
Заключение
На этом наш список завершен. В этом руководстве мы рассмотрели семь советов (и даже бонусный!) по повышению эффективности рабочего процесса.
Git push в удаленный репозиторий или как залить локальную ветку в origin
Перевод статьи «Git Push to Remote Branch – How to Push a Local Branch to Origin».
Как запушить локальную ветку git в origin
Вообще синтаксис команды следующий:
В примере, приведенном ниже, удаленный origin — это GitHub-репозиторий, а текущая ветка — main :
В выводе вы можете увидеть, что локальная ветка main была запушена в удаленную ветку main :
Как принудительно запушить ветку
Обычно вы заливаете что-то в ветку и пополняете ее историю коммитов.
Но бывает, что вам нужно принудительно перезаписать историю ветки. Такая необходимость может возникнуть по двум причинам.
Во-первых, для исправления ошибки. Хотя в этом случае лучше, пожалуй, просто сделать новый коммит, откатывающий изменения.
Во-вторых (и этот вариант случается чаще), вы можете захотеть перезаписать историю ветки после выполнения rebase, меняющего историю коммитов:
Git осуществляет rebase путем создания новых коммитов и применения их к указанной основе (base). Очень важно понимать, что хотя ветка выглядит так же, как выглядела, она составлена из совершенно новых коммитов.
rebase создает совершенно новые коммиты.
Это означает, что если вы попытаетесь запушить ветку, которая локально была «перебазирована», а удаленно — нет, удаленный репозиторий распознает, что история коммитов изменилась, и не даст вам запушить ваши изменения, пока вы не устраните различия:
Принудительный push деструктивен, так что используйте его, только когда вы уверены, что именно этого и хотите.
Принудительный push с оговоркой
Может случиться такое, что вы хотите выполнить принудительный push, но только если никто другой не менял ничего в ветке.
Если кто-то поработал с вашей веткой и запушил свои изменения в удаленный репозиторий, а вы после этого принудительно запушите свои, — вы перезапишете изменения, внесенные вашим коллегой.
С этим флагом вы говорите Git принудительно обновить ветку только в том случае, если она выглядит точно так же, как когда вы ее видели в последний раз.
Как запушить изменения в ветку с другими именем
Обычно вы отправляете вашу локальную ветку в удаленную ветку с тем же именем (т. е. локальную my-feature — в удаленную my-feature ), но так бывает не всегда.
Чтобы запушить локальную ветку в удаленную ветку с другим именем, вам нужно указать имена обеих веток, разделив их двоеточием.
Как запушить все локальные ветки в удаленный репозиторий
Заключение
Команда git push — одна из тех, что используются наиболее часто. Она имеет много вариантов использования и соответствующих опций. Найти их можно в документации.