wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Гитхаб что это такое: GitHub: The Largest and Most Advanced Open Source Development Platform — Secure Public & Private Repositories — Code Review — Codespaces — Actions — CI CD — Project Management

alexxlab
No Comments

Содержание

Как начать работать с GitHub: быстрый старт / Хабр

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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


Итак, сайт github.com позиционируется как веб-сервис хостинга проектов с использованием системы контроля версий git, а также как социальная сеть для разработчиков. Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое. GitHub на данный момент является самым популярным сервисом такого рода, обогнав Sourceforge и Google Code.

Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план:

Начнем с регистрации. Идем по ссылке github.com/signup/free и вводим свои данные.

После регистрации мы попадаем на Dashboard нашего аккаунта:

Сейчас у нас нет ни одного репозитория, и мы можем либо создать новый репозиторий, либо ответвиться (fork) от уже существующего чужого репозитория и вести собственную ветку разработки. Затем, при желании, свои изменения можно предложить автору исходного репозитория (Pull request).

Но для начала установим git и настроим его для работы с сайтом.

Если вы работаете в Windows, качаем и устанавливаем msysgit. Это консольная версия git для Windows (далее расказ будет вестись на примере этой ОС).
Инструкция для MacOS X (eng)
Инструкция для Linux (eng)

Проблем возникнуть не должно, просто везде жмем Next. После установки выбираем в контекстном меню Проводника Git Bash:

или через Git Bash.lnk в папке с установленой программой:

Прописываем в консоли свои данные и настройки переносов строк:
git config --global user.name "ваше имя"

git config --global user.email "ваша почта"

git config --global core.autocrlf true

git config --global core.safecrlf true

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

Для тех, кто предпочитает gui — для Windows существует несколько таких инструментов для работы с git. Два основных — это SmartGit (кроссплатформенный) и TortoiseGit. Оба неплохие, и какой использовать — дело вкуса. Я опишу работу с TortoiseGit.

Для маков выбор giu тоже имеется.

  • официальный клиент от GitHub — на мой взгляд пока достаточно сыроват.

  • GitX — лично мне не приглянулся

  • GitBox — наиболее следует mac-way, очень рекомендую попробовать именно его

Качаем по ссылке code.google.com/p/tortoisegit/downloads/list. При установке везде жмем Next.

Теперь возвращаемся к github и создадим новый репозиторий. Находясь на Dashboard, жмем New Repository (https://github.com/repositories/new), вводим данные и жмем Create Repository.

GitHub позволяет работать с репозиториями тремя способами: SSH, HTTP и Git Read-Only, соответственно предоставляя ссылки трех видов для нашего репозитория:
1. [email protected]:habrauser/Hello-world.git

2. [email protected]/habrauser/Hello-world.git

3. git://github.com/habrauser/Hello-world.git

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

Если же мы захотим внести изменения в репозиторий на github, нужно пользоваться HTTP или SSH.

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

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

Для генерации ключей, можно воспользоваться инструментом ssh-keygen, который идет в комплекте с git (описание этого способа можно почитать тут). Мы же будем использовать PuTTY (а точнее небольшую программку puttygen, входящую в его состав). PuTTY — это такой клиент для удаленного доступа, в том числе и с использованием SSH.

Качаем последнюю версию с официального сайта (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Кстати, puttygen более старой версии (2007 год) идет в составе TortoiseGit.

После установки PuTTY, запускаем puttygen из папки с установленной программой:

Жмем Generate, двигаем некоторое время курсором мыши, для получения случайных данных, необходимых алгоритму

Вводим пароль, защищающий наш приватный ключ в поле Key passphrase, вводим подтверждение, жмем Save private key, сохраняем.

Далее копируем публичный ключ в формате OpenSSH из текстовой области «Public key for pasting…» и идем в настройки нашего аккаунта на github (Account Settings) в раздел SSH Public Keys:

жмем Add another public Key, вставляем наш публичный ключ:

нажимаем Add key. Все, теперь мы готовы работать с github по ssh. Попробуем забрать наш пустой рерозиторий на локальную машину с использованием TortioшseGit. В контекстном меню проводника выбираем Git Clone…

В поле Url вставляем SSH-адрес нашего репозитория, в поле Load Putty Key указываем путь к нашему приватному ключу, жмем OK.

Pageant запросит у наc пароль для приватного ключа (потом этого делать не потребуется)

Pageant — это агент SSH-аутентификации в составе PuTTY, он позволяет управлять закрытыми ключами.

В трее висит его значек:

Репозиторий успешно склонирован на локальную машину

Теперь попробуем изменить локальный репозиторий и отправить изменения на github. Добавим в локальный репозиторий файл README (файл с именем README обрабатывается github специальным образом — его содержимое будет отображаться в качестве описания репозитория на соответствующей странице)

Закоммитим изменения в локальный репозиторий

и синхронизируем его с репозиторием на github:

нажимаем Push

Теперь зайдя на страницу нашего репозитория мы увидим следующее:

Для каждого репозитория сайт предлагает wiki:

а также простую систему issue tracking-a:

кстати, для тех, кто использует в работе Eclipсe — есть соответствующий mylyn-коннектор для github:

и плагин EGit:

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

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

Полезные ссылки

Для работы с git:
code.google.com/p/msysgit git для windows
www.syntevo.com/smartgit/index.html SmartGit
code.google.com/p/tortoisegit TortoiseGit
http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY

Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» — перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
los-t.livejournal.com/tag/git%20guts цикл постов «внутренности git»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks Линус Торвальдс о git
habrahabr.ru/blogs/Git/80909 книга «Волшебство git»

Про git на английском:

книги

видео
другое

Git и командная разработка (для чайников) / Хабр

Соавтор статьи: RicardoMilos

Введение

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

GIT

Наверняка вам знакома такая ситуация:

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

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

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

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

И тут мы можем провести аналогию с играми. Почти во всех ААА проектах есть система сохранений. Как наглядный пример можно привести игру Papers Please.

Примерно также и работают все системы контроля версий.

Version Control System (VCS) — система, записывающая изменения файла или набора файлов в течение большого периода времени, так чтобы была возможность позже вернуться к определенной версии.

Классификация СКВ:

  1. Локальные

  2. Централизованные

  3. Распределенные

С локальными СКВ мы уже разобрались (это те самые кучи одинаковых файлов)

Централизованные СКВ

  • центральный сервер

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

  • ряд клиентов

    получают копии файлов

Примеры:

Распределенные СКВ

  1. Клиенты полностью копируют весь репозиторий

  2. Центральный сервер отвечает за предоставление основной копии

  3. Синхронизация может быть
    • С сервером

    • С любым клиентом

Примеры:

Зачем нужна СКВ

  1. Хранение всех изменений проекта

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

  3. Возможность вести одновременную командную разработку

  4. Возможность решать проблемы, подобные следующей

GIT

Git — распределённая система контроля версий
Автор: Линус Торвальдс
2005 — первая версия

Установка:

Linux: sudo apt install git

Windows/macOS: ссылка

Используют разработчики:

  • GNU/Linux

  • Android

  • Wine

  • Google

  • Chromium

  • jQuery

  • PHP

  • MediaWiki

  • Qt

Базовые понятия

Репозиторий (repository, repo) — место, где СКВ хранит свои метаданные и базу данных объектов проекта
Рабочий каталог (working directory) — извлечённая из репозитория копия определённой версии проекта
Область подготовленных файлов (staged area) — служебный файл, содержащий информацию о том, что должно войти в следующую ревизию проекта
Ревизия (revision) — объект, хранящий изменение состояния проекта (версия проекта)
Коммит (commit) — создание новой ревизии

Настройка конфигурации GIT

Настройка имени пользователя

git config --global user.name "Your Name" 
git config --global user.email [email protected]

Настройки сохраняются в скрытый файл .gitconfig (в домашней директории пользователя)

[user] 
name = John Doe 
email = [email protected]

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

mkdir first_git_repo 
cd first_git_repo 
git init

Состояния файлов проекта

  1. Зафиксированный

    файл уже есть в репозитории

  2. Измененный

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

  3. Подготовленный

    измененный файл, который станет зафиксированным после создания новой ревизии (этот файл попадет в эту ревизию)

Работа с кодом

  1. Изменение в коде проекте: создание / удаление / редактирование файлов

    В любой IDE

  2. Просмотр состояния
    git status

  3. Добавление измененных файлов в индекс

    (перевод в состояние Staged)
    git add имена_файлов_через_пробел

  4. Создание ревизии (из Staged в Repo)
    git commit -m "Комментарий"

Суммируем

Работа с СКВ

Что хранить?

[+] Все файлы исходного кода

[+] Все ресурсы, необходимые для компиляции

[+] настройки компиляции проекта

[-] настройки проекта в IDE

[-] файлы, компилируемые из исходников

[-] исполняемые файлы

Удаление из индекса

git rm имя_файла

Коммит может содержать изменения нескольких файлов

Когда делать коммит?

  • Когда завершил маленьшую задачку

  • Если задачка большая — делим на логические подчасти

  • Код должен быть в рабочем состоянии!

Просмотр истории

git log
git log --graph

Номер ревизии = SHA-1 хэш изменений

Переключение на ревизию

git checkout sha1_hash 
git checkout первые_8_цифр_sha1

Ветки

Ветка (англ. branch) — это последовательность коммитов, в которой ведётся параллельная разработка какого-либо функционала

Основная ветка – master

Ветки в GIT

Показать все ветки, существующие в репозитарии

git branch

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

git branch имя

Переключиться на ветку

git checkout имя
На этот момент не должно быть несохранённых изменений

Создать ветку и переключиться на неё

git checkout -b имя

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

Объединение веток (англ. merge) — процесс интеграции изменений (коммитов) одной ветки в другую:

b1 — ветка, в которую мы добавляем изменения

b2 — ветка из которой мы добавляем изменения

git checkout b1 
git merge b2

Просмотр истории

Оконные утилиты:

Удаление веток

Удалить ветку

git branch –d имя_ветки

УДАЛИТЬ ветку

git branch –D имя_ветки

А точнее, удалить ветку, не дожидаясь перемещения коммитов в master

Буфер несохраненных изменений

Или «что делать, если нужно переключиться на другую ветку, а коммит делать рано?»

Записать изменения во временный буфер

git stash

Извлечь из буфера эти изменения

git stash pop

Полезные ссылки:

git-scm.com/book/ru/v2
githowto.com/ru
ru.wikipedia.org/wiki/Система_управления_версиями

Командная разработка

Итак, если ты добрался до этой строчки, то значит ты хотя бы чуть-чуть разобрался с git’ом (очень на это надеюсь). Но что же насчет командной разработки? Давай рассмотрим этот вопрос поподробнее.

Небольшая юмористическая задачка:

Дано:

  • N разработчиков

  • Рабочие места

  • Техническое задание (ТЗ)

  • Интернет

Вопрос:

  • Как выполнить проект не привлекая внимание санитаров?

Ответ:

  • Слаженная команда и упорный труд

Хм, а что же такое вообще команда? Что она из себя представляет?

Команда – это небольшое количество людей:

  • с взаимодополняющими умениями (кто-то программирует, кто-то занимается дизайном и т.д.)

  • стремящимся к общим целям (им всем нужно выполнить задачу заказчика, чтобы получить полное самоудовлетворение)

  • разделяющих ответственность за достижение цели проекта (если вдруг у кого-то из участников команды возникает трудность с его личным ТЗ, то его напарники всегда придут ему на помощь (этим не стоит злоупотреблять, иначе вы просто окажетесь ненужным для команды)).

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

Так-с, теперь тебе понятно, что такое команда. Но следующий вопрос, который возникает в твоей голове (да, да, авторы данной статьи умеют читать мысли): «А кто за что отвечает в команде? У каждого «есть свое место»? Или все делают, что захотят?».

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

  1. Team Leader:

    Team Leader — это нечто среднее между проектным менеджером и квалифицированным девелопером.

    На проектах есть две lead роли: менеджерская — PM, и техническая — System Architect. Тимлид отчасти выполняет обе роли, но акцент его обязанностей направлен на менеджмент (акцент на техническую часть — это tech lead).

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

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

    Под техническую роль: участие в написании технической документации, выбор технологий для проекта, разработка архитектуры, R&D, code review, менторинг джуниоров, проведение технических собеседований, грамотное вовлечение новых членов команды в рабочий процесс, ответственность за техническую часть проекта.

    Типичный рабочий день тимлида включает в себя:

    • рассмотрение новых задач и их распределение

    • стендап с командой

    • митинги

    • программирование

    • архитектурные вопросы

    • code review

  2. Project manager:

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

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

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

    «Главная постановка задачи для PM’а: „Нам нужно, чтобы это работало“, что подразумевает, что команда предоставит результат в разумные сроки с разумным уровнем качества».

  3. Тестировщик:

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

    Главные должностные обязанности тестировщика:

    • Контроль качества разрабатываемых продуктов.

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

    • Разработка автотестов и их регулярный прогон.

    • Разработка сценариев тестирования.

    • Документирование найденных дефектов.

  4. Разработчики:
    • Junior:

      Junior – разработчик начального уровня.

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

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

    • Middle:

      Middle – разработчик среднего уровня.

      Основное требование к мидл-разработчику — способность самостоятельно выполнять поставленные перед ним задачи. Очень похоже на то, что было написано в предыдущем пункте, правда? Однако есть важный нюанс — здесь отсутствует слово «технические». То есть на новом уровне нужно понимать требования бизнеса и уметь переводить их в технические решения.

      Таким образом:

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

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

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

    • Senior:

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

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

  5. Дизайнер:

    Дизайнер – тот человек, который занимается дизайном. Логично, не правда ли?

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

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

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

    • Понимание проблемы:

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

    • Поиск решения:

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

    • Оформление:

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

    • Согласование:

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

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

Заключение

Чтож, если ты дочитал до этого момента – поздравляю, ты нереально крут! Нет, ну правда, у тебя мозг еще не вскипел от такого количества информации? Надеюсь, что нет.

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

Спасибо за внимание!

P.S.

Статья подготовлена учениками МШП (Московская школа программистов), по материалам лекций курса «Промышленное Программирование».

Git и Github. Простые рецепты / Хабр

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

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

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

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

Создание локального репозитория

Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.

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

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

Переходим в папку с проектом /home/user/project:

cd /home/user/project

И показываем список файлов с расширением .pyc:

find . -name *.pyc

Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:

find . -name *.pyc -delete

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

Создадим локальный репозиторий в папке с проектом:

git init

После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.

Добавление файлов в локальный репозиторий

Для добавления файлов используется команда:

git add readme

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

9f2422325cef705b7682418d05a538d891bad5c8

Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:

.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8

Что легко увидеть с помощью команды:

ls .git/objects

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

git cat-file -p 9f2422325cef705b7682418d05a538d891bad5c8

Для того, чтобы добавить все файлы из текущей директории введите:

git add .

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

git add --all

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

Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.

После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).

Для просмотра текущего состояния можно воспользоваться командой:

git status

После выполнения команды мы увидим, что в stage area находится наш файл:

new file:   readme

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

new file:   readme

modified:   readme

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

git add readme

Можно отменить добавления файла readme в staging area с помощью команды:

git rm --cached readme

После выполнения команды, файл readme отметится, как неизмененный системой.

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

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

git commit -m "comment"

Каждая новая версия сопровождается комментарием.

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

.git/objects/9f/2422325cef705b7682418d05a538d891bad5c8
.git/objects/65/7ab4c07bd3914c7d66e4cb48fe57f5c3aa7026
.git/objects/da/c6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3

Посмотрим, что внутри:

git cat-file -t 657ab4c07bd3914c7d66e4cb48fe57f5c3aa7026

Ключ -t показывает тип объекта. В результате мы видим:

commit

Для второго объекта:

git cat-file -t dac6721c3b75fcb3c9d87b18ba4cef2e15e0a3d3

Результат:

tree

Для самого первого файла:

git cat-file -t 9f2422325cef705b7682418d05a538d891bad5c8

Мы видим:

blob

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

Самую первую версию отменить нельзя. Ее можно только исправить. Если вы хотите добавить изменения в последнюю версию, то после выполнения команды commit, добавляете необходимые изменения и вызываете:

git commit -m "comment" --amend

Или так:

git commit --amend --no-edit

Ключ —no-edit нужен, чтобы не вводить заново комментарий.

Можно просмотреть изменения, которые вы внесли последним коммитом:

git show

Или так:

git show --name-only

Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.

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

git commit -a -m "comment"

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

git log

Или так:

git log --oneline

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

2b82e80 update
657ab4c first

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

git show 657ab4c

Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:

git reset HEAD~1

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

git clean -df

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

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

После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.

В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.

Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).

git remote add origin [email protected]:myuser/project.git

Можем просмотреть результат добавления с помощью команды:

git remote -v

Если все было правильно сделано, то увидим:

origin [email protected]:myuser/project.git (fetch)
origin [email protected]:myuser/project.git (push)

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

git remote rm origin

Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.

git remote add github https://github.com/myuser/project.git

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

git push -u github master

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

git push

Перенос репозитория на другой компьютер

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

git clone https://github.com/myuser/project.git

Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).

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

git clone https://github.com/myuser/project.git <myfolder>

Работа с одним репозиторием с разных компьютеров

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

Для получения обновлений с удаленного репозитория воспользуйтесь командой:

git pull

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

git fetch --all
git reset --hard github/master

Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.

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

git push

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

git push -f

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

git stash

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

git stash pop

Заключение

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

Что такое GitHub? Что такое Git? И как использовать эти инструменты разработчика.

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

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

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

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

Контроль версий — это возможность сохранить свое место в документе или папке и сослаться на предыдущие сохранения.

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

Что такое Git?

Git — это система контроля версий, разработанная Линусом Торвальдсом в 2005 году (тот же парень, который писал для Linux). Git помогает разработчикам отслеживать состояние своего кода и позволяет совместно работать над базой кода. Мы рассмотрим основные компоненты чуть позже.

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

Использование Git

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

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

Давайте рассмотрим эту программу в JavaScript. Она выводит на консоль три строки (вывод, который вы можете увидеть в своем браузере или терминале):

console.log('Hello, this is a git example!')
console.log('And here is another!')
console.log('And yet a third')

git init

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

git add

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

git commit

Далее я наберу git commit -am "Initial commit". git commit — это команда для сохранения версии нашего кода. -am является «флагом» и сигнализирует о том, что существуют необязательные действия, которые мы хотели бы предпринять с этим поручением. Флаг a означает, что мы собираемся сохранить все наши изменения. Флаг m обозначает, что мы предоставим сообщение позже, то есть "Initial commit".  

Как Git сохраняет изменения

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

console.log('Now I have changed the first line.')
console.log('And here is another!')
console.log('And yet a third')

git diff

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

Немного сложно понять, что здесь происходит, но есть удаления - и вставки +. Мы удалили текст «‘Hello, this is a git example!» и добавили текст «Now I have changed the first line.» Вот как Git отслеживает, что изменилось между версиями.  

diff --git a/git.js b/git.js
index eb0f1d1..8dbf769 100644
--- a/git.js
+++ b/git.js
@@ -1,3 +1,3 @@
+console.log('Now I have changed the first line.')
-console.log('Hello, this is a git example!')
 console.log('And here is another!')
 console.log('And yet a third')

Теперь, когда мы рассмотрели изменения, которые мы фиксируем, мы можем пойти дальше и сделать вторую фиксацию: git commit-am 'Update first console log'. Это позволит сохранить изменения, которые я внес в первую строку текста.

git log

Мы можем просмотреть коммиты, которые мы сделали с командой git log. Если я сейчас запущу его в своей программе, то получу такой вывод:

commit 67627dd44e84a3106a18a19e94cf9f3723e59b3c (HEAD -> master)
Author: amberwilkie <[email protected]>
Date:   Wed Apr 22 16:55:39 2020 -0400

    Update first console log

commit 49fe4152f474a9674a83e2b014a08828209d2690
Author: amberwilkie <[email protected]>
Date:   Wed Apr 22 16:54:59 2020 -0400

    Initial commit

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

Git Checkout

Если мы хотим вернуться и посмотреть изменения в нашем коде по сравнению с предыдущим коммитом, мы сделаем это с git checkout 49fe4152f474a9674a83e2b014a08828209d2690. Git переведет наш код во временное состояние, чтобы мы могли посмотреть, как он выглядит на snapshot.

Я скопировал идентификатор для моего первого коммита. Если я запускаю эту команду, моя программа говорит: «Hello, this is a git example!» на первой линии.

Чтобы вернуться к последнему коду, вы наберете git checkout master.  

Ветви

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

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

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

На диаграмме ниже точки представляют собой коммиты. Две ветви были сделаны «вне» мастера. При разработке программного обеспечения мы часто называем эти ветви» функциональными», в отличие от основной ветви. Синяя ветвь была объединена обратно с мастер, а желтая ветвь все еще развивается.

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

Визуализация ветвления Git

git merge

git merge возьмет все коммиты, которые вы сделали в этой ветке, и вставит их в ветку master, сохраняя вашу работу.  

Зачем использовать ветки?

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

Утилита ветвления становится не очень понятной, пока мы не начнем думать о работе в команде разработчиков. Если бы каждый из них вносил свой вклад в ветку master каждый раз, когда вносил изменения, все очень быстро становилось бы беспорядочным. Также было бы трудно контролировать, какой код идет «в производство» (в прямом эфире для клиентов), а какой код все еще тестируется или работает.  

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

Что такое GitHub?

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

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

Загрузка вашего кода на GitHub

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

Как только вы войдете, найдите в верхнем углу +. Нажмите «New Repository» (название для папок Git, для краткости «repo»). Дайте ему имя — вероятно, то же самое, что и папка, которую вы создали ранее, где вы сохранили свои коммиты. Затем нажмите «Create Repository». Теперь вы можете скопировать URL-адрес, на который вы перенаправлены и можете указать источник нашего кода.

В какой-то момент здесь будет шаг аутентификации — просто следуйте инструкциям. Git очень хорошо дает нам четкие инструкции о следующих шагах.

git remote add origin

Теперь мы сообщим нашей кодовой базе (папке, где находится наш код), где хранить наш код в облаке. Мы введем git remote add origin <your-url>, который установит для нашего хранилища origin. Теперь мы можем перейти к нашему источнику, чтобы сохранить наше облако в GitHub.

git push

Предполагая, что мы все еще находимся в нашей ветке master (то есть мы не извлекли другую ветку), теперь мы можем напечатать git push и наш код перейдет в GitHub.  

Просмотр вашего кода

Теперь ваш код живет в GitHub! Вот как выглядит мой приведенный выше пример:

Репозиторий GitHub для примера git в этой статье

Вы можете просматривать файлы и папки своего хранилища, просматривая текущее состояние кода. Вы также можете просмотреть предыдущие версии кода, нажав «X commits» справа, посередине. Вы увидите список коммитов, сделанных в репо, и если вы нажмете на них, вы можете просмотреть файлы вашего проекта, как они существовали в тот момент времени.

Pull Requests

Есть много других функций GitHub, но наиболее важным в сотрудничестве с коллегами является запрос на извлечение. Pull Requests (очень часто сокращенный до PR) — это способ управлять входящими изменениями в кодовую базу.

Чтобы сделать его, вы создадите новую ветвь на своем локальном компьютере, создадите по крайней мере одну фиксацию на этой ветви, а затем git push origin head отправит эту ветвь на GitHub. (Вы можете поставить название своей ветви вместо head, но это полезно для того, чтобы все было точно согласовано).

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

GitHub автоматически предложит вам создать PR из новых веток

Если вы нажмете кнопку «Compare & pull request», вы сможете изменить многие настройки для вашего PR. Наиболее важными являются, как правило, заголовок и описание. Если вы работаете в команде, вы можете пометить для коллег ваш код с просьбой просмотреть его и добавить в проекты многие другие функции, которые вам, вероятно, пока не нужны.

Создание Pull Requests на GitHub

Обратите внимание, что мы сравниваем ветви. Здесь мы просим добавить изменения из этой ветви (pr-example) в ветку master. Но мы можем нацелиться на любую из других веток в нашем репо. На данный момент, просто поймите, что master это не единственная ветка, против которой вы можете «make a pull request against».  

Когда вы нажмете «Create Pull Request», вы увидите этот экран:

Пример Create Pull Request

Вы можете увидеть все коммиты в этой ветке (у меня есть только один — «Change third line of program»), а также вы можете объединить ваш Pull Request.

Помните, как мы могли объединить наш код локально, когда мы говорили о Git? Мы можем выполнить то же действие с нашим облачным кодом на GitHub. Если вы нажмете зеленую кнопку «Merge pull request», ваши изменения будут объединены в master.

git pull

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

Если вы проверите ветку master, то изменения git pull origin master, которые вы только что объединили, теперь будут на вашем локальном компьютере.  

➜  git-example git:(master) git pull origin master
From https://github.com/AmberWilkie/git-example
 * branch            master     -> FETCH_HEAD
Updating 67627dd..38ad2da
Fast-forward
 git.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Эта «Fast-forward» относится к нашей локальной главной ветви, «догоняющей» ветвь origin на GitHub. Мы завершили круг:

  • Локальные изменения
  • Нажмите на GitHub и сделайте PR
  • Объединить PR в мастер
  • Перетащите мастер на локальный компьютер

Когда вы освоитесь с этими шагами, вы будете на 80% пути к освоению Git и GitHub!

Как пользоваться GitHub и зачем заливать туда IT-проекты? ⋆

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

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

Что же такое GitHub?

GitHub – это один из самых популярных сайтов, которым пользуются программисты во всем мире. Новичку важно понимать, что GitHub – это сайт для хранилища данных (хостинг), а Git – это система контроля версий, которая позволяет вам следить за всеми изменениями в файле.

Это талисман сайта GitHub

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

Как пользоваться GitHub: алгоритм действий

Научимся работать с этим сайтом прямо сейчас! Для этого воспользуемся небольшим планом.

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

2. После подтверждения данных вам предложат создать репозиторий (место, для хранения вашего проекта). Создание репозитория — один из самых важных этапов работы с GitHub, так как это — лицо вашего проекта.

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

Пример создания репозитория на сайте GitHub

3. Понять, как пользоваться GitHub, невозможно без применения командной строки (консоли). Для работы с консолью в Windows нужно скачать и установить небольшое дополнение.

4. Откройте консоль. Для перехода на рабочий стол вписываем строку и нажимаем на Enter:

cd Desktop

5. Затем сделайте копию своего репозитория с сайта:

git clone https://github.com/<Имя профиля>/<Имя репозитория>

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

Уже чувствуете себя хакером, готовым взломать сайт Пентагона? Ещё рано.

Чувство, когда работаешь с сайтом GitHub

6. Выберите любую картинку и переместите в папку с названием репозитория на рабочем столе. Затем впишите в консоль шесть команд подряд (из левой колонки):

Как пользоваться GitHub: основные консольные команды

7. Обновите вкладку репозитория на сайте GitHub,и вы увидите появшиеся данные (картинку).

Теперь вы уже примерно представляете, как пользоваться GitHub. Было страшно? Надеюсь, что нет. Ведь умение пользоваться данным сайтом — первый шаг на пути становления IT-специалиста и создания крутых командных проектов.

GitHub — что это? — Программирование на C, C# и Java

На сегодняшний день GitHub – это один из самых популярных сервисов для совместной разработки программного обеспечения и его хостинга в облаке. Крупные IT-компании, такие как Microsoft, Google, Facebook и многие другие, используют данный ресурс для размещения исходных кодов своих разработок. Вы наверняка слышали о GitHub – пришло время научиться им пользоваться!

Этой статьёй мы открываем цикл публикаций посвященных GitHub. Итак, если вы не знаете, что это за сервис, то самое время время с ним познакомиться!

Что такое GitHub?

GitHub – это сервис на основе Git. Является удобным и популярным инструментом управления версиями и включает систему отслеживания ошибок. Адрес в Интернете: https://github.com/

Для каждого проекта можно создавать документацию и руководства по принципу wiki.

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

Главная страница ресурса

Сервис заработал в апреле 2008 года, но лишь относительно недавно он приобрёл огромную популярность. Его разработчиками являются Крис Ванстрас, PJ Хиетт и Том Престон-Вернер.

Сервис можно использовать как бесплатно, так и платно. При этом в бесплатном аккаунте доступны абсолютно все функции для работы над проектом. Объем памяти под хостинг – неограничен. Различие в тарифах следующее:

  • Бесплатно – можно создавать только публичные репозитории.
  • Платно (7$ в месяц) – доступны приватные репозитории.

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

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

Публичный репозиторий программы с сайта vscode.ru на GitHub

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

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

Система управления версиями

В основе работы GitHub лежит система управления версиями Git.

Проект Git был создан Линусом Торвальдсом. Первая версия вышла 7 апреля 2005 года.

Логотип Git

Система управления версиями (от английского Version Control System, сокращенно VCS) – это набор инструментов для удобной работы с документами или файлами, которые могут изменится со временем, то есть может поменяться их версия.

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

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

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

Основные термины VCS

Коммиты (commit)

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

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

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

Перво-наперво, Юлия должна выполнить апдейт (update) своего локального репозитория – синхронизироваться с сервером и получить последнюю на данный момент версию ПО. Для этого выполняется соответствующая команда.

Затем Юля занимается разработкой модуля для фильтрации изображении.

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

  1. Выполняется команда коммит (commit). Коммит – это сохранение изменений в проекте. Он обязательно должен сопровождаться текстовым комментарием разработчика о том, какая работа была проделана, и что изменено, либо написано. Коммит поможет другим разработчикам легче разобраться в чужом коде. Кроме того, по коммитам выполняется откат к предыдущей версии проекта, если вдруг что-то было сделано неправильно, либо с фатальными ошибками. Коммит фиксируется в локальном репозитории.
  2. Затем нужно синхронизировать локальный коммит с облаком и запушить (push) все изменения на сервер. Выполняется команда push.

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

Конфликты

Конфликты возникают во время операции push, когда оказывается, что два разработчика работали над одним и тем же кодом. Что и понятно.

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

Ветки (branch)

Рассмотрим создание веток опять же на примере проекта “графический редактор”.

Части команды дано задание начать разработку версии 2.0 графического редактора (например, предполагается поддержка работы с векторными изображениями).

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

В данной ситуации делается следующее: выделяется ветка (бранч, branch). Создание branch – это создание копии текущего репозитория. Дальнейшая разработка в рамках новой ветки никак не будет затрагивать начальную основную ветку проекта (которая называется master).

Разработка в рамках новой ветки идентична разработке основной ветки. Коммиты, push – это всё на месте.

Когда работа завершена, необходимо выполнить слияние (merge) дополнительной ветки с основной. Программная команда так и называется – merge. В результате слияния получится версия программы 2.0, при этом в ней будут содержатся исправления всех недочётов, которые были обнаружены и поправлены в основной ветке проекта.

 

На этом всё! До встречи на vscode.ru!

Из следующих статей на тему работы с GitHub Вы узнаете:

 

GitHub – что это?

5 (100%) 11 votes


Поделиться в соц. сетях:

Первый коммит в Github / Песочница / Хабр

Руководство по созданию первого коммита в свой репозиторий на Github

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

  • Github нужен для взаимодействия между разработчиками при совместной работе над проектами (может использоваться в течении всего жизненного цикла ПО).

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

Основы

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

Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.

GitHub — это сервис для проектов, использующих Git.

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

Репозиторий — каталог файловой системы, в котором могут находится: файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.


Репозиторий бывает:

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

  • удалённый (находится на сервере, может быть приватным – доступным ограниченному числу лиц, и публичным – open source)

В GitHub входит:

  • система контроля доступа

  • багтрекинг (отслеживание истории действий над файлами и, при необходимости, переход на более ранние версии)

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

К проекту, загруженному на GitHub, можно получить доступ с помощью интерфейса командной строки и Git-команд, сайта https://github.com/, или с помощью приложения Github — desktop для Windows или macOS.

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

Установка Git

Для Linux:

1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git

Для macOS:

1. Воспользуемся homebrew
2. Вводим в терминале: brew install git

Для Windows, (для macOS и Linux — альтернатива):

1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.

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

Создание и настройка локального репозитория

1. Открываем Bash

Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.

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

git config --global user.name "Name" git config --global user.email [email protected]

(где Name – логин пользователя, [email protected] — почта)

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

tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.

find – удаление файлов со специфичным суффиксом.

3. Переходим в папку с проектом Users/Public/Project:

cd Users/Public/Project/

4. Создадим локальный репозиторий в папке с проектом:

git init

Командная строка должна вернуть что-то вроде:

Initialized empty Git repository in Users/Public/Project/

Добавление файлов в локальный репозиторий

1. Теперь создадим любой файл в нашей директории, например, first.txt

2. Добавим его в систему управления версиями:

git add first.txt

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

git add –A

или:

git add --all

4. Проверить текущее состояние:

git status

Можно отменить добавление файла командой:

git rm –-cached first.txt

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

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

1. Введем команду:

git commit -m "comment"

Ключ –m означает создание пользователем описания этого коммита.

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

git clean -df

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

Все действия до этого раздела производились над локальным репозиторием, который находится у вас на компьютере. Если мы хотим сохранить проект в Интернете, и предоставить к нему доступ, то создадим репозиторий на Github.

1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).

2. Нажимаем кнопочку «+» и вводим название репозитория.

3. Выбираем тип Public (Private доступен только в платной версии).

4. Нажимаем Create.

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

5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).

git remote add origin [email protected]:nikname/project.git

Результат можно увидеть с помощью команды:

git remote -v

Если все правильно сделано, то увидим:

origin [email protected]:nikname/project.git (fetch)
origin [email protected]:nikname/project.git (push)

Для отмены регистрации удаленного репозитария, введите:

git remote rm origin

Этой командой вносятся все изменения, которые были сделаны в локальном репозитории на Github:

git push -u github master

-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push

Полезные ресурсы

  • Более подробно про Git можно прочитать в книге Скотта Чакона и Бена Штрауба — Pro Git

  • За помощью с работой в Github переходим на сайт.

Что такое GitHub

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

GitHub позволяет вам (и другим) работать вместе над проектами.

Зарегистрируйтесь на GitHub на https://github.com/:

Основы GitHub:

  • Хранилища
  • Филиалы
  • Совершает
  • Запросы на извлечение
  • Git (программа управления версиями GitHub)

Пример

$ git push origin heroku
$ cd / и т.д. /
$

Репозиторий

Репозиторий GitHub можно использовать для хранения проекта разработки .

Может содержать папок и файлы любого типа
(HTML, CSS, JavaScript, документы, данные, изображения).

Репозиторий GitHub также должен включать файл лицензии и файл README о
проект.

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

Филиал

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

По умолчанию репозиторий имеет master ветку (производственная
ветвь).

Любая другая ветка — это копия главной ветки (как это было
в определенный момент времени).

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

Фиксирует

На GitHub изменения называются фиксациями.

Каждая фиксация (изменение) имеет описание, объясняющее, почему было внесено изменение.

Запросы на извлечение

Pull Requests — это основа сотрудничества с GitHub .

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

Pull-запросы показывают контент отличий , изменения, добавления и вычитания в
цветов (зеленый и красный).

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

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

Вы объединяете любые изменения в мастер, нажав кнопку «Объединить запрос на перенос».

После объединения вы можете удалить ветвь, нажав кнопку «Удалить ветку».

.

Глоссарий GitHub — GitHub Docs

Документы GitHub

  • Все продукты

  • GitHub.com

    • Начиная

      • Быстрый старт

        • Настроить Git
        • Создать репо
        • Форк репо
        • Быть социальным
      • Изучение GitHub

        • Продукты GitHub
        • Изучение выпусков раннего доступа с предварительным просмотром функций
        • Типы аккаунтов GitHub
        • Часто задаваемые вопросы об изменениях в планах GitHub
        • GitHub CLI
        • GitHub Desktop
        • GitHub для мобильных устройств
        • Разрешения на доступ на GitHub
        • Глоссарий GitHub
        • Шпаргалка по Git
        • Учебные ресурсы Git и GitHub
      • Регистрация на GitHub

        • Регистрация новой учетной записи GitHub
        • Подтверждение адреса электронной почты

.

Начало работы с GitHub — GitHub Docs

Документы GitHub

  • Все продукты

  • GitHub.com

    • Начиная

      • Быстрый старт

        • Настроить Git
        • Создать репо
        • Форк репо
        • Быть социальным
      • Изучение GitHub

        • Продукты GitHub
        • Изучение выпусков раннего доступа с предварительным просмотром функций
        • Типы аккаунтов GitHub
        • Часто задаваемые вопросы об изменениях в планах GitHub
        • GitHub CLI
        • GitHub Desktop
        • GitHub для мобильных устройств
        • Разрешения на доступ на GitHub
        • Глоссарий GitHub
        • Шпаргалка по Git
        • Учебные ресурсы Git и GitHub
      • Регистрация на GitHub

        • Регистрация новой учетной записи GitHub
        • Подтверждение адреса электронной почты
        • Настройка пробной версии GitHub Enterprise Cloud
        • Настройка пробной версии GitHub Enterprise Server
      • Изучение проектов на GitHub

        • Поиск способов внести свой вклад в открытый исходный код на GitHub
        • Сохранение репозиториев со звездочками

.

Привет, мир · Руководства GitHub

Проект Hello World — это давняя традиция компьютерного программирования. Это простое упражнение, которое поможет вам начать изучение чего-то нового. Приступим к работе с GitHub!

Вы узнаете, как:

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

Что такое GitHub?

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

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

Кодирование не требуется

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

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

Шаг 1. Создание репозитория

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

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

Для создания нового репозитория

  1. В правом верхнем углу рядом с вашим аватаром или идентификатором щелкните и выберите Новый репозиторий .
  2. Назовите свое хранилище hello-world .
  3. Напишите краткое описание.
  4. Выберите Инициализируйте этот репозиторий с помощью README .

Щелкните Создать репозиторий .

Шаг 2. Создайте ответвление

Ветвление — это способ одновременной работы с разными версиями репозитория.

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

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

На этой диаграмме показано:

  • Главный филиал
  • Новая ветка под названием feature (потому что мы выполняем «функциональную работу» над этой веткой)
  • Путь, который проходит функция , прежде чем она будет объединена в основную

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

  • рассказ.txt
  • story-joe-edit.txt
  • Story-Joe-Edit-Review.txt

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

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

Для создания новой ветки

  1. Зайдите в ваш новый репозиторий hello-world .
  2. Щелкните раскрывающийся список в верхней части списка файлов с надписью branch: main .
  3. Введите имя ветки, readme-edits , в текстовое поле новой ветки.
  4. Выберите синее поле Create branch или нажмите «Enter» на клавиатуре.

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

Шаг 3.Внести и зафиксировать изменения

Браво! Теперь вы находитесь в режиме просмотра кода для своей ветки readme-edits , которая является копией main . Внесем некоторые правки.

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

Внести и зафиксировать изменения
  1. Щелкните README.md файл.
  2. Щелкните значок карандаша в правом верхнем углу окна просмотра файла, чтобы отредактировать его.
  3. Напишите немного о себе в редакторе.
  4. Напишите сообщение фиксации, описывающее ваши изменения.
  5. Нажмите Принять изменения кнопку.

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

Шаг 4. Откройте запрос на слияние

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

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

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

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

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

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

Щелкните изображение, чтобы увеличить его

Когда вы закончите с сообщением, нажмите Create pull request !

Совет : вы можете использовать эмодзи и перетаскивать изображения и гифки в комментарии и запросы на вытягивание.

Шаг 5. Объедините Pull Request

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

  1. Нажмите зеленую кнопку Merge pull request , чтобы объединить изменения в main .
  2. Нажмите Подтвердите слияние .
  3. Удалите ветку, так как ее изменения были включены, с помощью кнопки Удалить ветку в фиолетовом поле.

Празднуйте!

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

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

  • Создан репозиторий с открытым кодом
  • Открыл и управлял новым филиалом
  • Изменил файл и зафиксировал эти изменения на GitHub
  • Открыл и объединил Pull Request

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

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

.

No related posts.

Share :

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

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