Форс пуш что это
Как стать 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 для начинающих. Урок 6.
git push и git pull
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.
Что такое push (пуш)
Зачем пушить на сервер
Когда пушить на сервер
Когда сделали новый коммит или несколько коммитов
Как узнать, что есть незапушенные коммиты
В командной строке набрать git status
Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая
«is up-to-date» означает, что у нас нет незапушенных коммитов
master и origin/master
git push в терминале
Как пушить в PhpStorm
Что такое pull (пулл)
Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.
Зачем пулиться с сервера
Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах
git pull в терминале
Как пулить в PhpStorm
Когда что-то пошло не так.
Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры
git push rejected
Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое
Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?
Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.
Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.
Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.
Как избавиться от мердж-коммита
Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.
При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.
Мердж-коммит в PhpStorm
PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.
Что могу посоветовать
Если мы работаем в одиночку, то удаленный репозиторий нужен только для сохранения резевной копии. Скорее всего, мы будем в него только пушить.
Но при работе в команде имеет смысл подумать над такими вещами:
Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.
В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.
Я слышал, что умение ответить на этот вопрос на собеседовании в некоторых компаниях является критерием прохождения собеседования на сеньорские позиции. Но чтобы лучше понять ответ на него, нужно разобраться, почему вообще плохо переписывание истории?
Для этого, в свою очередь, нам понадобится быстрый экскурс в физическую структуру 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 — делитесь ими в комментариях!
Force «git push» для перезаписывания удаленных файлов
Я хочу нажимать свои локальные файлы и иметь их на удаленном репо, не имея дело с конфликтами слияния. Я просто хочу, чтобы моя локальная версия имела приоритет над удаленным.
Как я могу сделать это с помощью Git?
ОТВЕТЫ
Ответ 1
Вы можете заставить локальную ревизию удаленного репо использовать
Просто будьте осторожны, если другие люди используют этот репозиторий, их история изменений будет конфликтовать с новой. И если у них есть локальные коммиты после момента изменения, они станут недействительными.
Обновление. Думаю, я добавлю примечание. Если вы создаете изменения, которые будут рассмотрены другими, то нередко создавать ветку с этими изменениями и периодически обновлять, чтобы поддерживать их в актуальном состоянии с основной ветвью развития. Просто сообщите другим разработчикам, что это произойдет периодически, чтобы они знали, чего ожидать.
Обновление 2. Из-за увеличения числа зрителей я хотел бы добавить дополнительную информацию о том, что делать, когда ваш upstream действительно испытывает силовое нажатие.
Скажем, я клонировал ваше репо и добавил несколько коммитов:
Принудительное нажатие с «арендой» позволяет принудительному нажатию выйти из строя, если новые коммиты на пульте дистанционного управления, которых вы не ожидали (технически, если вы еще не принесли их в свою ветку удаленного отслеживания), которая полезно, если вы не хотите случайно перезаписать чужой что вы даже не знали об этом, и вы просто хотите перезапишите свои собственные:
Ответ 2
Вы хотите принудительно нажать
То, что вы в основном хотите сделать, это принудительно надавить на вашу локальную ветвь, чтобы перезаписать удаленный.
Если вы хотите получить более подробное объяснение каждой из следующих команд, см. раздел «Мои данные» ниже. В основном у вас есть 4 разных варианта для принудительного нажатия Git:
Если вы хотите получить более подробное объяснение каждой команды, см. ниже раздел моих длинных ответов.
Предупреждение: принудительное нажатие перезапишет удаленную ветвь с состоянием ветки, которую вы нажимаете. Убедитесь, что это то, что вы действительно хотите сделать, прежде чем использовать его, иначе вы можете переписать фиксации, которые вы действительно хотите сохранить.
Детали принудительного нажатия
Указание удаленного и ветки
Опускание ветки
Когда ветвь, нажавшая ветвь, не указана, Git будет определять ее на основе ваших настроек конфигурации. В версиях Git после версии 2.0 новое репо будет иметь настройки по умолчанию, чтобы нажать текущую отмеченную ветку:
Опускание пульта и ветки
До версии Git версии 2.0 значение по умолчанию matching в основном просто подталкивает все локальные ветки к ветвям с таким же именем на пульте дистанционного управления (по умолчанию это начало).
Принудительное нажатие на «аренду» позволяет принудительному нажатию выйти из строя, если на пульте нет новых коммитов, которые вы не ожидали (технически, если вы еще не набрали их в свою ветку удаленного отслеживания), что полезно, если вы не хотите случайно перезаписывать кого-то еще, который еще не знал, и вы просто хотите перезаписать свой собственный:
Ответ 3
Другой вариант (чтобы избежать принудительного толчка, который может быть проблематичным для других участников), заключается в следующем:
Таким образом, вы можете выдвинуть мастер на дистанцию без необходимости что-либо форсировать.
Ответ 4
Ответ 5
Ответ 6
Простые шаги с помощью черепахи
GIT передает локальные файлы и помещает их в репозиторий git.
1) изменения stashа заначка
2) тянуть
3) Сундук с надписью
4) совершить 1 или более файлов и дать изменения фиксации описание установить автора и дату
Малоизвестные Git-команды
У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.
git please
Каждому разработчику приходилось хотя бы раз общаться со своим тимлидом на тему принудительного пуша (force pushing) в общую ветку (не делайте этого). Ребейз (rebasing), внесение правок и squash — всё это забавно до тех пор, пока вы не перезапишете часть общей истории и не раскидаете дублирующиеся коммиты по всему репозиторию. К счастью, Git не позволит вам невольно перезаписать историю на сервере. Вам придётся явным образом передать в git push опцию —force, чтобы доказать серьёзность своих намерений. Но принудительный пуш — это грубый подход: вы затаптываете локальной версией вышерасположенную ветку, и все изменения, которые вы к тому моменту не подтянули (fetch), будут стёрты из истории.
git commend
Бывало так, что вы закоммитили и тут же сообразили, что забыли проиндексировать (stage) файл? Больше не нужно об этом беспокоиться! Алиас git commend тихо прикрепляет к последнему созданному вами коммиту все проиндексированные файлы, повторно используя уже имеющееся сообщение о коммите.
git it
Первому коммиту в репозитории нельзя сделать ребейз, как обычному. Поэтому рекомендуется в качестве корневого создавать пустой коммит. Алиас git it инициализирует ваш репозиторий и за одну операцию создаёт пустой корневой коммит. И когда вы в следующий раз запустите проект, то не надо просто добавлять его в систему управления версиями: выполните git it!
git staaash
git stash — одна из самых восхитительных и полезных Git-команд. Она регистрирует все изменения, вносимые в отслеживаемый файл в вашем рабочем дереве, и скрывает их для последующего использования, а вам показывает чистое дерево, чтобы вы могли спокойно работать с другой его частью. Но если вы создали новые файлы и ещё не проиндексировали их, то по умолчанию git stash их не тронет, поэтому у вас будет неопрятное рабочее дерево. Соответственно, по умолчанию не скрывается и содержимое неотслеживаемых или игнорируемых файлов.
Я сделал несколько удобных алиасов для разных вариантов git stash, в зависимости от того, какие биты вашего рабочего дерева нужно скрыть:
Если сомневаетесь в выборе, то самый длинный алиас (git staaash) всегда сможет восстановить рабочее дерево состояния свежего клона вашего репозитория.
git shorty
Я запускаю git status чаще любой другой Git-команды. Встроенная помощь в Git за последние годы стала куда удобнее, что очень хорошо для начинающих, но для более опытных пользователей информация слишком многословна. Например, git status объясняет мне в 12 строках, что у меня пара индексированных, неиндексированных и неотслеживаемых изменений:
Всё то же самое git shorty говорит мне тремя строками:
Для краткости я сделал это в виде алиаса git st, не смог остановиться.
git merc
Если вы используете обычный рабочий процесс ветвления без ребейза, то будет не лучшим решением запускать стандартный git merge для слияния веток с фичами с мастер-веткой. Если не добавить к этой команде опции, то по умолчанию станет использоваться стратегия слияния —ff, при которой новый коммит слияния будет создан только в том случае, если в мастер-ветке нет новых изменений. В противном случае мастер-ветка просто «перемотается» до места последнего коммита в вашей ветке. Лишь иногда, создавая коммит слияния, при просмотре Git-истории бывает непросто сказать, какой код был разработан в какой ветке.
git merc использует стратегию —no-ff, при которой всегда создаётся коммит слияния.
Между прочим, —no-ff всегда используется по умолчанию в ходе слияния pull request’ов в Bitbucket.
git grog
Мой алиас git grog (или graphical log) в последние годы разросся настолько, что я больше не уверен, будто точно знаю, что он делает. Но выглядит красиво:
Для сравнения, вот стандартный git log:
Там доступны все виды удобных форматов, так что форкайте вышеуказанную команду и пользуйтесь на здоровье!
Для поклонников GUI
Если вы поклонник Git GUI и работаете под Mac или Windows, то, возможно, вы используете наш бесплатный Git-клиент Atlassian SourceTree. Если да, то примените описанные в этой статье алиасы, создав новое кастомное действие — можно назначить комбинацию клавиш — в настройках SourceTree:
Это действие запускается с помощью меню (Actions → Custom Actions) или клавиатурной комбинации: