Яго Родригес

Вы когда-нибудь меняли что-либо непосредственно в репозитории вашего проекта? Вы когда-нибудь объединяли филиал в master? Потом захотели вытянуть изменения в свое локальное хранилище и возникли проблемы с этим?

Если вы не знаете, что означает «вытащить хранилище», вы в правильном месте. Хочешь чашку кофе?

Краткое вступление

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

Под «впереди ваших» я подразумеваю комиты, существующие в вашем удаленном репозитории (на серверах GitHub). Эти комиты не существуют в вашем локальном хранилище (на вашей машине).

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

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

Теперь мы можем перейти в каталог на нашей машине, чтобы клонировать наш проект. Если мы еще не создали каталог, который служит нашим центром, мы можем создать его для сохранения наших проектов с GitHub. Выберите четные или коэффициенты, чтобы принять решение.

Если вы не знаете, о чем я говорю, посмотрите статью.

Теперь давайте проверим события, которые могут произойти, когда нам нужно git pull.

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

Это самая простая ситуация. Это происходит когда мы создали удаленное репо и добавили некоторые файлы, которых у нас еще нет локально. У нас также нет изменений в нашем локальном репо.

В порядке. Сначала перейдем в папку, созданную во время клонирования проекта. У него такое же название.

Пора создать некоторые файлы на GitHub. На странице проекта создайте файл README. Простенькая!

На нашем компьютере откройте CMD или любое терминальное приложение (например, cmder) и введите git pull origin master. Вы увидите, как произойдет магия.

Теперь мы также имеем эти изменения локально. Достаточно круто, правда?

Извлечение, когда у нас есть локальные изменения, которые еще не были зафиксированы

Прекрасно. Давайте создадим несколько файлов. В своем любимом редакторе кода можно открыть папку локального проекта. Но я рекомендую использовать VSCode.

С помощью этого создайте файл.gitignore файл и добавьте туда что-нибудь.

Теперь у нас есть локальные изменения, но мы не фиксировали эти изменения. Мы пока не собираемся этого делать.

Давайте перейдем в наше удаленное хранилище. Создайте другой файл. Это может быть LICENSE.md. Выполните следующим образом:

1. Введите лицензию на входе.
2. Нажмите на выбрать шаблон лицензии.

На следующей странице выберите Лицензия MIT и нажмите на Посмотрите и подайте. Не стесняйтесь прочесть лицензию, если хотите.

Ваш файл должен выглядеть так, как на картинке сейчас, с вашим именем GitHub, конечно.

Теперь мы можем это сделать. Перейдите на страницу вниз и нажмите Зафиксируйте новый файл. Убедитесь, что выбран первый вариант.

Вы можете оставить поля пустыми (в нем используется тот же текст заполнителя) или ввести что-нибудь другое, если хотите.

Пока мы изменились как дистанционно, так и локально. Однако мы не внесли своих местных изменений. Оставьте так.

Давайте внесем изменения и посмотрим, что произойдет?

Круто! Мы могли тянуть без проблем. Это происходит потому, что мы изменили разные файлы. Далее мы увидим, что произойдет, когда мы изменим тот же файл. Держись там!

Вытягивание, когда у нас есть локальные комиты, которые еще не были нажаты

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

Итак, давайте добавим и зафиксируем файл. Не надо git push еще!

Давайте добавим еще одну смену к удаленному репо и зафиксируем ее. Это может быть index.html файл.

Если вы вводите git status вы увидите, что наше локальное и удаленное РЕПО разошлось. Они оба имеют 1 (один) разный комит.

Давайте попробуем извлечь эти изменения сейчас и посмотрим статус.

Посмотрите на это! Git рекурсивно вытащил изменения в отдаленный репозиторий и автоматически объединил их в наш локальный стек фиксации. Следовательно, мы можем также вносить изменения таким образом.

Что делать, если у нас есть изменения в одном файле?

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

Однако что произойдет, если мы изменим один и тот же файл в обоих хранилищах?

Прежде чем продолжить, мы должны сделать git push origin master относительно локальных изменений, которые мы произвели раньше. Таким образом, у нас нет никаких модификаций, и мы равны с удаленным.

Теперь мы можем что-нибудь изменить. Скажем, измените файл README локально и зафиксируйте изменения. Пока не жмите.

Выделите удаленный файл README и измените его. Сделайте это.

Мы находимся в «такой же» ситуации, что и раньше, с разными обязательствами с каждой стороны.

Если попробовать git pull удаленный, вот что мы видим:

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

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

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

Здесь все очень просто. Примите текущие изменения означает, что мы принимаем только отдаленные изменения. Примите входящие изменения означает, что мы принимаем только наши локальные изменения. Мы также можем принять оба изменения с принять оба изменения вариант.

Благодаря этому мы можем добавить и зафиксировать файл. Если мы проверим статус сейчас, мы увидим, что мы на 2 комита впереди удаленного хранилища. Это означает, что мы успешно объединено файл.

Теперь мы можем нажать его и проверить измененный файл GitHub.

Фу! Э?! Этот дал нам немного работы. Но ведь это не ракетостроение, не так ли?

Хвалите солнце ☀️друже. Сейчас мы идём работать.

Что делать, если у нас уже есть проект для отправки на GitHub и удаленная репозитория с материалами в нем?

В порядке! Это долгий вопрос. Но это немаловажный момент. Это еще одна ситуация, которую мы должны рассмотреть.

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

Итак, теперь у нас есть каталог с некоторым кодом, и мы собираемся git init этой папки, чтобы Git мог начать слушать наши изменения.

Круто. Теперь мы хотим отправить этот проект на GitHub. Достаточно просто, правда? Просто нужно создать удаленный репозиторий. Но, скажем, мы создали это репо и добавили файл readme, лицензию, index.html и .gitignore.

Хммм… мы не обратили внимание на то, что наш шаблон уже поместил те же файлы в наше локальное хранилище.

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

Ради статьи, скажем, мы все равно внесем эти изменения. Но прежде чем мы решим это, мы должны увязать наш локальный проект с проектом на GitHub.

Запустите следующий код: git remote add origin <github's project link>

The Ссылка на проект GitHub это тот самый, который мы используем для клонирования хранилища. Если вы не знаете, что это такое, прочтите эту статью.

В порядке. Теперь, когда мы это сделали, мы можем начать тащить и толкать некоторые вещи. Но если мы попытаемся внести изменения сейчас, вы знаете, что произойдет, не правда ли?

Это достаточно просто обойти. Просто добавьте и зафиксируйте наши локальные изменения. Поскольку это наш первый локальный коммит, мы можем сделать это:

git add --allgit commit -m "first commit"

Благодаря этому мы можем попытаться вытащить еще раз. Имейте в виду, что мы должны использовать git pull origin master потому что это первое, что мы делаем в этом хранилище.

Мы должны получить следующее сообщение:

Мы не можем извлечь изменения, потому что Git этого не хочет. ? ? Прекрасно! Спасибо, Гит!!! ?

Чтобы устранить эту проблему, нам нужно объединить файлы. Но у нас есть гораздо более эффективный способ. Запустите код git rebase origin/master .

Мы получаем следующее сообщение:

Перебазирование – это очень круто. Это лучшая альтернатива git merge . Он делает то же самое, но лучшим способом. Вы можете узнать больше об этом здесь, но не беспокойтесь. В следующих статьях я объясню это.

Мы должны разрешать конфликты сейчас. Для этого мы можем перейти к VSCode.

Обратите внимание на несколько вещей здесь.

Во-первых, файлы, имеющие конфликты, являются файлами под файлом объединить изменения табл.

Во-вторых, когда мы бегали git rebase он снова добавил все наши файлы в фазу промежуточной работы — той же стадии, на которой мы находимся после запуска git add — но имеющие конфликты.

В третьих, на нижней левой панели VSCode мы видим серию чисел. Ну, git rebase создал эту ветвь. Но не волнуйся. Мы вернемся к мастер в секунду.

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

Мы можем добавить более одного файла с помощью этой команды: git add .gitignore index.html README.md .

После этого мы собираемся перебазировать отдаленные комиты на наши локальные. Мы можем сделать это с помощью команды git rebase --continue.

Теперь все комиты в удаленном хранилище объединены или перебазированы с нашими локальными комитами. Мы также вернулись к ветке мастера.

Мы можем проверить комиты с помощью git log .

Достаточно круто, правда? Это события, с которыми мы можем столкнуться, когда вытаскиваем изменения из удаленных хранилищ на GitHub.

Ну, пока, ребята. Надеюсь, эта статья помогла вам как-то.

Я планирую сделать серию статей для начинающих по Git и GitHub. Следите за новостями.

Увидимся в следующий раз. Мир! ✌️ ✌️ ✌️

Я Яго Родригес, бразилец из Белема, Пара. Я студент информационных систем, стажер-разработчик программного обеспечения и фрилансер. Я нахожусь в начале своей карьеры и просто хочу поделиться с вами некоторыми знаниями, которые я получил.

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

Яго Родригес – аналитик программного обеспечения — W3 Automação e Systems | LinkedIn
Просмотрите профиль Яго Родригеса на LinkedIn, крупнейшем в мире профессиональном сообществе. У Яго есть 3 вакансии, указанные в…www.linkedin.comЯго Родригес (@iagokv) | Twitter
Последние твиты от Яго Родригеса (@iagokv). Front-End разработчик | Vue.js подаван | Нуб по жизни. Белен, Бразилияtwitter.com

Да! Я знаю. Мое фото в Твиттере – это нечто…