Как получить файлы из репозитория
git config --global user.name "[name]" — установить имя, которое будет прикрепляться к коммиту.
git config --global user.email "[email address]" — установить email, который будет прикрепляться к коммиту.
git config --global color.ui auto — включить полезную подсветку командной строки.
git config --global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).
git config --global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.
Создание репозиториев
git init [project-name] — создать новый локальный репозиторий с заданным именем.
git clone [url] — загрузить проект и его полную историю изменений.
Работа с изменениями
git status — полный список изменений файлов, ожидающих коммита.
git status -s — краткий вид изменений.
git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).
git add [file] — сделать указанный файл готовым для коммита.
git add . — сделать все измененные файлы готовыми для коммита.
git add '*.txt' — добавить только файлы, соответствующие указанному выражению.
git add --patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.
git diff --staged — показать что было добавленно в индекс с помощью git add , но еще не было закоммиченно.
git diff HEAD — показать что изменилось с последнего коммита.
git diff HEAD^ — показать что изменилось с предпоследнего коммита.
git diff [branch] — сравнить текущую ветку с заданной.
git difftool -d — то же самое, что и diff , но показывает изменения в заданной difftool.
git difftool -d master.. — показать изменения, сделанные в текущей ветке.
git diff --stat — показать статистику какие файлы были изменены и как.
git reset [file] — убрать файлы из индекса коммита (изменения не теряются).
git commit --amend — добавить изменения к последнему коммиту.
Работа с ветками
git branch — список всех локальных веток в текущей директории.
git branch [branch-name] — создать новую ветку.
git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.
git checkout -b <name> <remote>/<branch> — переключиться на удаленную ветку.
git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.
git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.
git merge --no-ff [branch] — соединить ветки без режима “fast forwarding”.
git branch -a — посмотреть полный список локальных и удаленных веток.
git branch -d [branch] — удалить заданную ветку.
git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.
git branch -m <oldname> <newname> — переименовать ветку.
Работа с файлами
git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.
git rm --cached [file] — удалить файл из репозитория, но сохранить его локально.
git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.
Отслеживание файлов
.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:
git ls-files --other --ignored --exclude-standard — список всех игнорируемых файлов.
Сохранение фрагментов
git stash — положить во временное хранилище все отслеживаемые файлы.
git stash pop — восстановить последние файлы, положенные во временное хранилище.
git stash list — список всех сохраненных изменений во временном хранилище.
git stash drop — удалить последние файлы, положенные во временное хранилище.
Просмотр истории
git log — список изменения текущей ветки.
git log --follow [file] — список изменения текущего файла, включая переименования.
git log --pretty=format:"%h %s" --graph — изменение вида отображения истории изменений.
git log --author='Name' --after= --pretty=oneline --abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.
git log --no-merges master.. — посмотреть историю изменений только для текущей ветки.
git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.
git show [commit] — показать метадату и изменения в заданном коммите.
git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.
Отмена коммитов
git reset — убрать изменения из индекса коммита, сами изменения останутся.
git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.
git reset --hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.
Синхронизация изменений
git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.
git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.
git push — запушить текущую ветку в удаленную ветку.
git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.
git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.
git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.
git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.
git pull [remote][branch] — указать конкретную удаленную ветку для слияния.
git remote — посмотреть список доступных удаленных репозиториев.
git remote -v — посмотреть детальный список доступных удаленных репозиториев.
Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.
В целом СКВ можно разделить таким образом:
- Локальные — все файлы хранятся только в вашей операционной системе, например, разложены по папкам с версиями.
- Централизованные — проект хранится на сервере, а ваша рабочая версия включает только текущий набор файлов.
- Распределенные — копии проекта (и вся информация о версиях) располагаются не только на сервере, но и на нескольких клиентских машинах, чтобы обеспечить устойчивость к отказу сервера.
Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.
Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.
Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).
Принципы работы с Git
У проектных файлов в Git есть 3 базовых состояния
- Измененные (modified) — файлы в процессе рабочего редактирования.
- Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
- Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.
У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.
Чаще всего работа с Git устроена примерно так:
- Вы вносите правки в файлы рабочей копии проекта.
- Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
- Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.
Установка Git
Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).
Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.
Сначала потребуется установить Git на свой компьютер.
Установка в Linux
Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:
На Ubuntu и других Debian-подобных систем введите apt:
Установка на Mac
Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:
И следовать дальнейшим инструкциям.
Если вы пользуетесь Homebrew, запустите команду:
Установка в Windows
Настройка Git
Настроить рабочую среду нужно только один раз — после обновлений параметры не сбросятся. Если понадобится, в любое время можно изменить ваши настройки.
Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:
Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.
Всю используемую конфигурацию можно просмотреть так:
Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:
В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:
Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.
Выбор ветки по умолчанию
Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:
Работа в репозитории
Как правило, есть два варианта начать работу с репозиторием Git:
- Можно выбрать локальный каталог и создать новый репозиторий в нем.
- Можно клонировать существующий репозиторий с локального компьютера или сервера. Обычно проекты клонируются именно с сервера.
Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.
Команда создаст каталог с именем .git, в котором будут храниться структурные файлы репозитория.
И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add <имя файла>.
Заодно создадим начальный коммит командой git commit:
В этом репозитории вы можете продолжать работать и дальше, со временем обновляя его и отправляя рабочие версии на сервер.
Клонирование существующего репозитория
Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.
Видно, что можно выбрать тип репозитория:
- публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;
- приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.
Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.
На вашем компьютере в каталоге, куда вы перешли в командной строке, должен появиться каталог SomeConsoleApp, внутри него — каталог .git и все скачанные файлы репозитория последней версии.
После получения проекта обычно начинается более рутинный рабочий процесс — правки, добавление функционала и т. д. Далее в какой-то момент вы захотите сохранить прогресс в новой версии проекта.
Правила и периодичность обновления могут быть почти любыми, но хорошим тоном обычно считается сохранять рабочую (или промежуточно завершенную) версию. Важное требование для команд разработчиков — возможность сборки проекта, иначе другие участники команды будут вынуждены тратить время на борьбу с ошибками компиляции.
Сохранение снимков и просмотр статуса проекта
Как упоминалось ранее, часть файлов в рабочем каталоге может и не находиться под контролем версий. За отслеживаемыми файлами «наблюдает» Git, они были как минимум в прошлом снимке состояния проекта. Неотслеживаемыми могут быть, например, вспомогательные файлы в рабочем проекте, если они не зафиксированы в прошлой версии проекта и не готовы к коммиту. Их можно выделить в отдельную категорию для Git, о чем будет рассказано далее.
Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.
Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:
Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:
Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.
Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:
Для удаления ненужных файлов из репозитория можно использовать команду git rm <file-name>. Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.
Файл .gitignore
Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.
Открывать файл можно в любом текстовом редакторе. Обычно удобнее не перечислять абсолютно все имена (которые к тому же всегда известны), а воспользоваться подобными инструкциями:
Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.
Рекомендуется создавать .gitignore до первой отправки вашего проекта в удаленный репозиторий, чтобы на сервер не попало никаких лишних файлов и каталогов. Разумеется, важно проверить, чтобы в .gitignore не были упомянуты критичные для проекта файлы, иначе у других участников команды возникнут проблемы после следующего обновления.
Управление удаленными репозиториями
Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add <shortname> <url>, например:
Отправка изменений в удаленный репозиторий (Push)
На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.
Команда для отправки изменений на сервер такова: git push <remote-name> <branch-name>. Если ваша ветка называется master, то команда для отправки коммитов станет такой:
Она сработает, если у вас есть права на запись на том сервере, откуда вы клонировали проект. Также предполагается, что другие участники команды за это время не обновляли репозиторий.
Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.
Получение изменений из репозитория (Pull)
Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.
На этом этапе могут возникать конфликты версий, когда несколько человек поработали над одними и теми же файлами в проекте и сохранили свои изменения. Избежать этого можно, если изолировать части проекта, поручив работу над одной частью только одному человеку. Разумеется, на практике это не всегда выполнимо, поэтому в Git есть инструменты для разрешения конфликтов версий. Они будут рассмотрены далее.
Создание веток и переключение между ними
Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch <branch-name> дважды с разными аргументами:
Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout <branch-name>:
Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:
Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.
Слияние веток (merge)
Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge <source-branch>:
Изменения успешно перенесены. В наших упрощенных условиях команда завершилась без ошибок, не найдя конфликтов в файлах. Если же над общими участками какого-либо файла успели поработать несколько человек, с этим нужно разбираться вручную. При возникновении ошибок Git помечает общие части файлов из разных веток и сообщает о конфликте.
Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.
Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:
Заключение
Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.
Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.
Обновите код в локальном репозитории с изменениями от других членов команды, используя следующие команды:
- fetch , который скачивает изменения из удаленного репозитория, но не применяет их к коду.
- merge , который применяет изменения, взятые из, в fetch ветвь в локальном репозитории.
- pull — Объединенная команда, которая выполняет, fetch а затем merge .
Из этого руководства вы узнаете, как выполнить следующие задачи:
Видеообзор
При наличии конфликта слияния между фиксацией, которую вы еще не отправили, и фиксацией, которую вы собираете или извлекать, устраните эти конфликты , прежде чем завершить обновление кода.
Вы скачиваете изменения в локальную ветвь с удаленного компьютера через fetch . Fetch запрашивает удаленный репозиторий о всех фиксациях и новых ветвях, которые были отправлены другими пользователями, но у вас нет и загружают их в репозиторий, создавая локальные ветви по мере необходимости.
Fetch не объединяет изменения в локальные ветви. Он скачивает только новые фиксации для проверки.
Чтобы обеспечить очистку списка ветвей и их обновление, настройте Git для очистки удаленных ветвей во время получения. Этот параметр можно настроить из командной строки или в Visual Studio.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
Visual Studio использует представление синхронизации в Team Explorer для изменения. Изменения, скачанные, fetch не применяются, пока вы не fetch или не синхронизируйте изменения.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В поле Синхронизациявыберите извлечь , чтобы обновить список входящих фиксаций.
Выполните git fetch команду из командной строки, чтобы загрузить изменения в локальную ветвь.
После запуска git fetch вы увидите результаты, аналогичные приведенным в следующем примере:
Обновление ветвей с помощью Merge
Примените изменения, загруженные fetch с помощью merge команды. Объединить принимает фиксации, полученные от fetch , и пытается добавить их в локальную ветвь. Слияние сохраняет историю фиксаций локальных изменений. Когда вы предоставляете общий доступ к ветви с помощью push-уведомлений, Git знает, как другие пользователи должны объединять ваши изменения.
Проблема заключается в том, что merge фиксация, полученная из, fetch вступает в конфликт с существующей неотправленной фиксацией в ветви. Git обычно очень разумен для разрешения конфликтов слияния автоматически, но иногда необходимо Разрешить конфликты слияния вручную и выполнить слияние с новой фиксацией.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
Team Explorer выполняет слияние при выполнении запроса или синхронизации из представления изменений .
Синхронизация — это Объединенная операция извлечения удаленных изменений и последующей передачи локальных. Эта операция синхронизирует фиксации в локальной и удаленной ветви.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В окне Синхронизациявыберите Синхронизация.
Выполнение merge без флагов или параметров добавляет фиксации, скачанные из fetch , в локальную ветвь. Git добавляет фиксацию слияния при наличии конфликтов. Эта фиксация слиянием имеет две родительские фиксации, по одному для каждой ветви, и содержит изменения, зафиксированные для разрешения конфликтов между ветвями.
Укажите --no-commit параметр для слияния без фиксации. Команда пытается выполнить слияние, но не фиксирует окончательные изменения. Этот параметр дает возможность проверить измененные файлы перед тем, как завершить слияние с фиксацией.
Выборка и слияние с помощью инструкции Pull
Pull выполняет, fetch а затем merge для загрузки фиксаций и обновления локальной ветви в одной команде, а не на двух. Используйте pull , чтобы сделать ветвь текущей с удаленной, если вы не беспокоитесь о просмотре изменений перед их слиянием в собственную ветвь.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В разделе Синхронизациявыберите извлечь , чтобы получить удаленные изменения и объединить их в локальную ветвь.
git pull без каких-либо параметров fetch изменения, которые у вас нет, origin будут изменены merge для текущей ветви.
Извлечение удаленной ветви в локальную ветвь путем передачи сведений об удаленной ветви в pull :
pull Команда — это удобный способ непосредственного слияния работы из удаленной ветви с локальной ветвью.
Обновление ветви с использованием последних изменений из Main
При работе в ветви может потребоваться внести последние изменения из основной ветви в ветвь. Существует два подхода, которые можно использовать: перебазовый или слияние.
- Перебазовая база данных принимает изменения, внесенные в фиксации в текущей ветви, и воспроизводит их в журнале другой ветви. Перезапись переписывает журнал фиксаций текущей ветви. Журнал начинается с последней фиксации в целевой ветви перебазы данных.
- Слияние объединяет изменения из исходной ветви в целевую, используя фиксацию слиянием, которая станет частью журнала фиксаций.
В этой статье демонстрируется этот merge подход. дополнительные сведения о rebase методах, которые подходят для вашего сценария, и рекомендации по их использованию см. в разделе rebase перебазовый Pro.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
git pull origin main Команда объединяет git fetch команды и git merge . чтобы это правильно сделать в Visual Studio интеграции, необходимо выполнить синхронизацию в Team Explorer , чтобы сделать часть. Это обеспечит актуальность локального репозитория Git с удаленным источником.
Чтобы объединить последние изменения из основной ветви в ветвь, выполните следующие действия.
На Team Explorer нажмите кнопку Главная и выберите пункт ветви.
Ознакомьтесь с целевой ветвью. Щелкните правой кнопкой мыши целевую ветвь и выберите команду объединить из.
Укажите слияние из ветви в этом примере, а затем выберите объединить.
При наличии конфликтов слияния Team Explorer сообщает о ней. Устраните фиксации слияния перед следующим шагом.
Чтобы объединить последние изменения из Main в ветвь, в этом примере с именем users/jamal/readme-fix можно использовать следующие команды:
Я думаю, большинство из вас, разработчики, используют любой VCS, и я надеюсь, что некоторые из вас используют Git. У вас есть какой-либо совет или трюк, как получить URL-адрес загрузки для одного файла в репозитории?
Я не хочу URL для отображения raw-файла; в случае двоичных файлов это ни для чего.
можно ли вообще использовать GitHub в качестве " скачать сервер"?
Если мы решим перейти на код Google, здесь представлена упомянутая функциональность?
или есть ли бесплатный хостинг и VCS для проектов с открытым кодом?
Git не поддерживает загрузку частей репозитория. Вы должны скачать все. Но вы должны быть в состоянии сделать это с GitHub.
при просмотре файла он имеет ссылку на" сырую " версию. Элемент URL построена так
заполнив пробелы в URL, вы можете использовать Wget или cURL (С -L опция, см. ниже) или что угодно, чтобы загрузить один файл. Опять же, вы не получите ни одного из приятные особенности контроля версий используется Git с этим.
обновление: я заметил, что вы упомянули, что это не работает для двоичных файлов. Вероятно, вы не должны использовать двоичные файлы в своем репозитории Git, но GitHub имеет раздел загрузки для каждого репозитория, который вы можете использовать для загрузки файлов. Если вам нужно более одного двоичного файла, вы можете использовать a .сжатый файл. URL-адрес для загрузки загружаемого файла составляет:
обратите внимание, что URL-адреса, приведенные выше, из ссылок на github.com , будет перенаправлять к raw.githubusercontent.com . Вы не должны напрямую использовать URL-адрес, указанный этим перенаправлением HTTP 302, потому что, per RFC 2616: "поскольку перенаправление может быть изменено время от времени, клиент должен продолжать использовать запрос-URI для будущих запросов."
- перейдите к файлу, который вы хотите скачать.
- щелкните его, чтобы просмотреть содержимое в пользовательском интерфейсе GitHub.
- в правом верхнем углу щелкните правой кнопкой мыши the .
- Сохранить как.
специально для БОЛЬШИЕ ФАЙЛЫ
вы можете скачать отдельные файлы и каталоги в формате zip. Вы также можете создать ссылку на скачивание, и даже дать имя zip-файла. Подробное использование -здесь.
GitHub Mate делает один файл скачать без усилий, просто нажмите на значок, чтобы загрузить, в настоящее время он работает только на Chrome.
В случае, если вы хотите скачать zip-файл с github С помощью wget
посмотреть этот сайт для более подробной информации
- перейти к конкретному набору данных, который вы хотите скачать и нажмите на него.
- вы увидите кнопку "Raw" в верхней правой части набора данных.
- нажмите "Alt", а затем щелкните левой кнопкой мыши " Raw" кнопка.
- весь CSV будет загружен в вашей системе.
страница, на которую вы ссылаетесь, отвечает на первый вопрос.
GitHub также имеет возможность загрузки для таких вещей, как релизы.
Код Google нет Git на всех.
GitHub, код Google и SourceForge, только для начала бесплатный хостинг. SourceForge все еще может сделать CVS.
Это определенно работает. По крайней мере в Chrome. Щелкните правой кнопкой мыши на значке "Raw" ->Сохранить Ссылку Как.
Я думаю, что новый url структура raw.giturl например:
git file
raw
чтобы загрузить файл из репозитория Github, используйте команду 'curl' со ссылкой на необработанный файл.
добавьте параметр --output, за которым следует новое имя файла, чтобы загрузить необработанный файл во вновь созданный файл.
Читайте также: