Как скопировать файлы в git

Обновлено: 04.07.2024

Git - система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?

Представьте, что вы с коллегами вместе пишете ~~ядро Linux~~научную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста - последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:

Чем-то похоже на Dropbox, Google Drive и прочие облачные хранилища, правда? Только в данном случае ваши файлы синхронизируются не автоматически, а по команде, и возможностей управления ими гораздо больше.

Понятно, что для совместной работы над текстом научной статьи вполне хватит и Google Docs, но вот если, например, вы хотите опубликовать результаты исследования в интернете и сделать для этого собственный сайт, то без VCS обойтись сложно. И ещё раз, системы контроля версий хороши тем, что:

они позволяют работать над проектом в команде;
вы видите, кем и когда были внесены те или иные изменения;
их всегда можно откатить назад;
вы не потеряете проделанную работу, даже если что-то удалите на своем компьютере;
ваши наработки могут быть полностью открыты для других (а это доступность знаний и ускорение развития технологий, ура!);
GitHub и GitLab позволяют не только хранить и просматривать файлы проекта, но и публиковать веб-сайты, документацию и т.п.

Существует много систем управления версиями, но мы будем пользоваться самой распространенной - git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы - это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:

Мы будем пользоваться программой GitHub Desktop, которую можно скачать отсюда. Если вы уже знакомы с Git, то вы можете выбрать любую программу или пользоваться командной строкой - это не принципиально. Стоит отметить, что пользоваться командной строкой гораздо сложнее чем графическим интерфейсом, поэтому она больше подходит продвинутым пользователям.

Git - разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
Репозиторий - это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

GitHub

GitHub - крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang компанией GitHub, Inc. Так как мы будем хранить на нём наши репозитории, поэтому мы и выбрали GitHub Desktop, т.к. он разрабатывался специально для максимальной интеграции и упрощения работы с GitHub.

После регистрации вы попадете на приветственную страницу, где сначала нужно, ничего не меняя, нажать зеленую кнопку Continue, а потом Skip this step (но если не лень, можно заполнить опросник и нажать Submit).

Далее подтвердите свой аккаунт на указанной ранее почте и все, вы готовы к работе.

Создание репозитория

Создать репозиторий можно двумя способами:

Сначала создадим через сайт. Чтобы создать репозиторий, нажимаем кнопку Start a project и выбираем название. Оно может быть любым, но должно отражать суть того, что лежит внутри, например, “homeworks”. Впрочем, GitHub предлагает более креативные варианты. Также в специальном поле можно добавить описание. Для публичных репозиториев хорошей практикой является заполнение всех полей, чтобы другие пользователи (или люди, проходящие по ссылке из резюме) могли сразу понять, о чём конкретно данный репозиторий.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

Далее у нас есть возможность инициализировать репозиторий с файлом README. В нем может быть отображена информация о репозитории, о его использовании, установке файлов и т.д. Описание происходит в формате Markdown. Также за этой галочкой скрывается команда init, которая превращает пустую папку в Git-проект.

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

GNU GPL;
MIT;
Unlicense;
WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Клонируем репозиторий

Для дальнеших шагов нам потребуется скачать и установить GitHub Desktop. После установки и первого запуска, возможно, потребуется войти в ваш аккаунт GitHub. Далее выбираем Clone repository или через File, а затем уже Clone repository.

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

Тут мы выбираем из списка репозиторий:

Тут мы вставляем ссылку на репозиторий:

Вне зависимости от выбора, все файлы с удаленного репозитория перейдут в указанную папку.

Добавляем и изменяем файлы

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов - это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Верните всё назад!

Любой коммит можно отменить, щёлкнув по нему правой кнопкой мыши и выбрав Revert this commit. Так, если мы проведём эту процедуру с последним коммитом и запушим изменения на GitHub, то файл goose там исчезнет. В истории изменений данное действие будет видно, как ещё коммит, отменяющий изменения выбранного (анти-коммит). Чтобы посмотреть историю коммитов, нужно нажать на History.

Откатывать коммиты можно также через веб-интерфейс (на сайте GitHub).

Клонирование чужих репозиториев

Клонировать можно не только свои репозитории, но и чужие. Для этого найдите нужный репозиторий в поиске на github. И выбираем Clone or Download.

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

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

Fork репозитория

Fork (форк) репозитория это возможность скопировать чужой репозитория на свой аккаунт и вносить любые изменения в него, без изменения оригинального репозитория. Можно сделать форк любого доступного репозитория. При создании форка нас спросят в какой аккаунт мы хотим его добавить.

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Ветки

В git есть понятие branch (ветка). Ветка - это покоммитный “путь” до некоторого коммита, называемого “концом” (tip) ветки. Мы можем иметь несколько независимых веток при работе. Коммит делается в конкретную ветку, по умолчанию это ветка master. Создать новую ветку можно как на сайте, так и в приложении GitHub Desktop. Для этого нужно выбрать вкладку Current branch и нажать на New branch:

Выбираем имя и в эту ветку пойдет вся информация с ветки master (точнее, новая ветка будет “смотреть” на тот же коммит, что и master), в том числе и все файлы:

И теперь мы можем переключать ветки и вносить изменения в конкретную ветку, не затрагивая основную, в данном случае master. Например, мы удалим один файл, и изменим другой. Удалённый файл будет отмечен красным минусом, а изменённый - желтой точкой. При этом справа видно, что мы работаем в ветке Features.

Делаем коммит в новую ветку и смотрим, что произошло. Как мы видим, в ветке master всё осталось, как прежде. Она по прежнему указывает на тот же коммит, что и раньше.

А вот в ветке Features удалённого файла уже нет. Переключить ветку можно, нажав на кнопку Branch с названием ветки:

Ветки удобно использовать для добавления новых функция, что они не ломали рабочий код до новой функции. После разработки ветку можно объединить с master (merge, смёржить, слить) сделав так называемый Pull request.

Создание репозитория из GitHub Desktop

Как говорилось ранее, новый репозиторий можно создать и из самого приложения. Для этого идем в File/New repository:

Указываем все данные аналогично тому как создавали на сайте и нажимаем Create repository:

Не забудьте нажать на Publish repository, чтобы он ушёл на сайт.

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

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

Установите программу просмотра кода

Загрузить и установить Код Visual Studio следуя указаниям мастера установки. После этого вы будете готовы просматривать файлы и код, которые можно загрузить с GitHub.

Есть много разных редакторов кода. Если проект был создан в другой IDE (интегрированной среде разработки), Visual Studio может не подойти для редактирования этого кода. При этом Visual Studio Code позволит вам редактировать код большинства проектов на GitHub, и он всегда будет работать, если все, что вы хотите сделать, это Посмотреть код.

Загрузка последней версии проекта на GitHub

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

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

Найдите раздел «Релизы» и выберите последнюю версию. На сайте GitHub для настольных ПК версии находятся на боковой панели справа. В качестве альтернативы вы можете добавить / релизы в URL-адрес репозитория. Релиз вверху будет самым последним.

Поскольку вы хотите просмотреть код, загрузите файл .zip с исходным кодом. Пользователи Linux должны загрузить файл tar.gz с исходным кодом.

Извлеките архив исходного кода, который вы загрузили на шаге 6.
Переключитесь в редактор визуального кода и выберите «Файл»> «Открыть папку». Перейдите и выберите папку, которую вы извлекли на шаге 7.

Выберите файл проекта на панели слева, и код появится в рабочей области справа.

Приведенные выше шаги помогут вам просмотреть файлы из последней версии проекта на GitHub. Но что, если вы хотите просмотреть файлы из определенной ветви проекта?

Скачивание из определенной ветки

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

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

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

Теперь, когда вы выбрали нужную ветку, найдите и нажмите зеленую кнопку «Код», выбрав либо Загрузить Zip, либо, если вы видите вариант, Открыть с помощью Visual Studio. (Вы также можете увидеть опцию «Открыть с помощью GitHub Desktop».)

Извлеките zip-файл и откройте извлеченную папку из Visual Studio Code, выполнив шаги 7–11 в разделе выше.

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

Загрузка из определенного коммита

Каждый раз, когда изменение кода применяется к репозиторию, оно добавляется посредством фиксации. Фиксация содержит все изменения с момента последнего обновления кода. Вы можете выполнить загрузку из определенного коммита, если пытаетесь отладить проблемы, вызванные недавним изменением кода.

Выберите фиксацию, которую вы хотите загрузить, выбрав заголовок фиксации.

Теперь вы находитесь на странице выбранного вами коммита. Затем нажмите кнопку «Обзор файлов».

Найдите и нажмите зеленую кнопку «Код» и выберите «Загрузить ZIP-архив» или, если он доступен, «Открыть с помощью Visual Studio».
Наконец, извлеките zip-файл и откройте извлеченную папку в Visual Studio Code.

Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу. Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.

Система контроля версий Git

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

Git — важный навык веб-разработчика

А лучший способ научиться программировать — профессия «React-разработчик». В программе три интенсива, прокачка навыков и оплачиваемая стажировка.

Устанавливаем Git

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

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Установка на macOS

Установка в Linux

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

Если у вас 21 или более ранняя версия Fedora, используйте yum install git .
Для 22 и последующих версий Fedora вводите dnf install git .
Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git .

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

Проверим, что Git установлен

После того, как все действия по установке завершены, убедимся, что Git появился в системе компьютера. Откройте терминал и введите git --version , должна появиться текущая версия программы на вашей машине. Эта проверка подходит для всех операционных систем.

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя: git config --global user.name "ваше имя"

Для добавления почтового адреса вводите: git config --global user.email адрес

Обратите внимание, что в командах, указанных выше, есть опция --global . Это значит, что такие данные будут сохранены для всех ваших действий в Git и вводить их больше не надо. Если вы хотите менять эту информацию для разных проектов, то в директории проекта вводите эти же команды, только без опции --global .

Что такое GitHub?

GitHub — веб-сервис, который основан на системе Git. Это такая социальная сеть для разработчиков, которая помогает удобно вести коллективную разработку IT-проектов. Здесь можно публиковать и редактировать свой код, комментировать чужие наработки, следить за новостями других пользователей. Именно в GitHub работаем мы, команда Академии, и студенты интенсивов.

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

Переходим на сайт GitHub. Cтартовая страница GitHub.
Для начала регистрации:
- Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей проходим верификацию. Первый шаг регистрации профиля на стартовой странице GitHub.
- После заполнения данных и успешного прохождения верификации нажимаем на кнопку Select a plan. Второй шаг регистрации профиля на стартовой странице GitHub.
Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Подтверждение электронного адреса.
После верификации GitHub предложит создать новый репозиторий, организацию или узнать больше о GitHub. Этот пункт пока можно пропустить и перейти в профиль. Переход в ваш профиль. Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге

/.ssh , поэтому нужно проверить содержимое этого каталога.

Открываем консоль.
Вводим cd

Открываем консоль и вводим команду: Указываем тот адрес электронной почты, который вводили при регистрации на GitHub. Генерируем ключ.
Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите. Указываем расположение ключа и вводим пароль.

В Сmder для запуска ssh-agent можно использовать команду start-ssh-agent .

Если проблема осталась, рекомендуем работать в Git Bash.

/.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K

/.ssh/id_rsa . Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

/.ssh права доступа командой chmod 700

Можно пойти другим путём, открыть файл id_rsa.pub прямо в папке и просто скопировать содержимое оттуда.

Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

Добавляем в свой профиль SSH-ключ.

Если всё сделано верно, в списке появится новый ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Работа с репозиториями

Для начала определим, что такое репозиторий

Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.

Если над проектом трудится команда разработчиков, как правило, создаётся общий репозиторий, в котором находится рабочая версия проекта (назовём его мастер-репозиторий). При этом каждый пользователь клонирует себе в профиль оригинальный репозиторий и работает именно с копией. Такая копия называется форком. Так как форк — ваша персональная версия мастер-репозитория, в нём вы можете пробовать разные решения, менять код и не бояться что-то сломать в основной версии проекта.

Как сделать форк мастер-репозитория?

Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.

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

Открываем консоль, переходим в директорию, где хотим сохранить папку с проектом, и вводим команду:

Если вы правильно настроили SSH-ключи, Git начнёт процесс копирования репозитория на ваш компьютер. Если вы видите ошибку, в которой написано Error: Permission denied (publickey) , скорее всего, вы ошиблись где-то при выполнении инструкции по настройке SSH-ключа. Вернитесь на несколько абзацев ранее и попробуйте повторить процесс настройки.

Если вы не хотите вручную вводить адрес репозитория, вы можете зайти на страницу проекта, нажать зелёную кнопку Clone or download (клонировать или скачать), выбрать Clone with SSH (клонировать по SSH) и скопировать адрес, который находится в текстовом поле. Этот адрес вы можете вставить в команду git clone .

Кстати, если вы хотите, чтобы название папки с проектом у вас на компьютере отличалось от имени репозитория, можете дополнить команду клонирования, добавив в конце другое название:

Теперь, на вашем компьютере, в папке your_project или в той, название которой вы указали самостоятельно, находится полная копия репозитория c GitHub.

Чтобы начать работу с проектом, надо оказаться в его директории. Для этого используем команду cd , после которой указываем название проекта на вашем компьютере: cd your-project

Сделали копию репозитория.

Создадим новую ветку. Открываем терминал, вводим команду git branch . Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master создаём новую ветку: git checkout -b имя-новой-ветки .

Новая ветка.

Если текущая ветка не master , сначала переключимся в основную ветку: git checkout master . Мы делаем это, чтобы новая ветка содержала свежую, на момент создания, рабочую версию проекта.

Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.

Переключаемся между ветками.

Если вы ошиблись в названии, например, допустили опечатку, вы можете изменить название ветки с помощью команды: git branch -m старое-имя-ветки новое-имя-ветки .

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

Если вы хотите сохранить изменения не во всех файлах, для начала можно ввести команду git status . Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

Состояние ветки.

Перед тем, как зафиксировать изменения отдельных файлов, нужно добавить файлы в набор этих изменений. Воспользуйтесь командой git add имя-файла . Если название очень длинное, вы можете начать его писать, затем нажать Tab и консоль сама предложит вам продолжение пути к файлу.

Если вы хотите сохранить все изменения разом, вводите git add -A .

Делаем коммит.

Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внесли и сохранили, пока локальны. Их нужно послать на GitHub.

Отправляем изменения.

Теперь заходим на страницу нашего форка и создаём пулреквест, чтобы слить свой код с данными в мастер-репозитории. Что такое пулреквест? Это предложение изменить код в репозитории.

Любое предложение можно принять или отвергнуть. Так же и с пулреквестом. После его создания, он должен получить ревью и одобрение так называемого коллаборатора — пользователя GitHub, который имеет права администратора в мастер-репозитории. Им может быть ваш коллега-разработчик, техлид, наставник. Если к вашему коду нет вопросов, пулреквест принимается и изменения из вашей ветки попадают в master главного репозитория. Если в код нужно внести изменения, пулреквест отклоняется, и вам нужно снова пройти по цепочке локальные изменения — сохранение — коммит — пуш, только пулреквест заново делать не нужно. Если вы продолжаете вести работу в той же ветке и пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .

Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

В локальном репозитории вводим команду git checkout master , переходим в master .
Теперь забираем (подтягиваем) изменения из ветки master мастер-репозитория git pull academy master . Academy здесь — сокращённое название мастер-репозитория, такое имя используется в проектах студентов Академии, вы можете выбрать любое другое название. Забираем изменения из мастер-репозитория. Если консоль выдаёт ошибку и говорит, что не знает директории с таким именем, нужно добавить ссылку на этот репозиторий: Вместо academy указывайте своё название и оно закрепится за этим репозиторием.
Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master . Отправляем изменения в форк.

Готово, теперь форк и оригинальный репозиторий находятся в актуальном состоянии.

наши репозитории Git начинались как части одного репозитория Monster SVN, где у каждого отдельного проекта было свое собственное дерево:

очевидно, было довольно легко перемещать файлы с одного на другой с помощью svn mv . Но в Git каждый проект находится в своем репозитории, и сегодня меня попросили переместить подкаталог из project2 to project1 . Я сделал что-то вроде этого:--6-->

но это кажется довольно запутанным. Есть ли лучший способ сделать что-то в этом роде? Или я выбрал правильный подход?

обратите внимание, что это включает в себя объединение истории в существующий репозиторий, а не просто создание нового автономного репозитория из части другого (как и в предыдущем вопросе).

Да, нажимая на --subdirectory-filter of filter-branch был ключ. Тот факт, что вы использовали его, по сути, доказывает, что нет более простого способа - у вас не было выбора, кроме как переписать историю, так как вы хотели получить только (переименованное) подмножество файлов, и это по определению изменяет хэши. Поскольку ни одна из стандартных команд (например, pull ) перепишите историю, вы не можете использовать их для этого.

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

Если ваша история вменяема, вы можете взять коммиты как патч и применить их в новом репозитории:

или в одной строке

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

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

этап Один

сделайте копию репозитория A, так как следующие шаги делают major изменения в этой копии, которые вы не должны нажимать!

(предполагая, что myprojects-это репозиторий, из которого вы хотите скопировать)

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

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

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

например. FILE_TO_KEEP = ПФЛ.xml, чтобы сохранить только pom.xml-файл из FOLDER_TO_KEEP

Второй Этап

вы можете импортировать эти файлы в репозиторий B в каталоге, не являющемся корневым:

сделать это каталог

переместить файлы в этот каталог

добавить файлы в этот каталог

сохранить изменения и мы готовы объединить эти файлы в новый репозиторий

Третий Этап

сделайте копию репозитория B, если у вас его еще нет

(предполагая, что FOLDER_TO_KEEP-это имя нового репозитория, в который вы копируете)

создайте удаленное соединение с репозиторием A как ветвь в репозитории Б

(repo-a-branch может быть чем угодно - это просто произвольное имя)

Pull из этой ветви (содержащей только каталог, который вы хотите переместить) в репозиторий Б.

The pull копирует как файлы, так и историю. Примечание: Вы можете использовать слияние вместо вытягивания, но вытягивание работает лучше.

наконец, вы, вероятно, хотите немного очистить, удалив пульт подключение к хранилищу

нажимаем и все готово.

нашел этой очень полезно. Это очень простой подход, когда вы создаете патчи, которые применяются к новому РЕПО. См. связанную страницу для получения дополнительной информации.

Он содержит только три шага (скопировано из блога):

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

под Windows я получил ошибку InvalidArgument. Поэтому мне пришлось накладывать все пластыри один за другим.

СОХРАНЕНИЕ ИМЕНИ КАТАЛОГА

подкаталог-фильтр (или более короткая команда git subtree) работает хорошо, но не работает для меня, так как они удаляют имя каталога из информации фиксации. В моем сценарии я просто хочу объединить части одного репозитория в другой и сохранить историю с полным именем пути.

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

этот ответ предоставляет интересные команды, основанные на git am и представлены с использованием примеров, шаг за шагом.

вы хотите переместить некоторые или все файлы из одного хранилища в другое.
вы хотите сохранить свою историю.
но вы не заботитесь о сохранении бирки и филиалов.
вы принимаете ограниченную историю для переименованных файлов (и файлов в переименованных справочники.)

процедура

извлечение истории в формате электронной почты с помощью
git log --pretty=email -p --reverse --full-index --binary
реорганизовать дерево файлов и обновить изменение имени файла в истории [необязательно]
применить новую историю с помощью git am

1. Извлечение истории в формате электронной почты

пример: извлечь историю file3 , file4 и file5

очистить временный каталог назначения

очистите ваше РЕПО источник

извлечь историю каждого файла в формате электронной почты

к сожалению, вариант --follow или --find-copies-harder нельзя комбинировать с --reverse . Вот почему история вырезается при переименовании файла (или при переименовании родительского каталога).

после: временная история в формате электронной почты

2. Реорганизовать дерево файлов и обновить изменение имени файла в истории [необязательно]

Предположим, вы хотите переместить эти три файла в другое РЕПО (может быть то же самое РЕПО).

поэтому реорганизуйте свои файлы:

ваша временная история теперь:

изменить также имена в истории:

Примечание: эта переписывает историю, чтобы отразить изменение пути и имени файла.
(т. е. изменение нового местоположения / имени в новом РЕПО)

3. Применить новую историю

применить фиксации из временных файлов истории:

ваш другой РЕПО теперь:

использовать git status чтобы увидеть количество коммитов, готовых к нажатию : -)

Примечание: как история была переписана, чтобы отразить путь и имя файла изменить:
(т. е. по сравнению с местоположением / именем в предыдущем РЕПО)

не нужно git mv чтобы изменить местоположение / имя файла.
не нужно git log --follow для доступа к полной истории.

дополнительный трюк: обнаружение переименованных / перемещенных файлов в вашем РЕПО

чтобы перечислить переименованные файлы:

дополнительные настройки: вы можете выполнить команду git log используя опции --find-copies-harder или --reverse . Вы также можете удалить первые два столбца, используя cut -f3- и grepping полный шаблон' <.* => .*>'.

имея подобный зуд, чтобы поцарапать (altough только для некоторых файлов данного репозитория), этот скрипт оказался действительно полезным:git-import

короткая версия заключается в том, что он создает файлы исправлений данного файла или каталога ( $object ) из существующего репозитория:

которые затем применяются к новому репозиторию:

для подробной информации, пожалуйста, посмотрите:

для соответствия стандартам stackoverflow, вот процедура:

использование для этого примера:

после того как вы сделали это, вы можете повторно организовать файлы migrate-from-project2 ветвь перед слиянием.

Я хотел что-то надежное и многоразовое (функция one-command-and-go + undo), поэтому я написал следующий сценарий bash. Работал на меня несколько раз, поэтому я решил поделиться им здесь.

он может перемещать произвольную папку /path/to/foo С repo1 на /some/other/folder/bar to repo2 (пути к папкам могут быть одинаковыми или различными, расстояние от корневой папки может отличаться).

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

поскольку это создает осиротевшую ветвь со всей историей старого РЕПО, а затем объединяет ее с главой, она даже будет работать в случае столкновения имен файлов (тогда вам придется разрешить слияние в конце, конечно).

если нет конфликтов имен файлов, вам просто нужно git commit в конце, чтобы завершить объединить.

недостатком является то, что он, скорее всего, не будет следовать переименованиям файлов (за пределами REWRITE_FROM папка) в исходном repo-pull запросы приветствуются на GitHub для размещения для этого.

в моем случае мне не нужно было сохранять РЕПО, из которого я мигрировал, или сохранять любую предыдущую историю. У меня был клочок той же самой ветки, из другого удаленного

на этих двух шагах я смог заставить ветку другого РЕПО появиться в том же РЕПО.

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

теперь он вел себя так, как-если бы это было просто еще одна ветка, которую я толкнул против того же РЕПО.

если пути для файлов, о которых идет речь, одинаковы в двух репозиториях, и вы хотите принести только один файл или небольшой набор связанных файлов, один простой способ сделать это-использовать git cherry-pick .

первым шагом является приведение коммитов из другого РЕПО в ваше собственное локальное РЕПО с помощью git fetch <remote-url> . Это уйдет FETCH_HEAD указывая на фиксацию head из другого РЕПО; если вы хотите сохранить ссылку на эту фиксацию после того, как вы сделали другие выборки, вы можете захотеть пометьте его git tag other-head FETCH_HEAD .

затем вам нужно будет создать начальную фиксацию для этого файла (если он не существует) или фиксацию, чтобы привести файл в состояние, которое может быть исправлено с первой фиксацией из другого РЕПО, которое вы хотите ввести. Вы сможете сделать это с помощью git cherry-pick <commit-0> если commit-0 представил файлы, которые вы хотите, или вам может потребоваться создать фиксацию "вручную". Добавить -n к параметрам cherry-pick, если вам нужно изменить начальную фиксацию, например, удалить файлы из этого обещай, что не захочешь вмешиваться.

после этого вы можете продолжать git cherry-pick последующие коммиты, снова используя -n где это необходимо. В простейшем случае (все коммиты-это именно то, что вы хотите и применяете чисто) вы можете дать полный список коммитов в командной строке cherry-pick: git cherry-pick <commit-1> <commit-2> <commit-3> . .

Читайте также: