github открытый исходный код
Исходные коды GitHub.com и GitHub Enterprise утекли
Противостояние разработчиков на GitHub по поводу блокировок на GitHub репозиториев проектов за нарушение действующего в США Закона об авторском праве в цифровую эпоху (DMCA) продолжается.
4 ноября 2020 года пользователь под ником nat (якобы под учетной записью Нэта Фридмэна — руководителя GitHub) прикрепил исходные коды GitHub.com и GitHub Enterprise прямо к репозиторию, где сервис хранит уведомления от правообладетелей.
Вдобавок там было оставлено сообщение: «felt cute, might put gh source code on dmca repo now idk». Это отсылка к мему «Feeling Cute, Might Delete Later» — когда выложенные в сети по настроению фотографии позднее удалялись пользователями по определенным соображениям.
В оперативном порядке специалисты GitHub удалили эти изменения в репозитории github/dmca. Однако, они остались в архиве Интернета.
На портале Hacker News сегодня появилось сообщение по этому поводу от имени Нэта Фридмэна. Опубликовавший это сообщение написал, что все в порядке, GitHub не был взломан. Оказалось, что два месяца назад специалисты сервиса случайно отправили некоторым клиентам тарбол (tarball) с исходным кодом GitHub Enterprise Server и с кодом github.com. Вероятно, что выложенные на некоторое время данные были частью этого архива с исходным кодом GitHub Enterprise (для предприятий). Он позволяет поднять свой GitHub сервер и развернуть окружение для совместной разработки проектов внутри корпоративной сети.
Также Фридмэн пояснил, что коммит от его имени не был подписан меткой «verified» и был поддельным. Неизвестный пользователь смог через неподписанный коммит выдать себя за него в своей локальной копии Git и затем загрузить новый репозиторий на GitHub.
Ранее 23 октября 2020 года по запросу американской ассоциации звукозаписывающих компаний (RIAA) основной репозиторий программы youtube-dl и его популярные форки были удалены с GitHub.
В конце октября исходный код youtube-dl был прикреплен к репозиторию github/dmca. Один из разработчиков сделал форк репозитория DMCA, затем создал коммит для слияния репозитория DMCA и youtubedl, чтобы код youtubedl стал включен во все дерево истории. Затем пользователь создал PR для основного репозитория DMCA. Создание PR привело к добавлению новой истории в исходный репозиторий DMCA. Так работает бэкэнд GitHub. В итоге разработчик получил доступ к истории в репозитории DMCA и смог добавить туда youtubedl.
В начале ноября GitHub внес изменения в правила обработки запросов о нарушении Закона об авторском праве в цифровую эпоху (DMCA). В документе появилось предупреждение о недопустимости повторной публикации заблокированного контента другими пользователями. Это будет рассматриваться как нарушение условий использования GitHub и может привести приостановке или блокировке учетных записей пользователей сервиса.
Помимо форков youtubedl пользователи GitHub начали создавать репозитории с mp3 песнями, треки которых были упомянуты в исходном запросе RIAA на удаление youtube-dl. Например, пользователь GitHub под ником ‘FuckTheRIAA‘ опубликовал в открытом доступе на сервисе сразу три трека — Icona Pop — I Love It, Justin Timberlake — Tunnel Vision и Taylor Swift — Shake It Off. Сейчас этот репозиторий удален, как и аккаунт пользователя. В архиве Интернета это все осталось.
Открыть исходники (почти) всего
На этот раз я бы хотел предложить к прочтению [вольный] перевод статьи Тома Престон-Вернера, одного из сооснователей GitHub, в которой он рассуждает о том, какие выгоды компания может извлечь из открытия своих проектов, какие проекты открывать не стоит и какова Единственно Правильная Лицензия. Хочу также отметить, что мнение переводчика не всегда совпадает с мнением автора оригинала. Ссылка на оригинал, как всегда, под текстом перевода.
Когда Крис и я начинали работу над GitHub в конце 2007, мы разделили работу на две части. Крис работал над Rail-приложением, а я работал над Grit, первым в истории адаптером Git для Ruby. После шести месяцев разработки, Grit стал достаточно законченным, чтобы обслуживать GitHub во время нашего публичного запуска сайта и мы встали перед интересным вопросом:
Стоит ли нам открыть исходники Grit или оставить его проприетарным?
Если оставить проприетарным, то это создало бы препятствие для конкурирующих Git-хостингов, давая нам преимущество. Открыть исходники означало, что тысячи людей по всему миру смогут использовать его чтобы разработать интересные инструменты, создавая ещё более яркую экосистему Git.
После небольшого спора мы решили открыть исходники Grit. Я не помню всех подробностей обсуждения, но это решение, сделанное почти четыре года назад, привело к тому, что я считаю одной из наших главных ценностей: открыть исходники (почти) всего.
Почему открыть исходники (почти) всего круто?
Если вы все делаете правильно, то открытые исходники это отличная реклама для вас и вашей компании. В GitHub нам нравится публично обсуждать библиотеки и системы, которые мы разработали и которые ещё закрыты, но обречены стать открытыми. Этот подход имеет несколько преимуществ. Это позволяет определить, что именно открыть и как много внимания надо этому уделить. Недавно, к всеобщему восторгу, мы открыли исходники Hubot, нашего чат-бота. За пару дней он набрал 500 подписчиков на GitHub и 409 голосов на Hacker News. Это выражается в одобрении GitHub и ещё большем количестве фанатов, чем когда либо ранее.
Если ваш код популярен настолько, что привлекает сторонних контрибьюторов, то вы создадите усиливающий эффект, который помогает выполнять больше работы дешевле. Больше пользователей означает что исследуется больше сценариев использования, что означает более надёжный код. Наш проект resque был улучшен 115 разными разработчиками вне компании, и ещё сотнями, предлагающими сторонние плагины, расширяющие функциональность resque. Каждое исправление ошибки, которое вы принимаете в проект, это сэкономленное время и раздражение потребителя, которого удалось избежать.
Умные люди любят общаться с другими умными людьми. Умные разработчики любят работать с умным кодом. Когда вы публикуете полезный код, вы привлекаете таланты. Каждый раз, когда талантливый разработчик смотрит в открытый код вашего проекта, вы выигрываете. У меня было много отличных бесед на технических конференциях о моём открытом коде. Некоторые из этих встреч привели к идеям, которые вылились в лучшие решения проблем с моими проектами. В индустрии с настолько большим количеством креативных и продуктивных разработчиков, правильный взгляд на ваш код может сыграть важную роль.
Если вы нанимаете разработчиков, то лучшее техническое собеседование это то, которое вам не нужно проводить, потому что разработчик уже проявил себя в одном из ваших открытых проектов. Как только технические навыки было предъявлены таким способом, всё что остается это убедиться в соответствии корпоративной культуре и убедить этого человека работать на вас. Если они увлечены открытым кодом, который они писали, и вы относитесь к тем компаниям, которые заботятся о качестве кода (а вы, очевидно, заботитесь), это должно быть просто! Мы наняли Висента Марти (Vicent Martí), после того, как мы увидели его яркую работу над libgit2, проектом который мы инициировали для извлечения функциональности Git в отдельную библиотеку на C. Технического собеседования не требовалось, Висент уже продемонстрировал свои навыки с помощью открытого кода.
После того как вы наняли всех этих крутых людей с помощью их вклада, нацеливание на открытый код это поразительно эффективный способ сохранить эти таланты. Давайте посмотрим, крутые разработчики могут выбрать место работы прямо сейчас. Эти же разработчики знают ценность открытой разработки и захотят собрать портфолио проектов, которыми они могли бы похвастаться перед друзьями или потенциальными будущими работодателями. Парадокс! Чтобы сделать разработчиков счастливыми, вы должны помочь им стать более привлекательными для других работодателей. Но здесь нет ничего страшного, так как это как раз те разработчики, которые вы хотите чтобы работали на вас. Так что расслабьтесь и дайте им работать над открытыми проектами, или они уйдут куда-нибудь, где им позволят.
Когда я начинаю новый проект, я предполагаю что он, в конечном счёте, будет открыт (даже если это маловероятно). Такая установка без усилий приводит к модульности. Если вы думаете о том, как другие люди, вне вашей компании, могут использовать ваш код, меньше шансов, что вы станете использовать проприетарные компоненты или жёстко связанные интерфейсы. Это, в свою очередь, приводит к более чистому и более поддерживаемому коду. Даже внутренний код должен притворяться открытым.
Вы когда-нибудь разрабатывали замечательную библиотеку или инструмент на одном месте работы, а затем увольнялись, чтобы присоединиться к другой компании только для того, чтобы переписать этот код или стать несчастными из-за его отсутствия? Я да, и это отстой. Публикация кода позволяет резко сократить дублирование усилий. Меньше дублирования означает больше работы над более важными вещами.
Наконец, это правильно. Сейчас почти невозможно что-то делать без прямого выполнения большого количества открытого кода. Если вы пользуетесь интернетом, то вы пользуетесь открытым кодом. Этот код олицетворяет миллионы человеко-часов, которые были потрачены для всеобщего блага. Мы все получаемы удовольствие от этой выгоды, и я верю, что мы все морально обязаны отплатить этому сообществу. Если программное обеспечение это океан, то открытый код это прилив, снимающий с мели корабли.
Ладно, но что я не должен открывать?
Это просто. Не открывайте ничего, что является основой бизнеса.
Вот несколько примеров того, что мы не отрываем, и почему:
Какова Единственно Верная Лицензия?
Я предпочитаю MIT и почти всё, что мы в GitHub открываем, распространяется под этой лицензией.
Я люблю эту лицензию по нескольким причинам:
Как я могу начать?
Легко, просто сдвиньте этот переключатель на вашем репозитории на GitHub из «закрытый» в «публичный» и расскажите миру о вашем проекте с помощью вашего блога, твиттера или Hacker News и за кружкой пива в местном пабе. Затем откиньтесь на спинку стула, расслабьтесь и наслаждайтесь тем, что вы часть чего-то большего.
Как принять участие в работе Open Source проектов на GitHub. Краткое руководство для начинающих
На GitHub размещены миллионы Open Source проектов, но для начинающих разработчиков бывает достаточно сложно поначалу разобраться в принципах их работы, а также в интерфейсе сайта. Это краткое руководство поможет участвовать в проектах с открытым кодом, которые размещаются на GitHub.
Адаптированный перевод статьи The beginner’s guide to contributing to a GitHub project. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.
Шаг 0: Выберите проект
На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект Хекслет Sicp.
Шаг 1: Создайте рабочую копию на своем компьютере
Прежде всего, вам нужен локальный форк проекта, поэтому нажмите кнопку «Fork» в GitHub.
Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:
Теперь вам нужна локальная копия, найдите «SSH clone URL» — справа, вверху.
Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.
Результат будет выглядеть примерно так:
Перейдите в директорию нового проекта:
Теперь необходимо установить связь локальной копии с оригинальным проектом, чтобы вы могли получать изменения основного проекта и вносить их в свою локальную копию. Сначала перейдите по ссылке в оригинальный репозиторий — она помечена как «forked from» в верхней части страницы GitHub. Это вернет вас на главную страницу проекта на GitHub, где вы сможете найти «SSH clone URL» и использовать его для создания новой связи, которую мы назовем upstream.
Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:
Шаг 2: Заставьте его работать на вашей машине
Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.
Если у вас все работает, но документация неясна, то улучшение этого раздела должно стать вашим первым PR в проекте. Это одновременно и самый простой и полезный способ войти в проект!
Шаг 3: Сделайте что-нибудь полезное
Это самый приятный этап — внести свой вклад в проект. Начните лучше c исправления ошибки, которая вас раздражает. Либо найдите подходящую в трекере проблем проекта — «Issues». Если вы не уверенны, с чего начать, многие проекты используют ярлык «good first issue» (или его разновидность), чтобы указать, что эту проблему может решить даже новичок в проекте.
Теперь, когда вы выбрали проблему, воспроизведите ее на своей локальной версии проекта. Как только вы воспроизвели проблему, изучите код, чтобы понять, где она возникла. Как только вы нашли проблему в коде, можно переходить к ее устранению.
Ветвление
Важное правило — размещать каждую часть разработки в отдельной ветке. Изучите, какая модель ветвления используется в проекте. Если в документации бранч-стратегия не описана, посмотрите, как называются уже существующие ветки. Вы можете назвать свою ветку как угодно, но важно, чтобы она была осмысленной. Названия веток типа «feature», «bugfix», «hotfix», «update» с указанием на то, что меняется — это лучший вариант.
В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:
В первую очередь мы убеждаемся, что находимся на master-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.
Теперь вы можете заняться устранением проблемы.
Если в проекте есть тесты, запустите их, чтобы убедиться, что вы ничего не сломали. Вы также можете добавить новый тест, чтобы показать, что ваше изменение устраняет первоначальную проблему.
Убедитесь, что вы исправляете только то, над чем работаете. Не поддавайтесь искушению исправить другие вещи, которые вы видите по пути, включая проблемы форматирования, так как ваш PR, скорее всего, будет отклонен.
Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью Как правильно составлять описания коммитов и почему это важно.
Шаг 4: Создайте Pull Request
Чтобы создать PR, вам нужно отправить ветку в ваш форк на GitHub, а затем нажать несколько кнопок на GitHub.
Чтобы отправить новую ветку:
Вернитесь в браузер и перейдите к вашему форку проекта (в нашем примере это будет выглядеть вот так, и вы увидите, что ваша новая ветка появилась в верхней части с удобной кнопкой «Compare & pull request»:
Нажмите эту кнопку!
Если вы видите выделенную надпись, как показано ниже:
Нажмите на ссылку, которая приведет вас к файлу CONTRIBUTING проекта, и прочитайте его! Он содержит ценную информацию, как работать с кодовой базой проекта, и поможет вам добиться одобрения вашего вклада.
На этой странице убедитесь, что «base repository» и «base» указывает на правильный репозиторий и ветку. Затем дайте хорошее, краткое название вашему запросу и объясните, почему вы его создали в поле описания. Добавьте соответствующие номера проблем, если они у вас есть.
Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.
Как только вы будете уверены, нажмите кнопку «Create pull request» и все — готово.
Шаг 5: Проверка разработчиками проекта
Чтобы ваши изменения были приняты в проект, разработчики должны проанализировать вашу работу. После этого они либо запросят изменения, либо объединят ее с основной веткой (либо отклонят их).
Как участвовать в Open Source проектах Хекслета:
Итоги
Главные этапы работы в Open Source:
Дополнение от переводчика
Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Git и Github. Простые рецепты
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Самую первую версию отменить нельзя. Ее можно только исправить. Если вы хотите добавить изменения в последнюю версию, то после выполнения команды commit, добавляете необходимые изменения и вызываете:
Ключ —no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ —oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
До текущего момента мы работали с локальным репозиторием, который сохранялся в папке на компьютере. Если мы хотим иметь возможность сохранения проекта в интернете, создадим репозиторий на Github. Для начала нужно зарегистрироваться на сайте github.com под именем myuser (в вашем случае это может быть любое другое имя).
После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой: