Git Commit vs Push: What’s the Difference?
Many coders have used Git at one point or another. In fact, for most, it’s the version control system of choice since it’s open-source and easy to use.
A common discussion that comes up is Git commit vs push, or more specifically, how the two commands differ. In this post, you’ll learn more about these two coding terminologies, their differences, and how they work in tandem.
What is Git commit? ��
Think of a git commit as a snapshot that make up a file system. When you commit, you save your project, and Git records the work by taking a snapshot of the metadata and saving it in the local repository.
During a project, the author will create dozens or even hundreds of commits for every update.
What about staging?
You may also have heard of a Git stage; this is an integral part of a commit. Think of a Git stage as a staging area, or an intermediary step between making updates and committing. Through a Git index command, you move changes from the working repository into the staging area where the updates are ready to be committed. The working repository and staging area are all substations within the local repository.
What is Git push? ��
Every developer has their own local repository where they store commits and create new ones. Updates are always completed at the local level. When you’re ready to share them with other developers, you move, or “push” the changes to the remote repository. You actively push the commits using the Git push command. The commits are now viewable by other developers in your collaboration circle or to the public at large.
You can think of a Git push as an update or publish. Depending on the nature of the project, only selecting members with authorization may be able to push commits to the remote repository.
Git commit vs push: Examining the difference ��
A differential element is that a commit always comes before a push. You have to create or update data, then save the information with a commit. This happens at the local level where only you and select members have access. Then, if you choose, you can push the commit to the remote repository where it becomes available to all developers.
In short, the scope of Git commit is at the local level while the scope of Git push is at the upstream and remote level.
Git commit vs Git push: Side-by-side comparison
Here’s a deeper look at the differences between Git commit and Git push.
What about Git fetch and Git pull? ��
You may also wonder about how Git fetch and pull factor into this and their relation to commits and pushes.
In addition to local and remote repositories, there are also clone repositories, in which you receive a duplicate of another developer’s original repository shared in the remote repository. Changes made thereafter to the original repository don’t affect your clone repository.
A Git fetch commands the local Git to check on updates from the original repository that you received a duplicate copy of. A Git pull checks for updates and also transfers the changes to your clone repository.
Relationship to a Git commit and Git push ��
So, how are Git commit, push, fetch, and pull commands all connected?
You can make your own updates to the cloned repository even as you continue to get transferable updates through a Git pull. Save the updates with a commit. Use a Git push to share the changes in the remote repository where it can be viewed by other developers, including the developer whose repository you cloned.
These four commands are essential tools in the GitHub space and cornerstones for remote collaborative work. The difference between commit and push also becomes more apparent as you can see their respective applications occur in different stages of the development cycle.
Automation with Mergify made easy ��
Between commit vs push Git, there are multiple steps that come before, in between, and after. It’s an intricate process that can be simplified with Mergify. Save time by automating merge queues that would otherwise have to be performed manually.
Streamline your development cycle today by making Mergify an integral part of your daily operations. Sign up for a free Mergify trial today.
Когда использовать commit, tag, branch, push в Git?
В каком случае что использовать? С репозиторием работает один человек, git используется для удобства. Фишки совместной работы не берем. 1) Commit, насколько я понимаю, нужен для фиксации последовательных изменений. Но для меня не понятно, когда его использовать. Хочу откатиться на предыдущие коммиты, последующие все равно остаются, получается бардак. Фактически полезен он только для отката последних действий. Откатываться назад вглубь более, чем на один коммит — это уже беда. Если есть часть изменений, которую надо откатить, но сделаны и другие изменения, то эти другие утеряются. Верно? Какова польза коммита? 2) Branch, насколько я понимаю, нужен как раз в случае, если есть какие-то изменения, которые надо откатить, и те, которые не надо. Путем манипуляций с ветками я могу создавать нужную комбинацию того, что мне нужно оставить. Каковы основные случаи использования branch? 3) Как в общую концепцию вписываются теги? Какого их основное назначение? 4) Когда я должен использовать push? У меня все работает, я уверен, что это важная веха — сохраняю на сервер?
Отслеживать
задан 2 сен 2018 в 22:59
John Smith John Smith
121 2 2 бронзовых знака
3 сен 2018 в 2:36
1. Обычно commit делают когда вы сделали какую то работу, после завершения которой код опять находится в работоспособном состоянии. можно откатить любой коммит с помощью git revert. 2. ветки полезны, когда вы делаете какую то крупную работу и в процессе этого вам иногда надо не доделав ее до конца быстро сделать что то совершенно другое. и выложить изменения стабильной версии +изменения по срочной работе, но не выкладывая на половину разломанный код образовавшийся из за незавершенной первой работы.
3 сен 2018 в 6:59
push в вашем случае нужен только для бекапа. А вообще, даже если выработаете один над каким то важным проектом, обычно у вас существует развернутый где то стабильный код, который в работе у пользователей и отдельно ваша отладочная версия. с помощью push/pull вы выкатываете на продакт те изменения, которые делали у себя отладке
Гит-словарик для начинающих программистов
Мы часто упоминаем Git — способ организации хранения и контроля версий файлов в рабочем проекте. Сегодня расскажем о странных словах: «бранч», «коммит», «пулл-реквест» и об остальных понятиях в гите.
О чём речь
Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.
Главная особенность гита — он помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.
На базе гита есть сервис «Гитхаб». Работает так:
- все рабочие файлы проекта синхронизируюся между облаком и вашим компьютером;
- такая синхронизация происходит у каждого участника проекта;
- можно настроить автоматическую синхронизацию, а можно отправлять изменения вручную;
- можно отправить на сервер изменения, которые сделали вы на своём компьютере, а можно наоборот — скачать себе те, которые внесли в проект другие программисты.
Это полезно, например, когда несколько человек параллельно пилят совместный проект. Каждый работает над своим файлом или даже своим куском одного файла. Всю работу авторы синхронизируют между собой: чтобы не было ситуации, что два человека редактируют один и тот же файл, а потом затирают результаты работы друг друга, сами того не зная.
Это если вкратце. Теперь будут подробности.
Что такое репозиторий (git repository)
Гит-репозиторий — это облачное хранение вашего проекта на сервере (например, на сервере Гитхаба, но можно и на другом).
У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект. А можно вести все проекты в одном репозитории, но тогда это превратится в мешанину. Но каждый имеет право на мешанину.
В репозитории могут храниться:
- файлы с исходным кодом проекта;
- базы данных;
- картинки и графики;
- текстовые файлы;
- и всё остальное, что нужно проекту для работы.
Что такое бранч (git branch)
Бранч — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.
В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки.
Дело в том, что ветка master используется для выпуска новых версий проекта, которые будут доступны всем. То, что добавляется в мастер-бранч, сразу становится доступно пользователям.
Но представьте такую ситуацию: мы только что запустили сайт для заказчика и он срочно хочет добавить интерактивный раздел со скидками. Можно сделать так: править рабочие файлы проекта «по живому», чтобы сразу видеть результат. А можно сделать из мастера отдельную ветку news и работать уже в ней (и это очень похоже на форк). В этом случае мы получим полную копию проекта, в которую можно вносить любые правки и они никак не повлияют на запущенный сайт. Мы в этой ветке пилим всё, что нужно клиенту, показываем ему результат на секретном сайте, а потом объединяем её с мастером. Это называется «смёржить бранчи».
Что такое клонирование (git clone)
Клонирование — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять.
Чем это отличается от простого копирования: когда вы клонируете репозиторий, вместе с файлами вашего проекта вы также тянете всю историю версий, все ветки, всю историю работы. И если кто-то дальше будет вносить изменения в проект, благодаря этим данным вы сможете тоже их получить.
А если просто скопировать нужные файлы с чужого компьютера, то никаких историй и никаких связей не сохранится. Синхронизации не будет. Просто какие-то файлы.
Что значит «смёржить» (git merge)
Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.
Получается, что схема работает так:
- Запускаем в мастере рабочий код с первой версией сайта, которая автоматически отправляется в продакшен (на сборку).
- Создаём новую ветку на основе мастера.
- В этой новой ветке пишем новый код, который добавит интерактивные функции на сайт.
- Тестируем эту ветку как отдельный проект.
- Если всё в порядке — смёрживаем её в мастер и получаем сразу готовую сборку сайта с новыми возможностями.
Что такое коммит (git commit)
Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит.
Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы.
Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.
Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.
Коммитить можно хоть после правки каждой строчки — весь вопрос в том, насколько нужна такая детализация в проекте. Но иногда и изменения из одной строчки можно закоммитить, если оно действительно важное.
Что такое пуш и пулл (git push, git pull)
Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.
Иногда бывает так, что сервер отказывается это сделать, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать запросы из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью git pull.
Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.
Чем коммит отличается от пуша
Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.
Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.
Получается, последовательность действий такая:
- Вы подключаетесь к репозиторию и клонируете его.
- Делаете себе новую ветку.
- Перед началом работы делаете пулл, чтобы забрать актуальную версию файлов.
- Пилите в своей ветке то, что вам нужно.
- Когда работа сделана, вы её коммитите.
- Чтобы отправить её другим ребятам, вы её пушите.
- Когда работу одобряют и перепроверяют, вашу ветку мержат (сливают, склеивают) с мастер-веткой.
- Пользователи счастливы, что вы добавили им новых возможностей.
Что дальше
Чтобы все эти бранчи и реквесты стали понятнее, в следующий раз сделаем вот что: заведём учебный проект на Гитхабе и будем работать с ним так, как делают настоящие программисты.
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, введите в консоли команду