Как обновить файлы в репозитории github
Обновлено: 24.11.2024
Вы когда-нибудь сталкивались с ситуацией, когда вы редактируете код, удаляете, добавляете и изменяете что-то и вдруг понимаете: Черт, я удалил этот кусок, и мне нужно переписать или использовать его повторно сейчас. Черт!
Вы когда-нибудь мечтали о более простом способе переноса кода на хостинг, вместо того, чтобы подключаться к FTP или архивировать файл, загружать его на хост и распаковывать? ты знаешь дрель, верно? Уф!
Вы когда-нибудь хотели, чтобы вы могли легко поделиться своим кодом и попросить других людей помочь вам в некоторых битах, чтобы сделать вашего бота лучше?
Если вы ответили утвердительно на любой из этих вопросов, у меня есть продукт для вас! Это называется git, и это довольно волшебный инструмент.
Чтобы воспользоваться всеми преимуществами git, вам необходимо сначала как минимум выполнить пошаговое руководство Добавление файла config.json. Это означает, что как минимум ваш токен находится в отдельном файле, а не в ваших файлах javascript. Наличие префикса и идентификатора владельца в этом отдельном файле конфигурации означает, что вы получаете преимущество простого тестирования: измените префикс и токен, и у вас есть дополнительный бот, с которым вы можете протестировать свой код, wooh!
Что еще вам нужно? git, конечно! Для Windows получите Git SCM , в Linux запустите sudo apt-get install git-all или sudo yum install git-all в зависимости от метода установки вашего дистрибутива. У пользователей Mac также есть установщик Git SCM.
Что-нибудь еще? Ээээ, нет! Вот и все. Приступим к использованию!
Итак, первый шаг в мир git — это инициализация папки вашего проекта в качестве репозитория git. Для этого вам нужно перейти к этой папке в командной строке. Или используйте ярлык ОС:
Открыв приглашение в этой папке, запустите git init . У него нет никаких опций или вопросов — он просто открывает папку.
В git одним из самых важных файлов является .gitignore, который, как следует из названия, игнорирует определенные файлы. Это очень важно для приложений node.js и нашего бота: вы определенно хотите и должны игнорировать как папку node_modules, так и файл config.json. Первое, потому что вы не хотите, чтобы загружались тысячи файлов (и они все равно не работают в других системах), второе, потому что вы не хотите, чтобы ваш токен попал в общедоступный репозиторий git!
Существуют готовые файлы .gitignore, которые вы можете загрузить из Интернета, но для целей этого упражнения вам понадобятся только две строки в этом файле:
Но как его создать? Пользователи Linux и Mac, вы, вероятно, можете легко создать файл напрямую. Пользователям Windows, вам придется пойти на небольшой крюк — Windows не любит файлы только с расширением и без имени. Не волнуйтесь, это просто. Начните с создания нового файла с именем, например, gitignore.txt и вставьте две строки выше. Затем в консоли запустите rename gitignore.txt .gitignore, и это переименует его, как ожидалось.
А теперь мы готовы начать git gud (нет-нет, не пишите, что это мем!)
Первая команда, которую вы можете попробовать, это git status . Это покажет вам список всех ваших файлов и во всех подпапках и укажет их как неотслеживаемые файлы, что означает, что они не отслеживаются (сохраняются) git.
Давайте решим эту проблему с помощью нашей второй команды, которая, по сути, говорит git отслеживать все эти файлы и начинать с ними творить чудеса: git add . куда . — это просто ярлык для «всех файлов, включая подпапки».
А теперь пришло время зафиксировать задачу. Коммит в основном означает, что вы создаете снимок своего проекта, который навсегда сохраняется в вашей истории. Коммит может быть небольшим, например, небольшое исправление ошибки в одной строке или переписывание полной функции или модуля. Коммит всегда будет сопровождаться сообщением, описывающим изменение, поэтому небольшими коммитами будет легче управлять и отслеживать их в будущем. Итак, вот:
git commit -m 'Начальная фиксация проекта'
Это выведет новую фиксацию с некоторой статистикой, включая количество измененных строк и список измененных файлов. Здорово! Теперь у нас есть коммит. Забавная история: вы можете продолжать фиксировать изменения локально и делать все те замечательные вещи, которые делает git, не отправляя их в удаленный репозиторий. Но это то, для чего мы здесь, верно? Итак, вперед!
Благодаря Git у вас есть множество вариантов размещения проектов в Интернете. Отправка в онлайн-репозиторий обеспечивает безопасность резервных копий — вся история коммитов доступна, и ничего не потеряется, что бы ни случилось. Также дает вам возможность делиться своими проектами публично или в частном порядке с другими людьми и привлекать их к участию в вашем проекте, если вы хотите.
Три основных бесплатных сервиса хостинга Git: GitHub, GitLab и BitBucket. В этом случае я буду использовать GitHub, но большинство шагов, которые я предприму здесь, одинаковы для всех трех сервисов. Вам просто нужна учетная запись, и все готово!
На странице, которая отображается после создания репозитория, вы фактически получаете инструкции, которые вам нужно сделать, при отправке существующего репозитория из командной строки:
Очевидно, измените ваше имя пользователя и ваше имя репозитория на соответствующие строки. Первая строка связывает ваш локальный репозиторий с веб-сайтом GitHub. Вторая строка фактически берет всю вашу локальную историю коммитов и отправляет ее прямо на github. Обратите внимание, что это действие попросит вас ввести имя пользователя и пароль github.
'Погоди, правда? Вот и все?' ты спрашиваешь. Да, ваш код теперь на github. Обновите страницу github, и вы увидите там весь свой код — без node_modules и config.json, если вы все сделали правильно!
Связывание вашей учетной записи не избавит вас от будущих команд. На самом деле, каждый раз, когда вы вносите изменения и хотите отправить их в репозиторий, вам нужно снова использовать эту команду push. Обратите внимание, что вам не нужно отправлять каждую фиксацию по отдельности — вы можете работать целый день и делать несколько коммитов, а в конце дня отправлять их все сразу.
Небольшой способ, который вы можете использовать, — добавить и зафиксировать одновременно. Это работает только в том случае, если вы изменили файлы, но не создали новые (для этого просто выполните git add . отдельно). Итак, если вы внесли небольшие изменения, вы можете использовать это:
И не забудьте снова выполнить git push origin master!
Итак, допустим, у вас где-то есть VPS-хостинг. Или малиновый пи. Или какая другая машина. Вы хотите получить этот ваш код на нем. Сначала вам нужно выполнить описанные выше шаги по установке, чтобы установить git на машину, а затем вам нужно клонировать репозиторий с удаленного git:
Вот и все! Что ж, вам нужно снова ввести имя пользователя и пароль, но как только это будет сделано, этот код будет доступен!
Не забывайте, что любой файл, который был добавлен в ваш файл .gitignore, здесь отсутствует, поэтому вам нужно сделать 2 вещи:
- Снова создайте файл config.json с тем же токеном и префиксом или с другими.
- Повторно установите модули узла. Если вы правильно запустили npm init и установили все свои модули с аргументом -S или --save, вам нужно будет выполнить только npm install . В противном случае вам нужно установить их все заново, например, с помощью npm install discord.js
Теперь помните, что эти файлы не синхронизируются, поэтому они не будут перезаписаны или изменены всякий раз, когда вы загружаете или извлекаете данные из репозитория.
Кстати, каждый раз, когда вы загружаете GitHub, вы можете получить обновленную копию кода, просто запустив git pull origin master .
Конечно, вам придется перезагрузить бота, чтобы изменения вступили в силу.
Этот процесс не является односторонним. Если вы изменяете файлы на любом компьютере, вы можете использовать git push origin master и git pull origin master на другом. Однако будьте осторожны при редактировании в обоих местах, так как это может вызвать конфликты, которые раздражают при разрешении (и выходят за рамки этого руководства)
ЕСЛИ у вас есть «временные» изменения и вы хотите перезаписать их (например, быстрый путь на вашем VPS, который вы также исправили локально), вы можете избежать всего процесса «конфликта», сбросив репозиторий до вашего последнего рывка. Просто запустите git reset --hard HEAD, чтобы стереть все локальные изменения, затем запустите git pull origin master, чтобы получить последние изменения.
Вы можете подключиться к нескольким удаленным репозиториям, выполнив указанную выше команду удаленного добавления. Вам понадобится другое имя, например, вместо источника вы можете вызвать удаленную gitlab, и тогда любая команда должна отразить это, например git pull gitlab master .
Гитировать нужно намного больше, чем то, что показано здесь (и я знаю, что даже это уже куча информации). Вы можете создавать и объединять ветки, возвращаться к предыдущим коммитам, создавать и принимать PR. Вы можете узнать гораздо больше!
В этом руководстве рассказывается, как настроить центральное репо в качестве удаленного по отношению к вашему локальному репозиторию, чтобы обновлять локальную вилку обновлениями. Вы хотите делать это каждый раз, прежде чем начинать новые изменения в локальном репозитории.
Цели обучения
По окончании этого задания вы сможете:
- Объясните, почему важно обновить локальное хранилище перед началом редактирования.
- Обновите локальный репозиторий из удаленного центрального репозитория.
Дополнительные ресурсы
- Диаграмма команд Git: эта диаграмма включает в себя больше команд, чем мы узнаем в этой серии.
- Справка GitHub Изучение ресурсов Git
Теперь мы сделали следующее:
После того, как вы все настроите для работы над своим проектом, вам не нужно будет повторять этапы разветвления и клонирования. Но вы хотите обновить свой локальный репозиторий любыми изменениями, которые другие могли добавить в центральный репозиторий. Как мы это делаем?
Мы сделаем это, напрямую перетащив обновления из центрального репо в наше локальное репо, настроив локальное репо как «удаленное».«Удаленное» репо — это любое репо, отличное от репозитория, в котором вы сейчас работаете.
СЛЕВА: вы создадите ветвь и клонируете репозиторий только один раз. ПРАВИЛЬНО: После этого вы обновите свой форк из центрального репозитория, настроив его как удаленный и вытягивая из него с помощью git pull . Источник: Национальная сеть экологических обсерваторий (NEON)
Обновить, затем работать
После того, как вы наладили работу в своем репозитории, вы должны выполнять следующие шаги при каждом запуске работы в репозитории:
Обратите внимание, что мы уже научились выполнять шаги 2–4, теперь мы завершаем круг, учась обновлять наше локальное репо напрямую любыми изменениями из центрального репо.
Приведенный выше порядок шагов важен, поскольку он гарантирует, что вы включите любые изменения, внесенные в центральный репозиторий NEON, в разветвленные и локальные репозитории, прежде чем добавлять изменения в центральный репозиторий. Если вы не синхронизируете в этом порядке, вы подвергаетесь большему риску возникновения конфликта слияния.
Что такое конфликт слияния?
Конфликт слияния возникает, когда два пользователя одновременно редактируют одну и ту же часть файла. Git не может решить, какое редактирование было первым, а какое последним, и, следовательно, какое редактирование должно быть в самой последней копии. Отсюда конфликт.
Конфликты слияния возникают, когда одна и та же часть скрипта или документа изменяется одновременно, и Git не может определить, какое изменение следует применить. Источник: Atlassian
Настройка вышестоящего удаленного
Мы хотим напрямую обновлять локальное репозиторий любыми изменениями, внесенными в центральное репо, прежде чем приступать к следующим изменениям или дополнениям. Для этого нам нужно настроить центральный репозиторий как вышестоящий удаленный для нашего репозитория.
Шаг 1. Получите URL-адрес центрального репозитория
Во-первых, нам нужен URL-адрес центрального репозитория. Перейдите к центральному репозиторию в GitHub NEONScience/DI-NEON-участники. Нажмите зеленую кнопку «Клонировать» или «Загрузить» (так же, как мы делали это при клонировании репозитория), чтобы скопировать URL-адрес репозитория.
Шаг 2. Добавьте пульт
Во-вторых, нам нужно подключить вышестоящий удаленный центральный репозиторий к нашему локальному репозиторию.
Убедитесь, что вы все еще находитесь в локальном репозитории в bash
Сначала перейдите в нужный каталог.
Здесь вы указываете, что это команда git с помощью git, а затем добавляете вышестоящий удаленный сервер с заданным URL-адресом.
Шаг 3. Обновите локальное репозиторий
Во-вторых, обновите локальный репозиторий с помощью git pull с добавленными направлениями восходящего потока, указывающими центральный репозиторий, и мастером, указывающим, какую ветку вы извлекаете (помните, ветки — отличный инструмент для изучения, когда вы освоитесь с Git и GitHub). , но мы не будем на них заострять внимание. Просто используйте master ).
Понимание вывода: вывод будет меняться с каждым обновлением, несколько вещей, которые следует искать в выводе:
Теперь, когда вы синхронизировали локальный репозиторий, давайте проверим его статус.
Шаг 4. Завершите цикл
Сводка рабочего процесса
Синхронизация центрального репозитория с локальным репозиторием
Настройка (сделайте это только в первый раз)
После первоначальной настройки
Обновите свой локальный репозиторий и отправьте изменения
- git pull upstream master – вытащите все изменения и синхронизируйте локальное репозиторий с центральным репозиторием.
- внести изменения, git add и git commit
- git push origin master — отправляйте изменения в свою вилку
- Повторить
Есть вопросы? Без проблем. Оставьте свой вопрос в поле для комментариев ниже. Вероятно, у некоторых из ваших коллег тоже есть такой же вопрос! А также, вероятно, кто-то еще знает ответ.
Мне очень жаль, но я должен спросить. Как обновить файлы на github, не копируя их, не удаляя и не публикуя повторно?
Спасибо, ребята, будьте со мной помягче.
Это основной вопрос. Я не знаю, почему вы получаете столько дерьма.
Ответ заключается в том, что вам нужно научиться использовать git. Это технология, на которой работает GitHub. Сначала это немного сложно понять, но, к счастью, если вы работаете в Windows, вы можете просто использовать приложение:
GitHub Desktop клонирует ваш репозиторий в локальную папку, после чего вы можете просто перезаписать файлы в локальной папке и использовать приложение, чтобы зафиксировать и «отправить» эти файлы в сеть.
Чтобы это заработало, потребуется некоторая работа, но поверьте мне, оно того стоит.
Второй комментарий — мы все с чего-то начинаем.
Я очень рекомендую этот курс по codecademy, который поможет с основами.
Спасибо. Я знал, что это вещь, но не знал, для чего она на самом деле. Я сразу начну смотреть! :)
Вам нужно использовать git, чтобы отправить изменения на github.
Для изучения git и github я использовал это руководство, оно довольно пошаговое и простое в использовании. Обычно курсы Udemy стоят около 12 долларов США.
Другие комментарии говорят о том, что следующим шагом будет использование git, но не стыдитесь этого рабочего процесса. Я до сих пор копирую и вставляю, когда это удобнее.
Вы можете зафиксировать их
Да, я сейчас. Я имею в виду, что я нажимаю «Редактировать файл», а не копирую в новую версию. Есть ли способ лучше? Я не хочу писать это в своей IDE, чем снова в github
Ответ:
Используйте GitHub Desktop.
Это упрощает вашу жизнь без необходимости изучать git.
Комментарий к другим комментариям.
Но что это за гребаные ответы?
Разве вы не знаете Github Desktop?
По моему мнению, программирование должно упростить задачу, избавляя от необходимости изучать git, что должно быть необязательным.
Как программист, я считаю абсурдным, что все присоединяются к движению "Вам нужно изучить git". Ложь!
Только по долгу учебы мне пришлось использовать git.
"Возможно" мощнее, но на мой взгляд неправильно, что все функции не в программе например GitHub Desktop
Примечание 1. Извините, мне пришлось ответить на такой простой вопрос.
Примечание 2. Если я допустил опечатку, извините, это переводчик с испанского на английский.
Во второй статье из серии "Начало работы с Git" вы узнаете, как выполнять основные операции с Git.
В первой статье этой серии о начале работы с Git мы создали простой репозиторий Git и добавили в него файл, подключив его к нашему компьютеру. В этой статье мы узнаем еще несколько вещей о Git, а именно, как клонировать (загружать), изменять, добавлять и удалять файлы в репозитории Git.
Давайте сделаем несколько клонов
Программирование и разработка
Скажем, у вас уже есть репозиторий Git на GitHub, и вы хотите получить из него свои файлы. Возможно, вы потеряли локальную копию на своем компьютере или работаете на другом компьютере и хотите получить доступ к файлам в своем репозитории. Что вы должны сделать? Скачать файлы с GitHub? Точно! Мы называем это «клонированием» в терминологии Git. (Вы также можете загрузить репозиторий в виде ZIP-файла, но в этой статье мы рассмотрим метод клонирования.)
Давайте клонируем репозиторий под названием Demo, который мы создали в предыдущей статье. (Если вы еще не создали репозиторий Demo, вернитесь к этой статье и выполните эти шаги, прежде чем продолжить.) Чтобы клонировать файл, просто откройте браузер и перейдите на https://github. .com//Demo (где имя вашего репозитория. Например, мой репозиторий — https://github.com/kedark3/Demo). Перейдя по этому URL-адресу, нажмите кнопку «Клонировать или загрузить», и ваш браузер должен выглядеть примерно так:
Затем, чтобы просмотреть список файлов в каталоге Demo, введите команду:
Ваш терминал должен выглядеть так:
Изменить файлы
Теперь, когда мы клонировали репозиторий, давайте изменим файлы и обновим их на GitHub. Для начала введите приведенные ниже команды одну за другой, чтобы изменить каталог на Demo/ , проверить содержимое README.md , добавить новый (дополнительный) контент в README.md и проверить статус с помощью git status :
Вот как это будет выглядеть в терминале, если вы будете запускать эти команды одну за другой:
Давайте посмотрим на вывод git status и разберемся, что это значит. Не беспокойтесь о части, которая говорит:
потому что мы еще не научились этому. Следующая строка говорит: Изменения не подготовлены для фиксации; это говорит вам о том, что файлы, перечисленные ниже, не помечены как готовые («постановочные») для фиксации. Если вы запустите git add, Git возьмет эти файлы и пометит их как готовые к фиксации; другими словами (Git), изменения подготовлены для фиксации. Прежде чем мы это сделаем, давайте проверим, что мы добавляем в Git, с помощью команды git diff, а затем запустим git add .
Вот ваш вывод терминала:
Давайте разберем это:
- diff --git a/README.md b/README.md — это то, что сравнивает Git (т. е. README.md в этом примере).
- --- a/README.md покажет все, что было удалено из файла.
- +++ b/README.md покажет все, что добавлено в ваш файл.
- Все, что добавляется в файл, печатается зеленым текстом со знаком + в начале строки.
- Если бы мы что-то удалили, это было бы напечатано красным текстом со знаком - в начале.
- Состояние Git теперь говорит, что изменения должны быть зафиксированы: и перечисляет имя файла (т. е. README.md ) и то, что произошло с этим файлом (т. е. он был изменен и готов к фиксации).
Совет: если вы уже запускали git add и теперь хотите посмотреть, что отличается, обычный git diff ничего не даст, потому что вы уже добавили файл. Вместо этого вы должны использовать git diff --cached . Он покажет вам разницу между текущей версией и предыдущей версией файлов, которые Git было сказано добавить. Вывод вашего терминала будет выглядеть так:
Загрузить файл в репозиторий
Мы изменили файл README.md, добавив новый контент, и пришло время загрузить его на GitHub.
Давайте зафиксируем изменения и отправим их на GitHub. Выполнить:
Это сообщает Git, что вы "фиксируете" изменения, которые вы "добавили" к нему. Вы можете вспомнить из первой части этой серии, что важно добавить сообщение, объясняющее, что вы сделали в своем коммите, чтобы вы знали его цель, когда позже будете просматривать свой журнал Git. (Мы подробнее рассмотрим эту тему в следующей статье.) Обновленный файл Readme — это сообщение для этого коммита. Если вы считаете, что это не самый логичный способ объяснить, что вы сделали, не стесняйтесь писать сообщение коммита по-другому. .
Запустите git push -u origin master . Вам будет предложено ввести имя пользователя и пароль, а затем загрузить файл в репозиторий GitHub. Обновите страницу GitHub, и вы должны увидеть изменения, которые вы только что внесли в README.md.
В правом нижнем углу терминала показано, что я зафиксировал изменения, проверил статус Git и отправил изменения на GitHub. Статус Git говорит:
Первая строка указывает, что в локальном репозитории есть одна фиксация, но ее нет в источнике/мастере (т. е. на GitHub). Следующая строка предписывает нам отправить эти изменения в origin/master, что мы и сделали. (Чтобы освежить вашу память о том, что означает «источник» в этом случае, обратитесь к первой статье этой серии. Я объясню, что означает «мастер» в следующей статье, когда мы будем обсуждать ветвление.)
Добавить новый файл в Git
Теперь, когда мы изменили файл и обновили его на GitHub, давайте создадим новый файл, добавим его в Git и загрузим на GitHub. Выполнить:
Это создаст новый файл с именем file.txt .
Если вы это проигнорируете:
Вы должны увидеть содержимое файла. Теперь запустите:
Git сообщает, что в вашем репозитории есть неотслеживаемый файл (с именем file.txt ). Это способ Git сообщить вам, что в каталоге репозитория на вашем компьютере есть новый файл, о котором вы не сообщили Git, и Git не отслеживает этот файл на предмет внесенных вами изменений.
Нам нужно сообщить Git, чтобы он отследил этот файл, чтобы мы могли зафиксировать его и загрузить в наш репозиторий. Вот команда для этого:
Ваш терминал выводит:
Состояние Git сообщает вам, что в файле file.txt есть изменения, которые нужно зафиксировать, и что это новый файл для Git, о котором он не знал до этого. Теперь, когда мы добавили файл file.txt в Git, мы можем зафиксировать изменения и отправить их в origin/master.
Git загрузил этот новый файл на GitHub; если вы обновите страницу GitHub, вы увидите новый файл file.txt в репозитории Git на GitHub.
С помощью этих шагов вы можете создать любое количество файлов, добавить их в Git, зафиксировать и отправить на GitHub.
Удалить файл из Git
Что, если мы обнаружим, что допустили ошибку и нам нужно удалить файл .txt из нашего репозитория. Один из способов — удалить файл из нашей локальной копии репозитория с помощью этой команды:
Если вы сделаете git status сейчас, Git скажет, что есть файл, который не подготовлен для фиксации, и он был удален из локальной копии репозитория. Если мы сейчас запустим:
Я знаю, что мы удаляем файл, но мы все еще запускаем git add, потому что нам нужно сообщить Git о вносимом нами изменении. git add можно использовать, когда мы добавляем новый файл в Git, изменяем содержимое существующего файла и добавляем его в Git или удаляем файл из репозитория Git. По сути, git add учитывает все изменения и размещает эти изменения для фиксации. Если вы сомневаетесь, внимательно посмотрите на вывод каждой команды на снимке экрана терминала ниже.
Git сообщит нам, что удаленный файл подготовлен для фиксации. Как только вы зафиксируете это изменение и отправите его на GitHub, файл также будет удален из репозитория на GitHub. Сделайте это, запустив:
Теперь ваш терминал выглядит так:
И ваш GitHub выглядит так:
Теперь вы знаете, как клонировать, добавлять, изменять и удалять файлы Git из репозитория. В следующей статье этой серии будет рассмотрено ветвление Git.
Читайте также: