Работа с git через консоль

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

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

Откройте «Командную строку‎» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.

В Linux выполните команду: ‎

cd /home/user/directory

В macOS

cd /Users/user/directory

В Windows:

cd C:/Users/user/directory

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

git init

Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git. Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:

git add

git commit -m 'initial project version'

Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

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

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Клонирование существующего репозитория

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

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

Для клонирования существующего репозитория понадобится ввести git clone <url>. Пример такой команды вы видите ниже:

git clone https://github.com/rep/rep

Данная команда позволила вам получить клон всех версий указанного репозитория (в качестве примера было взято название rep). Теперь на вашем сервере создана директория с указанным названием. К ней подключена поддержка контроля версий, то есть появилась папка .git. 

При использовании вышеуказанной команды репозиторий клонируется с текущим названием. Если же оно должно отличаться, используйте следующую вариацию команды:

git clone https://github.com/rep/rep myrep

Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:

Cloning into 'Git'...

remote: Counting objects: 46, done.

remote: Compressing objects: 100% (25/25), done.

remote: Total 46 (delta 7), reused 43 (delta 4), pack-reused 0

Unpacking objects: 100% (46/46), done.

Checking connectivity... done.

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

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

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

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

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

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

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

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

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

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

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

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

  • на сайте;
  • через GitHub Desktop.

У нас есть выбор между 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.

Далее нажимаем на зеленую кнопку Create repository. Вы увидите список файлов в своем репозитории (пока это только автоматически сгенерированный файл README с описанием проекта) и содержание README, если он есть, а также файлы .gitignore и LICENSE, если они создавались. Ссылка на репозиторий будет выглядеть так: https://github.com/username/your_repo_name.git .

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

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

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

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

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

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

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

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

  1. Открываем консоль.
  2. Вводим , чтобы перейти в нужный каталог.

    Переходим в нужную директорию.

  3. Используем , чтобы увидеть список всех файлов в каталоге.

    Открываем список файлов в директории.

    Ищем пару файлов с названиями вида и . Обычно имя — , , или . Файл с расширением — ваш публичный ключ, а второй — ваш приватный, секретный ключ.
    Если таких файлов или даже каталога у вас нет, вы можете их сгенерировать. Для этого делаем следующее.

    • Открываем консоль и вводим команду:
      ssh-keygen -t rsa -b 4096 -C "your_mail@example.com"

      Указываем тот адрес электронной почты, который вводили при регистрации на GitHub.

      Генерируем ключ.

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

      Указываем расположение ключа и вводим пароль.

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

    Добавляем ключ в shh-agent. Несколько важных примечаний:

    • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в связь ключа с доменом.
    • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой . Может появиться такое сообщение об ошибке:
      «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

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

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

    • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш файл, чтобы автоматически загрузить ключи в и хранить пароли.
      Host *
       AddKeysToAgent yes
       UseKeychain yes
       IdentityFile ~/.ssh/id_rsa

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

    • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой
  5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
    • Если вы на Windows
    • Для пользователей macOS
    • На Linux используйте , чтобы установить необходимый для копирования пакет , а затем введите

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

  6. Переходим на страницу для работы с ключами в вашем профиле на GitHub.

    Страница с настройками ключей в вашем профиле.

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

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

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

    Успешно добавленный ключ.

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

Знакомьтесь, pass

Перевод

Я много лет искал подходящую мне хранилку паролей и недавно наткнулся на Pass на HackerNews. Идея хранить пароли в git-репозитории может выглядеть странно, но в целом это неплохая идея, потому что:

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

Я использую -c чтобы копировать/вставлять пароли. Есть расширение для браузера, но копипейст лично мне удобнее. Проблемы синхронизации с телефоном и всеми linux-дейвайсами тоже не стоит (потому что это всего лишь git).
Делюсь с вами переводом приветственной странички Pass.
Управление паролями должно быть простым и следовать философии Unix. Используя pass, каждый Ваш пароль находится внутри зашифрованного файла gpg, имя которого совпадает с именем ресурса или веб сайта к которому данный пароль привязан. Эти зашифрованные файлы могут быть организованы в удобные иерархии папок, скопированы с носителя на носитель и, в общем, обработаны с помощью любых утилит управления файлами командной строки.
С pass управлять отдельными файлами паролей становится крайне просто. Все пароли хранятся в ~ / .password-store, а pass предоставляет несколько удобных команд для добавления, редактирования, генерации и получения паролей. Это очень короткий и простой Shell скрипт. Он способен временно помещать пароли в буфер обмена и отслеживать изменения паролей с помощью git.

Установка Git

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

Примечание

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

Установка в Linux

Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива.
Если у вас Fedora (или другой похожий дистрибутив, такой как RHEL или CentOS), можно воспользоваться :

Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте :

Чтобы воспользоваться дополнительными возможностями, посмотрите инструкцию по установке для нескольких различных разновидностей Unix на сайте Git https://git-scm.com/download/linux.

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

Существует несколько способов установки Git на Mac.
Самый простой — установить Xcode Command Line Tools.
В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив ‘git’ в терминале.

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

Если Вы хотите получить более актуальную версию, то можете воспользоваться бинарным установщиком.
Установщик Git для OS X доступен для скачивания с сайта Git https://git-scm.com/download/mac.

Рисунок 7. OS X инсталлятор Git

Установка в Windows

Для установки Git в Windows также имеется несколько способов.
Официальная сборка доступна для скачивания на официальном сайте Git.
Просто перейдите на страницу https://git-scm.com/download/win, и загрузка запустится автоматически.
Обратите внимание, что это отдельный проект, называемый Git для Windows; для получения дополнительной информации о нём перейдите на https://gitforwindows.org. Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

Установка из исходников

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

Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat, and libiconv.
Например, если в вашей системе используется (Fedora) или (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:

Для того, чтобы собрать документацию в различных форматах (doc, html, info), понадобится установить дополнительные зависимости:

Примечание

Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны для корректной установки пакета

Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет :

Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет , который уже установлен в системах на базе Debian:

К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:

Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест:
с сайта Kernel.org https://www.kernel.org/pub/software/scm/git, или зеркала на сайте GitHub https://github.com/git/git/releases.
Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.

Затем скомпилируйте и установите:

После этого вы можете получать обновления Git посредством самого Git:

prev | next

Я не знаю, что вы только что сказали (Вариант 2)

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

Давайте сделаем это!

Скажем, вы хотите создать новый репозиторий. (Вероятно, так и есть! Именно здесь будет жить ваш проект. Если вы не собираетесь создавать новый репозиторий, вы, вероятно, захотите клонировать существующий репозиторий. Мы поговорим об этом позже, но именно так вы получаете чужой проект и информация, которая вам нужна для вашей работы или курса, который вы выбираете.)

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

Это хорошая идея, чтобы включитьПРОЧТИ МЕНЯфайл с информацией о вашем проекте. Вы можете создать один в то же время, когда вы создаете свой репозиторий, щелкнув флажок.

  • Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
  • Назовите репозиторий и добавьте краткое описание.
  • Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
  • Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)

Новый репозиторий
Создание вашего нового хранилища

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

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

Допустим, вы хотите внести некоторые изменения в свой файл README прямо на GitHub.

  • Сначала зайдите в свой репозиторий.
  • Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
  • Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
  • Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
  • Нажмите кнопку «Подтвердить изменения»

Редактирование вашего файла на GitHub
Передача ваших изменений

Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!). Довольно легко, правда?

Довольно легко, правда?

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

Создание ветки

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

В GitHub Desktop переходим в Branch > New Branch и создаем новую ветвь. Назовем ее «development» и нажмем Create Branch.

Создание новой ветки

После создания ветки, в центре раскрывающееся меню будет указывать на ту ветку, в которой мы работаем. Создание ветки копирует существующий контент (из ветки master) в новую ветку (development).

Работа с ветками

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

Сохраним изменения.
Вернемся в GitHub Desktop и обратим внимание, что на вкладке «Changes» у нас появились новые измененные файлы.

Изменения в файле показывают удаленные строки красным и новые строки зеленым цветом. Цвета помогают увидеть, что изменилось.

Закоммитим изменения в левом нижнем углу и кликнем на Commit to development.
Нажимаем Publish branch (в верхней части окна GitHub Desktop), чтобы сделать локальную ветку также доступной в Origin (GitHub). (Всегда существует две версии ветки: локальная версия и удаленная версия.)
Вернемся в основную ветку (выбираем master в раскрывающемся меню). Затем посмотрим на свой файл (в текстовом редакторе)

Стоит обратить внимание, что изменения, внесенные нами во время редактирования в ветке , не отображаются в основной ветке.

Обычно новую ветку создают, когда вносят значительные изменения в контент. Например, нужно обновить раздел («Раздел X») в своих документах. Возможно, опубликовать другие обновления не нужно, прежде чем публиковать подробные изменения в Разделе X. Если работа была в той же ветке, было бы сложно выборочно загружать обновления для нескольких файлов за пределами Раздела X без отправки обновлений, которые сделали к файлам в разделе Х.

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

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

Клонирование или скачивание репозитория

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .

Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.

Если хотите просто покопаться в каком-то проекте, то вместо клонирования можете сделать форк проекта на GitHub. Для этого нажмите кнопку Fork в верхнем правом углу сайта. Так вы добавите копию этого проекта в свои репозитории и сможете вносить туда любые изменения без вреда для оригинала.

Добавляем файлы в проект

Вот, чем мы займемся:

git statusgit addgit commit -m “ “git push

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

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

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать . После внесения изменений создается снимок состояния репозитория, для чего используется команда. А через добавляется сообщение об этом снимке.

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

Теперь ваши изменения сохранены в указателе локальной копии проекта. Для отправки изменений на удаленный репозиторий выполните команду:

git push

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

Актуальность версии можно проверить в любое время через команду .

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

  • Как писать Bash-однострочники для клонирования и управления GitHub/GitLab репозиториями
  • Top 100 наиболее популярных репозиториев на GitHub
  • Основы Git за 5 минут

Давай сделаем это!

фотоМервин ЧаннаUnsplash

Почему бы не оставить свой след и приветствовать всех, кто здесь, чтобы узнать о Git и GitHub? Мы собираемся создать простую приветственную стену с заметками от всех, кто хочет опробовать Git и GitHub и внести свой вклад в их первый проект с открытым исходным кодом.

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

Клонировать хранилищелибо на сайте GitHub, либо запустив

git clone https://github.com/bonn0062/github_welcome_wall.git
  • Создайте новую ветку и добавьте приветственную и вдохновляющую мысль в файл «welcome_wall.md». Вы можете сделать это на веб-сайте, но я настоятельно рекомендую вам попробовать клонировать репозиторий на ваш компьютер, открыть файл в вашем любимом текстовом редакторе и добавить туда свое сообщение. Это просто хорошее обучение!
  • Создать пул-запрос,
  • Напишите краткую заметку с описанием ваших изменений и нажмите зеленую кнопку, чтобы создать запрос на извлечение.

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

Поздравляем !!! Ты сделал это!

GIF черезGIPHY

Как всегда, если вы сделаете что-нибудь удивительное с этой информацией, я хотел бы услышать об этом! Оставьте сообщение в разделе ответов или обратитесь в любое время в Twitter@annebonnerdata,

Спасибо за чтение!

Если вы хотите выйти или найти больше интересных статей, пожалуйста, присоединяйтесь ко мне вПростота содержания!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector