Word for push and pull

Git для начинающих. Урок 6.
git push и git pull

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

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

Что такое push (пуш)

Это отправка данных на сервер, в удаленный репозиторий, на github. Данные — это коммиты и ветки.

Зачем пушить на сервер

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

Когда пушить на сервер

Когда сделали новый коммит или несколько коммитов

Как узнать, что есть незапушенные коммиты

В командной строке набрать git status

Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая

«is up-to-date» означает, что у нас нет незапушенных коммитов

В PhpStorm понять, есть ли неотправленные коммиты, можно посмотрев в окно Version Control — Log, где находятся метка master и origin/master. Если master выше, то есть незапушенные коммиты.

master и origin/master

Это ветки: локальная и удаленная (на сервере, в github). По умолчанию мы находимся в ветке master. Подробно работу с ветками мы рассмотрим в следующем уроке, а пока достаточно запомнить, что master — это то, что на нашей машине, а origin/master — в удаленном репозитории, на github.

git push в терминале

• push — что сделать, отправить
• origin — куда, на сервер
• master — что, ветку master

Как пушить в PhpStorm

Правый клик — Git — Repository — Push. — Кнопка Push

Что такое pull (пулл)

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

Зачем пулиться с сервера

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

git pull в терминале

• pull — что сделать, получить данные
• origin — откуда, с сервера
• master — а точнее, с ветки master

Как пулить в PhpStorm

Правый клик — Git — Repository — Pull. — Кнопка Pull

Когда что-то пошло не так.

Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры

git push rejected

Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое

Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?

Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.

Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected. Значит, нам нужно сначала сделать git pull, а затем снова запушить

Здесь нас подстерегает неожиданность — в терминале выскакивает окно редактирования коммита. Пока просто сохраним, что предложено по умолчанию и закроем редактор. Вот теперь можно пушить свои коммиты

Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.

Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.

Как избавиться от мердж-коммита

Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.

Чтобы избавиться от него, подтягивайте изменения командой git pull с флажком —rebase

При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.

Мердж-коммит в PhpStorm

PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

Что могу посоветовать

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

Но при работе в команде имеет смысл подумать над такими вещами:

• пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
• пулиться почаще — обратная ситуация, почаще получать свежие изменения
• всегда пультесь с флажком ребейза — git pull —rebase origin master
• не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
• не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
• больше практикуйтесь. Посадите домашний проект на git и работайте с ним

Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Git push в удаленный репозиторий или как залить локальную ветку в origin

Перевод статьи «Git Push to Remote Branch – How to Push a Local Branch to Origin».

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

Как запушить локальную ветку git в origin

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

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

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

Если ваша текущая ветка — main , а вы запустите на выполнение просто git push , на самом деле будет выполняться git push origin main .

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

В выводе вы можете увидеть, что локальная ветка main была запушена в удаленную ветку main :

Как принудительно запушить ветку

Обычно вы заливаете что-то в ветку и пополняете ее историю коммитов.

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

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

Во-вторых (и этот вариант случается чаще), вы можете захотеть перезаписать историю ветки после выполнения rebase, меняющего историю коммитов:

Git осуществляет rebase путем создания новых коммитов и применения их к указанной основе (base). Очень важно понимать, что хотя ветка выглядит так же, как выглядела, она составлена из совершенно новых коммитов.

rebase создает совершенно новые коммиты.

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

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

Примечание: вместо —force можно использовать короткую форму -f .

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

Принудительный push с оговоркой

Может случиться такое, что вы хотите выполнить принудительный push, но только если никто другой не менял ничего в ветке.

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

Чтобы предотвратить такой ход событий, можно использовать опцию —force-with-lease (документация).

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

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

Как запушить изменения в ветку с другими именем

Обычно вы отправляете вашу локальную ветку в удаленную ветку с тем же именем (т. е. локальную my-feature — в удаленную my-feature ), но так бывает не всегда.

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

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

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

Вам не так уж часто понадобится пушить сразу все ветки из локального репозитория, но в принципе это возможно. Для этого нужно воспользоваться флагом —all :

Заключение

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

How to Push to GitLab

To get started with GitLab, you’ll need to create a repository and push code to it. Here’s how to push to GitLab.

How to Create a Project (Repository) in GitLab

Because of their larger potential in GitLab, repositories are called projects. But you can use the words interchangeably because a project behaves the same way as a repository you might find on GitHub.

After creating your account in GitLab, go to your Projects page and click New project.

From the Blank project tab, give the project a name and add a description. If you want it to be a public repository, click the Public option. Make sure the Initialize repository with README option is left unchecked. Then click the Create project button.

How to Push to GitLab

Once a new project is created, it will be blank by default. There are a couple of ways to populate it. You can directly add files online using the Add Files button.

But if you’re going to be using GitLab as an online versioning tool, it’s best to upload your local project files using the command line. To get started, first install and set up Git on your Linux, Mac, or Windows PC.

Then, open the Terminal (Git Bash on Windows) and navigate to the local folder that you want to sync with your GitLab project. Use the cd command to switch to the folder in question.

Now you can start the Git process with this command:

Now you’ll connect the remote GitLab project with your local directory. Use the following command, pasting in your GitLab project URL at the end (make sure it ends in .git ).

git remote add origin <project link>

After you press Enter or Return , you won’t see any confirmation. That’s because you haven’t added or transferred the files to the Git process yet. To add all the files from the current directory to the Git process, use the following command.

Then you can check if all files were added correctly using the following command.

Now you’ll make a commit, so you know which files were included when the local directory was first uploaded to the GitLab project. You can add your comment between the quotes at the end of the next command. It can include what changes you made recently to the code and if you added any new files.

git commit -m «first commit»

Now you’re ready to actually push the files and code to GitLab. Enter the following command.

git push -u origin master

After you press Enter or Return , you’ll be asked to enter your GitLab username and password. Since you’ve created a private repository, this step makes sure that only the project owner can make changes to the repository.

Once the authentication is done, the upload process will begin. And shortly, you’ll see a message saying that the upload is finished.

To check whether all the data was uploaded properly, you can open the project in your browser. Instead of the blank page, you’ll now see a list of all the files and folders in the project.

Automate GitLab with Zapier

Zapier lets you connect GitLab to thousands of apps, so you can automate more of your Git processes.

For example, you could automatically get a notification or create a task in your project management tool whenever there’s a new merge request in your repo.