Содержание

Введение в Git для начинающих, обучение с нуля – базовый курс, 16 уроков

Включено в курс

16 уроков (видео и/или текст)

18 упражнений в тренажере

64 проверочных теста

Самостоятельная работа

Дополнительные материалы

Помощь в «Обсуждениях»

Чему вы научитесь

  • Вести разработку в соответствии с современными инженерными практиками
  • Эффективно управлять исходным кодом, добавлять в общее хранилище, анализировать историю и изменять ее
  • Работать с GitHub и контрибьютить в открытые проекты

Описание

На этом курсе вы изучите систему управления версиями — Git. Вы узнаете больше о работе с историей изменений файлов и репозиториями. В итоге вы научитесь легко восстанавливаться после ошибок, изучать историю изменений и вести совместную разработку. Основы Git пригодятся, если вы решите управлять историей исходного кода, работать с удаленными репозиториями как Github. Знания из этого этого курса помогают программистам уверенно работать с кодом проекта как в одиночку, так и большими командами. Этот курс подойдет тем, кто начинает изучать программирование, так и тем, кто хочет обучиться современным практикам. Чтобы учиться было проще, стоит заранее изучить основы командной строки.

github рабочая директория клонирование восстановление

Уроки курса

Продолжительность 18 часов

  • Введение

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

    теория

  • Установка и настройка

    Рассказываем, как настроить операционную систему (Ubuntu/MacOSOS/Windows), установить Git и редактор кода VSCode, создать аккаунт на GitHub. А также о том, что поможет научиться владеть Git виртуозно.

    теория

  • Рабочий процесс

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

    теория

    тесты

    упражнение

  • Интеграция с GitHub

    Учимся настраивать GitHub, создавать в нем репозиторий и соединять его с локальным репозиторием. А также клонировать репозиторий, созданный на GitHub, на свой компьютер.

    теория

    тесты

    упражнение

  • Рабочая директория (Working Directory)

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

    теория

    тесты

    упражнение

  • Анализ сделанных изменений

    Анализировать изменения важно даже в небольших проектах. Разбираемся, почему. Знакомимся с командой git diff, которую нужно обязательно запускать перед каждым коммитом.

    теория

    тесты

    упражнение

  • Анализ истории изменений (коммитов)

    Учимся получать разнообразную информацию о прошлых коммитах: кто, когда и как менял код. Изучаем команды, которые позволят решить эту задачу: log, show, blame, grep.

    теория

    тесты

    упражнение

  • Отмена изменений в рабочей директории

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

    теория

    тесты

    упражнение

  • Отмена коммитов

    Что делать, если коммит уже сделан, но по каким-то причинам нас не устраивает? Изучаем специальные команды, позволяющие упростить отмену, либо изменение коммита: revert, reset.

    теория

    тесты

    упражнение

  • Изменение последнего коммита

    Сделали коммит, но забыли добавить часть файлов? Разбираемся, как добавить изменения в текущий коммит, не создавая новый.

    теория

    тесты

    упражнение

  • Индекс

    Как сделать коммит, если в рабочей директории есть исправления, не связанные напрямую с основным изменением? На помощь приходит индекс. Изучаем способы работы с индексом.

    теория

    тесты

    упражнение

  • Перемещение по истории

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

    теория

    тесты

    упражнение

  • Понимание Git

    Основная «работа» Git — формирование множества односвязных списков, состоящих из коммитов. Знакомимся с ключевым понятием Git и термином «ветка».

    теория

    тесты

    упражнение

  • Игнорирование файлов (Gitignore)

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

    теория

    тесты

    упражнение

  • Stash

    Как «прятать» изменения в рабочей директории и восстанавливать их при необходимости? Знакомимся с командой stash.

    теория

    тесты

    упражнение

  • Открытые проекты (Open Source)

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

    теория

  • Самостоятельная работа

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

Формат обучения

Испытания

Это практические задания, которые мы советуем выполнить после завершения курса. Задания помогут вам получить дополнительный опыт в программировании и закрепить полученные навыки. Обычно мы рекомендуем выполнить 3-5 испытаний. Но если не получается, не отчаивайтесь. Просто вернитесь к ним позже

Юрий Бачевский01 октября 2020

Классный, крутой и офигенный курс!

Прошел на одном дыхании! А главное многое, для себя, наконец-то понял!!! Компактный и без воды! Понятно что улучшать его можно бесконечно. Но как по мне, так это мега крутая шпаргалка. Где все очень четно и по делу. Единственное, хотелось бы тему про «ветки» раскрыть.

PS.

А еще в уроке про Интеграцию с GIT написано вот что….

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

рассматриваются позже, когда появится хоть какой-то опыт работы с Git

Из этого сообщения не совсем ясно, когда именно рассматривается тема веток и rebase? Т. к. в курсе эта тема не раскрыта.

Marina18 февраля 2022

Хочу сказать большое спасибо за очень понятно изложенный материал. Особенно классно заходит после курса ‘основы командной строки’!

arch31 декабря 2021

У меня ничего не получалось.. пока внимательно не прочитал задачу 😀 Ваши упражнения на 50% состоят из упражнений на внимательность. Так держать!

Богдан Табор22 апреля 2021

Тесты не проходили, пока через vim не скопировал весь текст) А всего-лишь неправильный дефис ввел.

Но вобщем класное задание! Спасибо, Хекслет!)

Йоси Адлер28 августа 2017

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

Рекомендуемые программы

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

Профессия

Фронтенд-разработчик

Разработка фронтенд-компонентов для веб-приложений

13 октября 10 месяцев

Профессия

Python-разработчик

Разработка веб-приложений на Django

13 октября 10 месяцев

Профессия

Java-разработчик

Разработка приложений на языке Java

13 октября 10 месяцев

Профессия

PHP-разработчик

Разработка веб-приложений на Laravel

13 октября 10 месяцев

Профессия

Node.js-разработчик

Разработка бэкенд-компонентов для веб-приложений

13 октября 10 месяцев

Профессия

Верстальщик

Верстка с использованием последних стандартов CSS

в любое время 5 месяцев

Профессия

Fullstack-разработчик

Разработка фронтенд- и бэкенд-компонентов для веб-приложений

13 октября 16 месяцев

Основы работы с Git — Разработка на vc.ru

1922 просмотров

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

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

Git послужит в качестве системы контроля версий, а Github — веб-сервиса для хостинга репозиториев Git. Осуществление этого проекта предполагает предварительное создание копии или нового репозитория. Если же вы этого еще не сделали, но хотите научиться, то добро пожаловать на этот ресурс.

Приступим!

Этап 1. Проверка ветки

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

git branch

Если увидели этот результат, то притормозите!

Можно написать новый код непосредственно в ветку master при условии, что вы не работаете с директорией приложения, содержащей несколько папок и файлов. Но если вы планируете работу над большим проектом, то лучше этого не делать.

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

Итак, что же следует делать, если вы находитесь на ветке master?

Этап 2. Переключение на новую ветку

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

git checkout -b

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

Этап 3. Написание кода

Приступаем к основной части статьи: непосредственно процесс создания кода!

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

Этап 4. Просмотр статуса

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

Если все в полном порядке, то для индексации этих изменений просто введите в терминал следующую команду:

git add .

Зеленый цвет файлов означает, что изменения были проиндексированы:

Этап 5. Создание коммита

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

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

git commit -m “useful info about the code I wrote”.

Флаг -m указывает команде git commit, что вы добавляете полезный комментарий о коде. Итак, его уже можно отправлять, но прежде немного задержимся еще на одном этапе.

Этап 6. Проверка ветки

Догадываюсь, что вас не обрадует предложение по нескольку раз вводить в терминал команду git branch. Но так надо. Проверим дважды — от нас не убудет. Затовы избавите себя от необходимости запоминать имена веток, поскольку за вас это сделает инструмент!

Этап 7. Отправка

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

git push origin

Вы увидите нечто подобное:

Если вы используете VScode, то эта команда + клик на http-адрес перенесут вас на этап 8. И вот ваша ветка запущена в эфир!

Этап 8. Запросы на слияние

На этом этапе мы готовы, можно сказать сгораем от нетерпения, написать дополнительный код. Но прежде посмотрим, что же мы отправили. Перейдите на онлайн-репозиторий Github и сделайте запрос на слияние ветки:

Кликните на Pull request для активации процесса

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

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

Этап 9. Лицом к лицу с master

На данный момент ветка master в онлайн-репозитории содержит больше кода, чем в локальном. Надо бы это исправить. Вернитесь на ветку master и введите в терминал следующую команду:

git pull origin master

Если все сработало, то вы увидите эти зеленые строки плюсов:

Этап 10. Итоги

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

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

Оригинал данной статьи на английском:Alex Mata: Introduction to Git Workflow

Что такое Git? — Azure DevOps

  • Статья
  • Чтение занимает 3 мин

Git стал мировым стандартом для управления версиями. Так что же именно это?

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

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

Основы Git

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

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

Ветви

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

Файлы и фиксации

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

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

Преимущества Git

Преимущества Git много.

Одновременная разработка

Каждый имеет собственную локальную копию кода и может работать одновременно с собственными ветвями. Git работает в автономном режиме, так как почти каждая операция является локальной.

Более быстрые выпуски

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

Встроенная интеграция

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

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

Git работает с любой командой

Использование Git с средством управления исходным кодом повышает производительность команды, поощряя совместную работу, применяя политики, автоматив процессы и повышая видимость и трассировку работы. Команда может урегулировать отдельные средства для управления версиями, отслеживания рабочих элементов, а также непрерывной интеграции и развертывания. Кроме того, они могут выбрать решение, например GitHub или Azure DevOps , которое поддерживает все эти задачи в одном месте.

Запросы на вытягивание

Используйте запросы на вытягивание , чтобы обсудить изменения кода с командой, прежде чем объединить их в главную ветвь. Обсуждения в запросах на вытягивание являются бесценными для обеспечения качества кода и повышения знаний в вашей команде. Такие платформы, как GitHub и Azure DevOps, предлагают широкий интерфейс запроса на вытягивание, где разработчики могут просматривать изменения файлов, оставлять комментарии, проверять фиксации, просматривать сборки и голосовать за утверждение кода.

Политики ветвления

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

Следующие шаги

Установка и настройка Git

основных команд Git | Atlassian Git Tutorial

git добавить

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

Сохранение изменений: git addИзучение Git с помощью Bitbucket Cloud: копирование репозитория Git и добавление файловИспользование веток: git mergeПроверка репозитория: git status

ветка git

Эта команда является вашим универсальным инструментом администрирования филиала. Он позволяет создавать изолированные среды разработки в одном репозитории.

Использование веток: git branchИспользование веток: git checkoutИспользование веток: git mergeИзучение Git с Bitbucket Cloud: использование ветки Git для слияния файла

git checkout

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

Использование веток: git checkoutОтмена изменений: git checkoutСравнение рабочих процессов: рабочий процесс Gitflow

гит чистый

Удаляет неотслеживаемые файлы из рабочего каталога. Это логический аналог git reset, который (обычно) работает только с отслеживаемыми файлами.

Отмена изменений: git clean

git clone

Создает копию существующего репозитория Git. Клонирование — наиболее распространенный способ для разработчиков получить рабочую копию центрального репозитория.

Git LFSСравнение рабочих процессов: разветвление рабочего процессаНастройка репозитория: git clone

git совершить

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

Использование веток: git mergeПереписывание истории: git commit —amendИзучение Git с помощью Bitbucket Cloud: Скопируйте репозиторий Git и добавьте файлы Сохранение изменений: git add

git commit —amend

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

История перезаписи: git commit —amend

git config

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

Настройка репозитория: git configGit LFSInstall Git: установка Git в Mac OS XInstall Git: установка Git в Linux

git fetch

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

Синхронизация: git fetchRefs и Reflog: RefspecsSyncing: git pull

git init

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

Настройка репозитория: git init

git log

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

Проверка репозитория: git logРасширенный журнал Git: фильтрация истории коммитовРасширенный журнал Git: форматирование вывода журналаРасширенные руководства по Git: обзор

git слияние

Мощный способ интеграции изменений из различных ветвей. После разветвления истории проекта с помощью ветки git git merge позволяет снова собрать ее вместе.

Слияние и перебазирование: пошаговое руководство по рабочему процессуИспользование ветвей: git mergeСравнение рабочих процессов: рабочий процесс GitflowСлияние и перебазирование: концептуальный обзор

git pull

Pulling — это автоматизированная версия git fetch. Он загружает ветку из удаленного репозитория, а затем сразу же объединяет ее с текущей веткой. Это Git-эквивалент svn update.

Синхронизация: git pullComparing Workflows: централизованный рабочий процессGit LFSComparing Workflows: Forking Workflow

git push

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

Синхронизация: git pushRefs и Reflog: RefspecsСравнение рабочих процессов: Gitflow WorkflowGit LFS

git перебазировать

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

Слияние и перебазирование: пошаговое руководство по рабочему процессу.

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

История перезаписи: git rebase -i

git reflog

Git отслеживает обновления в конце ветвей, используя механизм, называемый reflog. Это позволяет вам вернуться к наборам изменений, даже если на них не ссылается ни одна ветвь или тег.

История перезаписи: git reflog

git remote

Удобный инструмент для администрирования удаленных подключений. Вместо того, чтобы передавать полный URL-адрес командам fetch, pull и push, он позволяет вам использовать более значимый ярлык.

Синхронизация: удаленный git

сброс git

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

Отмена изменений: git resetReset, Checkout и Revert: OperationReset, Checkout и Revert на уровне фиксации: OperationsUndoing Changes на уровне файлов: git clean

git revert

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

Отмена изменений: git revertReset, Checkout и Revert: OperationReset, Checkout и Revert на уровне фиксации: сводка

git status

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

Проверка репозитория: git statusGit StashLearn Git с Bitbucket Cloud: используйте ветку Git для слияния файлаLearn Git с Bitbucket Cloud: скопируйте репозиторий Git и добавьте файлы

Основы Git | Проект Один

Введение

В этом уроке мы рассмотрим общие команды Git, используемые для управления вашими проектами и загрузки вашей работы на GitHub. Мы называем эти команды базовым рабочим процессом Git . Когда вы используете Git, вы будете использовать эти команды в 70-80% случаев. Так что, если вы сможете их записать, вы освоите Git более чем наполовину!

Обзор урока

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

  • Как создать репозиторий на GitHub
  • Как получить файлы на GitHub и обратно
  • Как сделать «моментальные снимки» кода

Назначение

Прежде чем начать!
  • Github недавно обновил название ветки по умолчанию. Это означает, что вам нужно убедиться, что вы используете последнюю версию git (2.28 или более позднюю). Вы можете проверить свою версию, запустив: git --версия
  • Если вы еще этого не сделали, установите для локальной ветки git по умолчанию значение 9.0154 основной . Вы можете сделать это, запустив: git config --global init.defaultBranch main
  • Для получения дополнительной информации об изменении с master на main см. репозиторий переименования GitHub.
Создать хранилище

  1. Вы уже должны были создать учетную запись GitHub в уроке «Настройка Git». Если вы еще этого не сделали, вы можете зарегистрироваться здесь.

  2. Создайте новый репозиторий, нажав кнопку, показанную на снимке экрана ниже.

  3. Дайте вашему репозиторию имя «git_test» в поле ввода имени репозитория. Установите флажок «Добавить файл README». А затем создайте репозиторий, нажав зеленую кнопку «Создать репозиторий» внизу страницы.

  4. Это перенаправит вас в ваш новый репозиторий на GitHub. Чтобы подготовиться к копированию (клонированию) этого репозитория на локальный компьютер, нажмите зеленую кнопку «Код». Затем выберите параметр SSH и скопируйте строку под ним. ПРИМЕЧАНИЕ. НЕОБХОДИМО выбрать параметр SSH, чтобы получить правильный URL-адрес.

  5. Давайте воспользуемся командной строкой на вашем локальном компьютере, чтобы создать новый каталог для всех ваших проектов Odin. Создайте каталог с именем repos с помощью команды mkdir в своей домашней папке. Если вы не уверены, что находитесь в своей домашней папке, просто введите cd ~ . Как только это будет сделано, перейдите в него с помощью команды cd .

  6. Теперь пришло время клонировать ваш репозиторий из GitHub на ваш компьютер с помощью git clone , за которым следует URL-адрес, который вы скопировали на последнем шаге. Полная команда должна выглядеть примерно так: git clone [email protected]:USER-NAME/REPOSITORY-NAME.git . Если ваш URL-адрес выглядит как https://github.com/USER-NAME/REPOSITORY-NAME.git , вы выбрали вариант HTTPS, а не требуемый параметр SSH.

  7. Вот оно! Вы успешно подключили репозиторий, созданный вами на GitHub, к вашему локальному компьютеру. Чтобы проверить это, вы можете ввести cd в новую загруженную папку git_test , а затем ввести git remote -v в командной строке. Это отобразит URL-адрес репозитория, созданного вами на GitHub, который является удаленным для вашей локальной копии. Возможно, вы также заметили слово origin в начале команды git remote -v 9.Выход 0155, который является именем вашего удаленного соединения. Имя «источник» является одновременно и значением по умолчанию, и соглашением для удаленного репозитория. Но с тем же успехом его можно было бы назвать «вечеринка-попугай» или «танцующий банан». (Пока не беспокойтесь о деталях происхождения, они появятся ближе к концу этого урока.)

Использование рабочего процесса Git

  1. Создайте новый файл в папке git_test с именем «hello_world.txt» с помощью команды коснитесь hello_world.txt .

  2. Введите git status в свой терминал. Обратите внимание, что в выходных данных ваш файл hello_world.txt выделен красным цветом, что означает, что этот файл не подготовлен.

  3. Введите git add hello_world.txt . Эта команда добавляет ваш файл hello_world.txt в промежуточную область в Git. Промежуточная область является частью двухэтапного процесса создания коммита в Git. Думайте о промежуточной области как о «комнате ожидания» для ваших изменений, пока вы их не зафиксируете. Теперь введите git статус снова. Обратите внимание, что в выходных данных ваш файл теперь отображается зеленым цветом, что означает, что этот файл теперь находится в промежуточной области.

  4. Введите git commit -m "Добавить hello_world.txt" , а затем еще раз введите git status . Теперь в выводе должно быть написано: « ничего не нужно фиксировать, рабочее дерево чистое », что указывает на то, что ваши изменения были зафиксированы. Не волнуйтесь, если вы получите сообщение, в котором говорится: « восходящего потока больше нет 9». 0278». Это нормально и отображается только в том случае, если ваш клонированный репозиторий в настоящее время не имеет веток. Это будет решено после того, как вы выполните остальные шаги в этом проекте.

    Сообщение « Ваша ветка опережает «origin/main» на 1 фиксацию » просто означает, что теперь у вас есть более новые снимки, чем те, что находятся в вашем удаленном репозитории. Далее в этом уроке вы будете загружать свои снимки.

  5. Тип git log и посмотрите на вывод. Вы должны увидеть запись для коммита « Add hello_world.txt ». Вы также увидите подробную информацию об авторе, сделавшем фиксацию, а также дату и время, когда фиксация была сделана. Если ваш терминал застрял на экране с (END) внизу, просто нажмите «q», чтобы выйти. Вы можете настроить параметры для этого позже, но пока не беспокойтесь об этом.

Изменить файл или два

  1. Откройте файл README. md в любом текстовом редакторе. В этом примере мы откроем каталог в Visual Studio Code с помощью команды code. внутри вашего репозитория.

    Пользователи MacOS: если ваш терминал читает «команда не найдена: код» , вы должны вернуться к основам командной строки и следовать предоставленным инструкциям, чтобы эта команда работала.

  2. Добавить «Привет, Один!» к строке 3 файла README.md и сохраните файл с помощью «Ctrl+S» (или «Command+S» на Mac).

  3. Вернитесь к своему терминалу или, если вы используете Visual Studio Code, вы можете открыть встроенный терминал, нажав Ctrl + ` (обратная кавычка). Затем введите git status . Вы заметите, что README.md теперь отображается как не подготовленный и не зафиксированный.

  4. Добавьте README.md в промежуточную область с помощью git add README. md .

  5. Можете ли вы угадать, что git status теперь будет выводиться? README.md будет отображаться зеленым текстом. Это означает, что README.md был добавлен в тестовую область. Файл hello_world.txt не будет отображаться, потому что он не был изменен с момента фиксации.

  6. Откройте файл hello_world.txt, добавьте в него текст, сохраните его и проиндексируйте. Вы можете использовать git add . , чтобы добавить все файлы в текущем каталоге и во все последующие каталоги в промежуточную область. Затем введите git status еще раз, и теперь все должно быть в промежуточной области.

  7. Наконец, давайте зафиксируем все файлы, находящиеся в промежуточной области, и добавим описательное сообщение фиксации. git commit -m "Редактировать README.md и hello_world.txt" . Затем еще раз введите git status , что выведет « ничего для фиксации ».

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

Отправьте свою работу на GitHub

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

  1. Введите git push . Чтобы быть более конкретным, введите git push origin main . Поскольку вы не имеете дело с другой веткой (кроме main ) или другим удаленным (как указано выше), вы можете оставить значение 9.0154 git push , чтобы сэкономить несколько нажатий клавиш. ПРИМЕЧАНИЕ. Если на этом этапе вы получаете сообщение «Поддержка аутентификации по паролю была удалена 13 августа 2021 г. Вместо этого используйте токен личного доступа», значит, вы выполнили шаги неправильно и выполнили клонирование с использованием HTTPS, а не SSH. Выполните следующие действия, чтобы изменить удаленный доступ на SSH, а затем попытайтесь выполнить отправку на Github.

  2. Введите git status в последний раз. Он должен вывести «: Ваша ветка обновлена ​​до «origin/main». ничего не делать, рабочее дерево чистое ».

  3. Когда вы перезагрузите репозиторий на GitHub, вы должны увидеть файлы README.md и hello_world.txt, которые вы только что отправили туда с вашего локального компьютера.

Примечание/предупреждение

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

Шпаргалка

Это справочный список наиболее часто используемых команд Git. (Вы можете добавить эту полезную страницу в закладки.) Постарайтесь ознакомиться с командами, чтобы со временем запомнить их все:

  • Команды, относящиеся к удаленному репозиторию:
    • git clone [email protected]:USER-NAME/REPOSITORY-NAME.git
    • git push или git push origin main (оба выполняют одну и ту же цель в этом контексте)
  • Команды, относящиеся к рабочему процессу:
    • git добавить .
    • git commit -m «Сообщение, описывающее, что вы сделали, чтобы сделать этот снимок другим»
  • Команды, связанные с проверкой состояния или истории журнала
    • статус git
    • журнал git

Основной синтаксис Git: программа | действие | пункт назначения .

Например,

  • git добавить . читается как git | добавить | . , где точка обозначает все содержимое текущего каталога;
  • git commit -m "сообщение" читается как git | зафиксировать -м | "сообщение" ; и
  • статус git читается как git | статус | (без пункта назначения) .

Лучшие практики Git

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

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

Атомарная фиксация — это фиксация, включающая изменения, относящиеся только к одной функции или задаче вашей программы. Для этого есть две основные причины: во-первых, если что-то, что вы меняете, вызывает некоторые проблемы, это легко отменить, не теряя других изменений; и, во-вторых, это позволяет вам лучше писать сообщения коммитов. В следующем уроке вы узнаете больше о том, как выглядит хорошее сообщение коммита!

Изменение редактора сообщений Git Commit

Если вы используете Visual Studio Code (и вы должны им пользоваться, если вы следуете этой учебной программе) и вы не хотите застрять в написании сообщения фиксации в Vim, потому что вы случайно использовали git commit без флага сообщения ( -m ), эта команда заставит Visual Studio Code открыть новую вкладку с возможностью написать сообщение о фиксации и необязательное описание под ним: git config --global core.editor "code --wait" .

После ввода этой команды на терминал не будет ни подтверждения, ни вывода. Чтобы выполнить фиксацию с помощью Visual Studio Code в качестве текстового редактора, обязательно используйте команду git commit без флага -m . Просто введите git commit и никаких сообщений после этого. Как только вы это сделаете, откроется новая вкладка. Теперь вы можете написать свое сообщение и предоставить дополнительную информацию, если хотите, прямо под ним. После ввода сообщения фиксации сохраните его и выйдите из вкладки.

После этого вы можете использовать либо git commit -m <ваше сообщение здесь> , либо git commit и ввести свое сообщение с помощью Visual Studio Code!

Заключение

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

Главное, что нужно усвоить из этого урока, это базовый рабочий процесс . Команды, которые вы здесь изучили, — это те, которые вы будете использовать чаще всего с Git.

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

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

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

Проверка знаний

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

  • Как создать новый репозиторий на GitHub?
  • Как скопировать репозиторий на локальный компьютер из GitHub?
  • Какое имя по умолчанию для удаленного подключения?
  • Объясните, что происхождение находится в git push origin main .
  • Объясните, что такое main в git push origin main .
  • Объясните двухэтапную систему, которую Git использует для сохранения файлов.
  • Как проверить состояние текущего репозитория?
  • Как добавить файлы в промежуточную область в git?
  • Как зафиксировать файлы в промежуточной области и добавить описательное сообщение?
  • Как вы отправляете свои изменения в свой репозиторий на GitHub?
  • Как вы смотрите на историю своих предыдущих коммитов?

Дополнительные ресурсы

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

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

Hello World — GitHub Docs

Введение

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

В этом руководстве вы узнаете об основах GitHub, таких как репозитории, ветки, коммиты и запросы на вытягивание. Вы создадите свой собственный репозиторий Hello World и изучите рабочий процесс запросов на вытягивание GitHub — популярный способ создания и проверки кода.

В этом кратком руководстве вы:

  • Создайте и используйте репозиторий
  • Запуск и управление новой веткой
  • Внесите изменения в файл и отправьте их на GitHub после фиксации
  • Открыть и объединить запрос на вытягивание

Для выполнения этого руководства вам потребуется учетная запись GitHub и доступ в Интернет. Вам не нужно знать, как программировать, использовать командную строку или устанавливать Git (программное обеспечение для контроля версий, на котором построен GitHub). Если у вас есть вопросы по поводу каких-либо выражений, используемых в этом руководстве, перейдите к глоссарию, чтобы узнать больше о нашей терминологии.

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

Репозиторий обычно используется для организации одного проекта. Репозитории могут содержать папки и файлы, изображения, видео, электронные таблицы и наборы данных — все, что нужно вашему проекту. Часто репозитории включают в себя README файл, файл с информацией о вашем проекте. Файлы README написаны на простом текстовом языке Markdown. Вы можете использовать эту памятку, чтобы начать работу с синтаксисом Markdown. GitHub позволяет добавить файл README одновременно с созданием нового репозитория. GitHub также предлагает другие распространенные варианты, такие как файл лицензии, но сейчас вам не нужно выбирать ни один из них.

Репозиторий hello-world может быть местом, где вы храните идеи, ресурсы или даже делитесь ими и обсуждаете их с другими.

  1. В правом верхнем углу любой страницы используйте раскрывающееся меню и выберите Новый репозиторий .

  2. В поле Имя репозитория введите hello-world .

  3. В поле Описание введите краткое описание.

  4. Выберите Добавьте файл README .

  5. Выберите, будет ли ваш репозиторий общедоступным или частным .

  6. Нажмите Создать репозиторий .

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

Ветвление позволяет одновременно иметь разные версии репозитория.

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

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

На этой схеме показаны:

  • Основная ветвь
  • Новая ветвь под названием функция
  • Путешествие, которое включает в себя дублирует до объединения с основным

Вы когда-нибудь сохраняли разные версии файла? Что-то вроде:

  • story.txt
  • история-edit.txt
  • история-редактирование-обзор.txt

Филиалы выполняют аналогичные задачи в репозиториях GitHub.

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

Создайте ветку

  1. Щелкните вкладку Code вашего репозитория hello-world .
  2. Щелкните раскрывающийся список в верхней части списка файлов с надписью main .
  3. Введите имя ветки readme-edits в текстовое поле.
  4. Нажмите Создать ветку: readme-edits from main .

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

Внесение и фиксация изменений

Когда вы создали новую ветку на предыдущем шаге, GitHub вывел вас на кодовую страницу для вашей новой ветки readme-edits , которая является копией main .

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

  1. В созданной вами ветке readme-edits щелкните файл README.md .

  2. Нажмите, чтобы отредактировать файл.

  3. В редакторе напишите немного о себе. Попробуйте использовать разные элементы Markdown.

  4. В поле Подтвердить изменения напишите сообщение фиксации, описывающее ваши изменения.

  5. Щелкните Зафиксировать изменения .

Эти изменения будут внесены только в файл README в вашей ветке readme-edits , так что теперь эта ветка содержит содержимое, отличное от main .

Открытие запроса на включение

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

Запросы на включение — основа совместной работы на GitHub. Когда вы открываете запрос на вытягивание, вы предлагаете свои изменения и просите, чтобы кто-то проверил и вытащил ваш вклад и объединил их со своей веткой. Запросы на вытягивание показывают различия или различия контента из обеих ветвей. Изменения, добавления и вычитания показаны разными цветами.

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

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

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

  1. Перейдите на вкладку Запросы на вытягивание вашего репозитория hello-world .

  2. Нажмите Новый запрос на вытягивание

  3. В поле Example Comparisons выберите созданную вами ветвь readme-edits для сравнения с main (оригиналом).

  4. Просмотрите свои изменения в различиях на странице сравнения, убедитесь, что они соответствуют вашим требованиям.

  5. Нажмите Создайте запрос на вытягивание .

  6. Назовите запрос на вытягивание и напишите краткое описание ваших изменений. Вы можете включать смайлики и перетаскивать изображения и гифки.

  7. При желании справа от названия и описания нажмите рядом с Рецензенты . Уполномоченные , Ярлыки , Проекты или Веха , чтобы добавить любую из этих опций в ваш запрос на вытягивание. Вам пока не нужно ничего добавлять, но эти варианты предлагают разные способы совместной работы с помощью запросов на вытягивание. Дополнительные сведения см. в разделе «О запросах на вытягивание».

  8. Нажмите Создайте запрос на вытягивание .

Теперь ваши соавторы могут просматривать ваши правки и вносить предложения.

Слияние вашего запроса на вытягивание

На этом последнем шаге вы объедините свою ветку readme-edits с основной веткой . После слияния запроса на вытягивание изменения в ветке readme-edits будут включены в main .

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

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

  1. Нажмите Merge pull request , чтобы объединить изменения в основной .
  2. Щелкните Подтвердить объединение . Вы получите сообщение о том, что запрос был успешно объединен и запрос закрыт.
  3. Нажмите Удалить ветку . Теперь, когда ваш запрос на извлечение объединен, а ваши изменения находятся на main , вы можете безопасно удалить ветку readme-edits . Если вы хотите внести дополнительные изменения в свой проект, вы всегда можете создать новую ветку и повторить этот процесс.

Следующие шаги

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

Вот что вы сделали в этом руководстве:

  • Создали репозиторий с открытым исходным кодом
  • Запуск и управление новой веткой
  • Изменил файл и зафиксировал эти изменения на GitHub
  • Открытие и слияние запроса на вытягивание

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

No related posts.