установка, настройка и инициализация репозитория

480 auto

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

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

Что такое Git?

Git — это распределенная система управления версиями, которая устанавливается на машину, где будет вестись работа над проектом. Грубо говоря, git — это софт, который можно скачать отсюда и установить на Linux, Windows или MacOS. В некоторых дистрибутивах Linux, git уже предустановлен, например, в Ubuntu 18/20/22.

Кстати, git был разработан Линусом Торвальдсом, чтобы решить проблему командной разработки ядра Linux. Основная проблема командной разработки больших проектов в том, что со временем становится очень сложно менеджерить процессы добавления нового кода в проект, так же как и тестировать его или отлавливать баги.

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

  • Управление различными версиями проекта;
  • Создание и управление разными ветвями развития проекта;
  • Откат к предыдущим версиям проекта;
  • Быстрое клонирование проектов с удаленных git-серверов.

Надо сказать, что git — это не единственная система контроля версий. Есть еще Mercurial, Team Foundation Server, SVN и прочие решения, но все они сильно уступают в популярности git. В основном из-за того, что многие крупные IT-корпорации поддерживают и развивают git. Например, Microsoft, которой принадлежит gitHUB.

Если сейчас вам не совсем ясно что же такое git — не переживайте, в процессе прочтения статьи всё прояснится. Перейдем от слов к практике и пощупаем git вживую.

Работа с git: установка, настройка, создание репозитория

Как мы сказали ранее, git — это софт, который нужно установить на машину, где будет вестись разработка и настроить его. Прежде чем качать git — нужно проверить командой git —version текущую версию установленных пакетов, если ваша версия git сильно устарела, например наша версия git на Ubuntu 18 была 2.17+ (2.39 — актуальная версия), — ее следует обновить.

Установка и обновление git

Git можно установить на все популярные десктопные ОС: Windows, Linux, MacOS. В Ubuntu достаточно выполнить уже привычный многим набор команд: apt update && apt install -y git.

Если git уже установлен, но версия устарела — обновить git можно так:

  1. Скачайте репозиторий с исходниками git: git clone https://github.com/git/git;
  2. Обновите apt-репозиторий: apt update;
  3. Скачайте набор пакетов, необходимых для сборки GIT из исходников:
    1. sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-dev;
    2. sudo apt-get install asciidoc xmlto docbook2x;
    3. sudo apt-get install install-info.
  4. Сделайте симлинк: sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi.
  5. Перейдите в скачанный репозиторий командой cd и выполните следующий набор команд:
    1. make configure;
    2. ./configure —prefix=/usr;
    3. make all doc info;
    4. sudo make install install-doc install-html install-info.

Ещё раз выполните команду git —version, чтобы убедиться, что git успешно обновился. Теперь можно двигаться дальше и настроить git для работы.

Настройка git

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

Настройка имени и электронной почты участника команды производится локально через консоль командами:

  • git config —global user.name [имя пользователя];
  • git config —global user.email [электронная почта пользователя].

Если имя пользователя задается с пробелом (Имя Фамилия) — тогда его необходимо указывать в двойных кавычках, электронная почта всегда задается без кавычек. При вводе электронной почты и имени пользователя git не возвращает никакого ответа, чтобы убедиться в правильности введенных данных можно выполнить команду: git config —list.

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

Инициализация репозитория

Инициализация или создание репозитория производится командой git init в директории проекта, при этом директория как может содержать файлы проекта, так и может быть пустой. При вызове команды git init вы увидите следующее сообщение:

Тут следует обратить внимание на несколько важных вещей:

  • По умолчанию git создаёт ветку master, где будут размещаться коммиты. В gitHUB же дефолтная ветка называется main — несоответствие веток может привести к проблемам в будущем, лучше сразу переименовать ветку master в main;
  • Задать имя дефолтной ветки можно с помощью команды git config —global init. defaultBranch main, где main — название ветки. Эта команда работает до создания первого коммита;
  • Переименовать уже существующую ветку можно командой git branch -m [название ветки].

При инициализации репозитория в директории проекта будет создана скрытая поддиректория .git, которая содержит различные сущности git и информацию о репозитории:

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

В git есть три зоны видимости файлов:

Первая зона видимости: рабочая директория (Working directory) — это директория, содержащая файлы проекта. Просмотреть все файлы в директории можно командой ls -la.

Вторая зона видимости: индекс (Staging area) — это виртуальная зона, где фиксируются изменения внесенные в файлы проекта перед тем, как они будут сохранены (закоммичены). Посмотреть, какие изменения содержатся в индексе можно командой git status.

Третья зона видимости: репозиторий (Repository) — это сохраненные изменения, попавшие в директорию .git после коммита. В этой зоне содержатся различные git-объекты. Напрямую с ними взаимодействовать нельзя.

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

Добавление файлов в индекс

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

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

На этом скрине красным выделены два действия с файлами, которые пока ещё не попали в индекс: 1) Внесение изменений в файл main.

py; 2) Переименование файла modules.md в python_modules.md. Отметим, что старый файл modules.md помечен теперь, как удаленный, а вот новый файл python_modules.md вообще гитом не трекается — его нужно добавить в индекс командой git add python_modules.md.

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

Кратко о GIT и его базовых настройках и командах

GIT — это система управления версиями, которая входит в многие популярные дистрибутивы Linux, например, Ubuntu 16+. Если в вашей сборке Linux нет гита из коробки, его всегда можно установить из apt (там будет не самая свежая версия) или скачать исходники с официального сайта git и скомпилировать их, как указано в нашей инструкции. Проверить версию git можно командой git —version, если git установлен корректно и версия отражается — можно переходить к созданию репозитория.

Репозиторий git — это скрытая директория .git в папке вашего проекта, где хранятся специальные git-объекты, описывающие состояние файлов и директорий вашего проекта во времени. Каждый раз, когда вы делаете коммит — вы сохраняете состояние файлов и директорий вашего проекта в git. Инициализируется или создается Git-репозиторий командой git init. После инициализации репозитория в него можно добавлять файлы для индексации.

В git есть три зоны видимости файлов:

  1. Рабочая директория проекта — это видимая зона, где отражаются файлы вашего проекта в текущем коммите, если вы удалили файл и сделали коммит, то в текущем времени его больше не будет, но если откатится на предыдущий коммит, то файл там будет, так как GIT сохраняет файлы целиком;
  2. Индекс или стейджинг — это невидимая зона, туда сохраняются подготовленные к коммиту изменения. Добавляются изменения в индекс командой git add .. Просмотреть изменения можно командой git status, а отправляются изменения в репозиторий командой git commit -m «комментарий»;
  3. Репозиторий — это скрытая директория . git, где в бинарном виде хранятся копии файлов и директорий. Они находятся в директории .git/objects/… Прочитать их простой командой типа cat не выйдет, для этого используется команда git cat-file -p [hash git-object].

Краткая логическая схема работы с git-репозиторием может выглядеть так:

Коммит — это одна из базовых сущностей git. Коммиты позволяют перемещаться по разным версиям проекта. Другая организационная единица git — это ветви. Ветви позволяют логически разделять направления разработки. О коммите и ветвях мы подробно поговорим в нашей следующей статье.

Ещё одной фишкой гита является возможность быстро скачивать уже существующие репозитории с gitHUB на сервер, работать над ними и загружать обратно, часто для такой работы требуются сторонние библиотеки и модули. Для такой работы удобнее всего использовать VPS с подключением по SSH, например, от 1cloud.

6 статей по работе с Git для новичков

480 auto

Мы продолжаем делиться знаниями с нашими читателями. В этот раз мы взялись за разработку большого цикла публикаций про Git. Всего вышло 6 статей, которые пошагово и максимально доходчиво описывают работу с Git. В материалах много yaml- и Python-кода, shell-команд.

После прочтения статей вы научитесь самостоятельной и одиночной работе в Git: сможете установить и настроить локальный Git-репозиторий, развернуть репозиторий на GitHub, связать их между собой и настроить автоматическую доставку кода вашего проекта на VPS 1cloud.

 

Из этой первой статьи вы узнаете: что такое Git, зачем он нужен, как его установить на локальный компьютер или VPS и как инициализировать репозиторий.

Git: установка, настройка, инициализация репозитория

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

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

Продолжаем углубляться в Git. Настало время разобраться с объектами Git и научиться с ними работать — будем создавать ветви, коммиты, мерджить их и разбираться в том, как работают зоны видимости в Git.

Git: коммиты, ветки и перемещение между ними

Из второй статьи вы узнаете: что такое коммит и как он работает, что такое head tree и blob, и как их использовать. Познакомитесь с ветвями и командами для управления ими.

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

Хранить исходный код проекта на локальной машине небезопасно и не удобно. Для хранения Git-репозиториев есть специальные облачные хранилища Git-репозиториев, например: GitHUB, GitBucked, GitLab и многие другие хостинги. О GitHUB и расскажем в этой статье.

Git: работа с gitHUB

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

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

GitHub — это не только хостинг Git-репозиториев, а облачная площадка с множеством инструментов для автоматизации процессов разработки и CI/CD. Одним из таких сервисов автоматизации является GitHub Actions.

GitHub Actions: знакомство и первые шаги

Из статьи вы узнаете: что такое GitHub Actions, как начать им пользоваться, что такое виртуальный сервер GitHub Actions, workflow, jobs и steps.

Материал статьи поможет разобраться в том, как устроена экосистема GitHub Actions и как работают основные его сущности. Это позволит вам сделать первые шаги в настройке своего проекта по автоматизации работы с CI/CD.

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

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

В этой финальной статье мы объединим все полученные ранее знания и разработаем workflow, который будет получать доступ к репозиторию нашего тестового проекта, создавать VPS через API, загружать код проекта на него и настраивать рабочее окружение проекта.

В итоге у вас получится полноценный рабочий проект по автоматическому развертыванию VPS 1cloud через API и доставке кода проекта на него.

GIT для начинающих | KodeKloud

Что такое GIT?

Какой самый важный инструмент сегодня должен быть известен как разработчикам, так и операционным группам? Говно! Git — это распределенная система контроля версий, которая позволяет разработчикам и операционным группам сотрудничать и отслеживать изменения, внесенные в проект. GIT как инструмент DevOps расширяет возможности совместной работы и ускоряет циклы выпуска. Любой, кто хочет начать свою карьеру в DevOps или повысить свой уровень, должен начать с основ, и GIT является наиболее фундаментальным требованием из всех.

Почему вы должны использовать GIT

Многие из самых популярных сегодня проектов с открытым исходным кодом разрабатываются на Github — Kubernetes, Ansible, Tensor Flow, Rust, Node.js, Go, Terraform, Helm Charts являются одними из лучших среди 100 миллионов репозиториев. Если вы хотите учиться и участвовать в этих проектах, понимание Git является обязательным, и наш курс GIT для начинающих здесь, чтобы помочь!

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

Курс GIT для начинающих.
Чему вы научитесь

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

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

Предпосылки
  • Основы командной строки Linux
  • Знание программирования/кодирования не требуется
Визуальное обучение

Git — сложная тема, особенно для новичка. Мы упрощаем сложные концепции, используя:

  • Визуализации
  • Анимации
  • Примеры реальных проектов
  • Аналогии
  • Демонстрации
  • Больше никаких скучных презентаций!
Практическое обучение

Учиться на практике — лучший способ учиться. Наших лабораторий:

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

Учебное пособие: GIT для абсолютно

Существует довольно универсальный стереотип о прогнозах: мы регистрируемся. желая взаимодействовать исключительно с нашими многочисленными компьютерными мониторами, предпочтительно в затемненной комнате. Мы покидаем нашу боевую станцию/крепость одиночества/кодовое додзё только тогда, когда нас побуждает биологическая потребность есть, спать или пользоваться туалетом. Мы никогда не разговариваем с другими, кроме как (а) в случае крайней необходимости или (б) как наш аватар онлайн-ролевой игры (неотразимо хорошо обеспеченный маг/воин высокого уровня). Как и все стереотипы, это в какой-то мере укоренено в реальности. Наши увлечения как программистов заставляют нас взаимодействовать с машинами больше и, возможно, более эффективно, чем с другими людьми.

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

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

Что такое Git?

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

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

Изучение git может быть пугающим, если у вас самого мало опыта программирования или нет, но просто продолжайте думать о нем как о забавно выглядящем Google Docs, и у вас все получится! Забавный факт: git был изобретен Линусом Торвальдсом — тем самым Линусом, который создал операционную систему Linux с открытым исходным кодом, которая теперь работает на многих интернет-ресурсах, включая Google и Facebook.

Итак: git — это часть программного обеспечения, которое вы устанавливаете на свой компьютер, и которое затем обрабатывает для вас контроль версий. Что же такое контроль версий?

Что такое контроль версий?

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

Что ж, благодаря git это так. Контроль версий происходит, когда вы устанавливаете git на свой компьютер. Git создан для создания этого нового каталога проекта и для отслеживания всех изменений, которые вы вносите во все без исключения файлы, которые вы помещаете в этот каталог. По мере развития событий и внесения дополнений и изменений git делает «моментальный снимок» текущей версии. И это, друзья, контроль версий: внесите небольшое изменение, сделайте снимок, сделайте еще одно небольшое изменение, сделайте снимок… И сохраните все эти снимки в хронологическом порядке. Затем вы можете использовать git для перехода назад и вперед по мере необходимости по каждой версии вашего каталога проекта.

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

Мы обсудим GitHub здесь лишь вкратце, потому что сначала важно понять, что делает сам git. Однако использование самого GitHub — это совершенно другая кривая обучения, которую мы изучим в нашем следующем руководстве.

Сотрудничество с Git

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

Git — это распределенная система контроля версий. Это означает, что в git есть команды, которые позволяют вам «проталкивать» свои изменения на машины других людей и «перетягивать» их изменения на свои. Между тем, GitHub хранит основную версию — на самом деле, основную библиотеку всех версий, когда-либо — проекта, чтобы не допустить, чтобы все стало слишком дико и безумно.

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

Получение git

Шаг 1. Загрузите git

Выберите подходящий для вашей операционной системы: Mac OS, Linux или Windows. Он установится самостоятельно. Не волнуйтесь, если вам кажется, что ничего не происходит,

Шаг 2. Откройте терминал

Извините, но вам просто нужно использовать командную строку. Итак, заткнитесь и шелушитесь: пользователи Linux, вы уже знаете, что делать. Для пользователей Mac это Finder -> Приложения -> Утилиты -> Терминал. Пользователи Windows (почему вы вообще здесь?), вам придется скачать и установить эмулятор терминала.

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

Шаг 3. Сообщите git, что вы существуете

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

git config —global user.name ‘My_Name’ git config —global user.email ‘[email protected]’ git config —global color.ui ‘авто’

git config —global user. name ‘My_Name’

git config —global user.email ‘[email protected]

git config —global color.ui ‘auto’


Последняя строка не является обязательной; он говорит git автоматически делать любой вывод команд git в терминал красиво окрашенным, что намного легче читать, а также понимать. Причина, по которой мы помещаем «-global» перед каждым, заключается в том, чтобы не вводить эти команды конфигурации в следующий раз, когда мы запускаем проект git в нашей системе. Таким образом, git знает, кто вы — навсегда.

Шаг 4. Создайте новый каталог

Теперь пришло время попрактиковаться в настройке примера проекта. Создайте себе пустой каталог для хранения всех ваших великолепных файлов проекта, которые скоро появятся (подсказка: $mkdir (yourDirectoryNameHere). Затем перейдите в него и введите волшебные слова «git init»:

«Git init» создает новый репозиторий git, обычно называемый «репозиторий». Представьте его как папку вашего проекта, только теперь со сверхспособностями git. Репозиторий содержит все файлы вашего проекта, а также дополнительный, в основном невидимый материал, который git генерирует для отслеживания и хранения каждого история изменений файла.

Начало рабочего процесса Git

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

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

Шаг 5. Добавьте файл «README» и файлы проекта. не нужно быть энциклопедическим — только основные факты, мэм. Это, кстати, базовая попытка командной строки, не специфичная для git: «touch README.md»:

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

Шаг 6. Скопируйте ваш репозиторий

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

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

Прелесть git в том, что он отслеживает все эти вещи для вас — кто что где изменил — и организует все это.

Итак, скопируйте — или клонируйте, говоря языком git — ваш репозиторий, выполнив команду «$git clone /path/to/your_repository:»

(Если вы начинаете с копирования файла, который уже запущен кем-то другим, взяв его с любого удаленного сервера/сервера, ваша команда будет выглядеть так: «$git clone username@host:/path/to/repository»).

Обратите внимание, что внутри нашего исходного каталога git-for-dummies теперь есть новая копия каталога git-for-dummies (рядом с нашим README). Причина, по которой он сообщает нам, что мы, похоже, скопировали пустой репозиторий, заключается в том, что мы еще не сохранили наши новые дополнения (подготовили наши коммиты).

Шаг 7. Проверьте статус

(Кстати, за кулисами я добавил файл-заполнитель с именем «my_file.md», чтобы в нашем репозитории было что-то помимо файла readme). Теперь, когда у нас есть несколько файлов в нашем репозитории, давайте посмотрим, как git их обрабатывает. Чтобы проверить текущий статус вашего репозитория, введите «git status»:

Шаг 8. Скажите git добавить ваши изменения

Статус Git сообщает нам, что у нас есть новые файлы, которые официально не были процесс отслеживания git. Чтобы сказать git, что да, пожалуйста, будьте милым консьержем этих файлов, мы добавляем их в git. Как ни странно, это называется «подготовкой», когда на самом деле команда «git add (здесь имя файла)»:

Обратите внимание, как цвет текста изменился с красного на зеленый: вы сделали Git счастливым! После того, как вы разместили свои файлы с помощью «git add», вы можете зафиксировать их в git.

Шаг 9 git commit!

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

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

Тем не менее, ваше самое первое сообщение фиксации при создании нового репозитория всегда будет «Первоначальная фиксация». Сообщение фиксации имеет формат «$git commit -m»my сообщение фиксации»:

Git идентифицирует каждую уникальную фиксацию, присоединяя к каждой фиксации длинное шестнадцатеричное число. На скриншоте обратите внимание на то, что «a4105ea» — наш первый коммит. Это похоже на подпись к вашему снимку. Если нам нужно будет вернуться в прошлое и получить доступ к этой конкретной версии нашего проекта, это «имя», которое вы должны использовать для идентификации нужной версии.

Шаг 10. Шага 10 нет, потому что ВЫ ЭТО СДЕЛАЛИ!!!! ???

Обратите внимание, как на снимке экрана выше после коммита мы сделали «git status». git вернул прекрасное сообщение «Нечего коммитить, рабочее дерево чистое» (помните наши деревья? Если нет, вернитесь и перечитайте раздел «Рабочий процесс git» выше). Это означает, что вы все догнали и текущие. Этот гит сделал и сохранил снимок вашего проекта. Хотя это рано, это похоже на детскую картинку.

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

Кхм.