Git и Github


Содержание материала:

GitHub и Git — создание и работа с репозиторием

August 30, 2014

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

Вот такие получаются шаги, которые нужно осветить. Profit у всех этих сложностей, описанных мною выше, один — но большой! Заключается он в том, что проект, над которым вы работаете (даже в гордом одиночестве) находится на удаленном сервере, к которому можно подключиться из любого места и с любой машины. Так как он находиться на remote server, то с ним ничего не случиться, даже если ваша машина упадет\утонет\разобьется.

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

Все действия, описанные в этой статье, будут производиться под операционной системой Linux Mint 17 Cinnamon, в консоли. Поэтому пользователи Mac OS X найдут для себя почти все идентичным. Система Windows остается в стороне.

Создание SSH-ключей под Linux

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

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

Если показанная выше команда “скажет” вам, что директории не существует, то это означает, что у вас с системе установлен пакет SSH, отвечающий за создание и обработку ssh-ключей.

Установка пакета SSH

Под Linux Mint его нужно установить командой:

Создание пары ssh-ключей

Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:

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

Обязательный параметр — электронный адрес, к которому “привязывается” создаваемый ssh-ключ; данный email будет также использоваться мною для регистрации на GitHub.

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

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

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

После успешного ввода ssh-ключи будут созданы:

В состав пакета входит утилита , задача которой в управлении созданными ssh-ключами. Передадим ей в пользование только созданные мною ssh-ключи:

Можно посмотреть, что утилита “подхватила” и распознала предоставленные ею ssh-ключи:

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

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

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

Добавление ssh-ключа на GitHub

Переходим на сервис GitHub и создаем на нем новую учетную запись. Описывать процесс создания такой записи на GitHub не буду, так как там все просто. Более интересный момент — это добавление ssh-ключа в профиль пользователя GitHub.

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

Откроется окно для добавления новых ssh-ключей в учетную запись пользователя на GitHub. Здесь все элементарно просто — нажимаем кнопку . В поле вводим название (произвольное) для импортируемого ssh-ключа.

В поле просто нажимаем Ctrl+V — содержимое буфера обмена (которое я получил ранее с помощью утилиты ) вставиться в это поле:

Жму на зеленую кнопку внизу окна. Ключ добавлен на GitHub и появиться в списке SSH-ключей:

Проверка SSH-соединения с GitHub

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

Для этой цели ввожу команду:

На ошибку в строке не стоит обращать внимание. В запросе командной строки печатаем и получаем:

Отлично! GitHub “узнал” меня и поприветствовал в строке . Это говорит о том, что ssh-соединение моей машины с GitHub установлено успешно и GitHub авторизует меня.

Однако, при настройке ssh-соединения возможны и ошибки. В этом случае может помочь статья — Error: Permission denied (publickey).

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

Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:

Отлично! На GitHub я только что создал новый репозиторий . Теперь можно скопировать (склонировать) его на свою локальную машину командами:

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

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

Вот, таким образом я наладил Git-работу своей машины с GitHub.

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

GitHub vs GitLab Кто лучше

Ещё вот в Этой статье мы уже разобрали разницу между GitHub и BitBucket. Победителем вышел второй. Но тогда я напомнил о существовании ещё и GitLab’а. Так давайте теперь рассмотрим разницу между GitHub и GitLab.

Как обычно, я бы хотел начать из далека.

Git — это платформа, на которой участники команды разработки могут хранить свой код, в случае если какой-либо или же каждый участник работает удалённо. Так же многие компании используют GIT, для контроля работы сотрудников, кто-то «накосячил» и кто где чего не до выполнил. В случаи не качественно выполненной задачи, последствия которой понесли за собой проблемы на всём проекте, GIT позволяет откатится до более раннего состояния проекта. Так что ни одна организация, команда разработчиков, ну или даже просто программист одиночка не должны пренебрегать Гитом.

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

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

Различия между GitHub и GitLab

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

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

GitLab начал свою работу в 2011 году и насчитывает уже более 1 миллиона активных участников, некоторые даже являются разработчиками из таких крупных компаний как IBM, Sony и NASA. Он имеет большинство функций GitHub, но так же и свои собственные уникальные особенности.

Непрерывная интеграция

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

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

Так что в удобстве работы с интеграциями побеждает GitLab, из-за автоматизированной системы CI.

Разрешение пользователя

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

НО! GitLab предлагает лучшую гибкость и контроль при управлении проектом. А всё потому что он позволяет админу проекта устанавливать более различные настройки для каждого участника. И в этих настройках вы можете найти больше чем просто Чтение и Запись.

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

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

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

Проблемы отслеживания и интеграции

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

По мимо просто отслеживания ошибок, GitHub и GitLab предлагают расширения для автоматических утверждений модификаций. Для этого, они оба используют сторонний трекер Tracker Usersnap. Благодаря ему, тестеры смогут проверить ваш проект и оставить свой отзыв. Менеджер же сможет собрать отзывы, отчёты и сообщения с обратной связи с пользователями, и направить команде разработчиков для решения проблем.

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

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

Импорт и экспорт данных

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

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

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

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

Топ-пост этого месяца:  Адаптивные изображения автоматическое создание

Ценообразование и сообщество

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

Корпоративная оплата в GitHub начинается от 84 долларов за одного пользователя в год, а у GitLab от 39 долларов за участника, так же в год.

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

Вот тут я пожалуй добавлю каждой платформе по баллу. Потому что у GitLab лучше цены. А у GitHub более продвинутое сообщество и он более популярен.

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

Если вам понравилась данная статья, то обязательно подписывайтесь на обновления блога, не забывайте про группу в ВКонтакте, и поставьте ОГОНЬ! под этой статьёй!

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

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

Когда получил непонятное задание.

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

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


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

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

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

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

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

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

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

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

Установка в Linux

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

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

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

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

  1. Скачиваем Git со страницы проекта.
  2. Запускаем загруженный файл.
  3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
  4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
  5. Установщик проведёт через все необходимые шаги.

Установка в Windows

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

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

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

Настройка Git

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

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

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

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

Регистрация на GitHub

Что такое GitHub?

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

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

  1. Переходим на сайт GitHub. Cтартовая страница GitHub.
  2. Есть два варианта начала регистрации:
    • Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей нажимаем Create an account (создать аккаунт).
    • Cразу вводим имя, почту и пароль на главной странице GitHub и нажимаем Sign up for GitHub (зарегистрироваться на GitHub).

    Первый шаг регистрации профиля на стартовой странице GitHub.

  3. На втором этапе нужно выбрать тарифный план. GitHub — бесплатный сервис, но предоставляет некоторые платные возможности. Выбираем тарифный план и продолжаем регистрацию. Выбор тарифа на втором шаге регистрации.
  4. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
  5. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Переход в ваш профиль.

Так выглядит ваш профиль после регистрации.

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

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

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

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

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

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

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

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

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

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

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

/.ssh , чтобы перейти в нужный каталог. Переходим в нужную директорию.

  • Используем ls , чтобы увидеть список всех файлов в каталоге. Открываем список файлов в директории. Ищем пару файлов с названиями вида имя и имя.pub . Обычно имя — id_rsa , id_dsa , id_ecdsa или id_ed25519 . Файл с расширением .pub — ваш публичный ключ, а второй — ваш приватный, секретный ключ. Если таких файлов или даже каталога .ssh у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
    • Открываем консоль и вводим команду: Указываем тот адрес электронной почты, который вводили при регистрации на GitHub. Генерируем ключ.
    • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
    • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите. Указываем расположение ключа и вводим пароль.
  • Добавляем ключ в ssh-agent (сгенерированный или уже существующий). Проверяем доступность ключа командой eval «$(ssh-agent -s)» и добавляем с помощью ssh-add

    /.ssh/your_key_name , где указываем верный путь до файла с ключом и его имя. Добавляем ключ в shh-agent. Несколько важных примечаний:

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

    /.ssh/config связь ключа с доменом.
    Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой eval «$(ssh-agent -s)» . Может появиться такое сообщение об ошибке: «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

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

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

    Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш

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

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

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

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

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

    /.ssh/

  • После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
    • Если вы на Windows clip .
    • Для пользователей macOS pbcopy .
    • На Linux используйте sudo apt-get install xclip , чтобы установить необходимый для копирования пакет xclip , а затем введите xclip -sel clip . Или введите команду cat

      /.ssh/id_rsa.pub , контент документа появится прямо в консоли и вы сможете скопировать ключ оттуда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Работу над проектом принято вести в ветках. В каждом репозитории есть как минимум одна ветка. Это основная ветка, которую создаёт сам Git, она называется master . Обычно в ней находится стабильная версия программы без ошибок. Если вы хотите исправить баг, добавить новую функциональность в проект, попробовать какую-то технологию, но не хотите сломать код в основной ветке, вы ответвляетесь из master и трудитесь в своей новой ветке. Здесь вы можете реализовывать свои идеи, не переживая, что рабочий код сломается. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединяется с основной.

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

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

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

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

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

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

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

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

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

      Теперь мы можем сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды git commit -m «ваше сообщение» . Текст сообщения должен быть лаконичным и в то же время сообщать о том, что делает коммит (внесённые изменения). Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте».

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

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

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

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

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

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

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

      Начинаем работу github

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

      Намедни, недавно решил отвлечься от основной работы и всё таки примкнуть к open source сообществу и написать свой велосипед и заодно разобраться с тем как работать

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

      Нам нужно установить git. Мануал курить отсюда

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

      Потом необходимо создать репозиторий

      После успешного создания репозитория вам выдадут адрес репозитория. Сохраните его.

      Учтите что мы создали пустой репозиторий без файлов.

      Далее заходите в терминал (*nix системы) или в коммандную строку Windows.

      Переходите в директорию где бы вы хотели клонировать наш репозиторий к себе локально.

      А потом выполняйте команду

      и создайте там пустой файл. Мы создадим файл README.md — это файл описания нашего проекта

      И добавим его в отслеживание git`ом введя команду в терминале

      Теперь этот файл у нас будет отслеживатся git`ом и его изменения будут фиксироваться с помощью git`a

      Далее нам нужно наш локальный репозиторий «подружить» с нашим удаленным.

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

      Адрес репозитория, само собой, меняйте на свой.

      Что-бы удостовериться что вы правильно «соединили» локальный репозиторий с удаленным введите команду

      Теперь нам нужно закоммитить (проще говоря — зафиксировать) наши изменения (добавление файла README.md в репозиторий).

      А теперь все изменения нам нужно залить на удаленный репозиторий

      У вас должно запросить логин и пароль к github как на скрине выше (при вводе пароля будет казаться что вы ничего не вводите — но это всё вранье)

      Теперь давайте перейдем в наш репозиторий через браузер и посмотрим — есть ли там наш файл

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

      Спасибо всем кто заинтерисовался.

      Если будет интересно то в следующий раз опишу как сделать так чтобы composer видел ваш githubовский репозиторий.

      P. S. Конструктивная критикая, советы приветствуются

      В чем разница между Git и GitHub?

      Senseich: да svn — аналог гита. хотя и менее функциональный, но со своими плюшками. лично я предпочитаю гит.

      TurtoiseSVN — это аналог гитхаб десктоп, только для svn. то есть — морда над консольным svn.

      Т.е. subversion.exe на оф. сайте это аналог GIT — который GITBush? )

      А TurtoiseGIT — это тоже аналог гитхаб десктоп?

      TurtoiseGIT — это тоже аналог гитхаб десктоп?

      Т.е. subversion.exe на оф. сайте это аналог GIT — который GITBush?

      Та же, что и porn и pornhub 😉

      Первое — название системы, вторая там где все это лежит

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

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

      Сравнение сервисов GitHub и GitLab

      GitHub Есть бесплатный тариф

      Сервис для хостинга кода, хранения IT-проектов и их совместной разработки.

      GitLab Есть бесплатный тариф

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

      Сервис для хостинга кода, хранения IT-проектов и их совместной разработки.

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

      Подробное описание

      GitHub — это «социальная сеть для разработчиков». Участникам, кроме непосредственного хранения кода, своих проектов, можно общаться, комментировать изменения друг друга, отслеживать новости знакомых. У программистов есть возможность объединять репозитории и выводить вклад участника в виде дерева.

      Ключевые особенности GitHub:

      • Совместная работа с управлением большими командами.
      • Графическое представление.
      • Личные страницы проектов.
      • Вики.
      • Система отслеживания ошибок.
      • Просмотр файлов проектов.
      • Подсветка синтаксиса для большинства языков.
      • Приватные репозитории.
      • Прямое добавление новых файлов в репозиторий.
      • Код проектов можно скопировать через Git или скачать.
      • Поддержка получения и редактирования через SVN и Mercurial.
      • Pastebin-сервис gist.github.com для мгновенной публикации фрагментов.
      • Встроенное отслеживание задач и ошибок.
      • Фильтры, назначения и метки у задач.
      • Комментарии, сортировка и время обновления.
      • Сочетания клавиш.
      • Управление вехами.
      • Управление доступом.
      • Markdown-разметка.
      • Добавление изображений.
      • Поддержка SSL, HTTPS и SSH.

      GitLab — это платформа управления Git-репозиториями, анализа кода, отслеживания ошибок, тестирования, деплоя, ведения каналов и вики-страниц.

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

      Ключевые возможности GitLab:

      • Организация публичных и приватных репозиториев.
      • Управление правами, группами.
      • Импорт проектов, в том числе с GitHub.
      • Вики.
      • API.
      • Доска идей и задач.
      • Лейблы, вехи, шаблоны, поиск.
      • Комментирование, объединение.
      • Интеграция с Jenkins CI.
      • Отслеживание изменений и прогресса.
      • Отслеживание времени.

      Записки программиста

      Моя шпаргалка по работе с Git

      28 декабря 2011

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

      В чем состоит отличие Git от Subversion?

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

      Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

      В результате имеем:

      • Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
      • Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
      • Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
      • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
      • Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
      • Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
      • Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
      • Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
      • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
      • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

      Пример использования Git

      Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

      В первую очередь необходимо поставить Git:


      Затем создаем пару ssh ключей, если не создавали ее ранее:

      Разница между Git и GitHub

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

      Почему у них есть одна и та же информация об учетной записи и разные репозитории?

      Разве не Git и GitHub одно и то же?

      Git — это система контроля версий, инструмент для управления историей исходного кода.

      GitHub — это служба хостинга для репозиториев Git.

      Таким образом, это не одно и то же: Git — это инструмент , GitHub — это служба для проектов, которые используют Git.

      Чтобы получить код в GitHub, посмотрите здесь.

      В аналогии SVN Git заменяет SVN, а GitHub заменяет SourceForge: P

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

      У них, похоже, есть что-то для пользователей Eclipse: http://eclipse.github.com/

      В противном случае, если вы новичок в Git: http://git-scm.com/book

      «Git — это бесплатная распределенная система контроля версий с открытым исходным кодом

      предназначенная для быстрой и эффективной работы с небольшими и очень крупными проектами»

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

      : «GitHub — это веб-хостинг Git-хостинга, который предлагает все функции распределенного контроля версий и управления исходным кодом (SCM) в Git, а также добавляет свои собственные функции. «

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

      Вам не нужен GitHub для использования Git.

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

      Github позволяет вам:

      • Поделитесь своими репозиториями с другими.
      • Доступ к другим пользовательским репозиториям.
      • Храните удаленные копии ваших репозиториев (github-серверов) в качестве резервной копии ваших локальных копий.

      Git — Инструмент управления версиями, который GitHub построен поверх.

      GitHub — Наша компания и название нашего программного обеспечения. Мы создаем программное обеспечение и веб-сайты, чтобы помочь вам эффективно взаимодействовать с репозиториями Git.

      GitHub.com — веб-сайт, на который вы входите, чтобы просматривать репозитории в Интернете.

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

      Между Git и GitHub существует ряд очевидных различий.

      Сам Git действительно сосредоточен на основных задачах контроля версий. Он поддерживает историю коммитов, позволяет отменять изменения с помощью команд reset и revert и позволяет делиться кодом с другими разработчиками с помощью команд push и pull. Я думаю, что это основные функции, которые каждый разработчик хочет получить от инструмента DVCS.

      Нет прицела с Git

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

      Дополнительные функции GitHub

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

      • простое отслеживание задач
      • настольное приложение GitHub
      • онлайн редактирование файлов
      • правила защиты веток
      • функции запроса по запросу
      • организационные инструменты
      • пределы взаимодействия для горячих голов
      • поддержка смайликов . octocat:: +1:

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

      Конкуренты Git и GitHub

      Иногда, когда дело доходит до разграничения между Git и GitHub, я думаю, что было бы хорошо посмотреть, с кем они конкурируют. Git конкурирует на одном уровне с такими инструментами, как Mercurial, Subversion и RTC, в то время как GitHub больше выступает в пространстве SaaS, конкурируя с поставщиками облаков, такими как GitLab и Atlassian BitBucket.

      GitHub не требуется

      Я всегда хотел напомнить людям о том, что вам не нужен GitHub, GitLab или BitBucket, чтобы использовать Git. Git был выпущен в 2005 году? GitHub не появлялся на сцене до 2007 или 2008 года, поэтому крупные организации занимались распределенным управлением версиями с помощью Git задолго до появления поставщиков облачного хостинга. Так что с Git все в порядке. Для эффективной работы не требуется облачный хостинг. Но в то же время наличие PaaS-провайдера, безусловно, не повредит.

      Работа с GitHub Desktop

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

      Я не слишком впечатлен этим инструментом, поскольку, как только вы узнаете Git, эти вещи не так сложно сделать в оболочке Bash, но это вариант.

      Проще говоря, ниже мы рассмотрим разницу между git и git hub и VSTS.

      git: — Рассматривайте git как движок/технологию для обеспечения контроля версий в нашем проекте. В отличие от TFS (опять же централизованный контроль версий исходного кода) git — это технология распределенного контроля версий. Это означает, что Git фактически не требует наличия какого-либо сервера. С помощью технологии git мы можем сделать наш собственный локальный компьютер в качестве репозитория исходного кода, не требуя, чтобы всегда был централизованный сервер (в больших масштабах он может иметь сервер Microsoft для отправки и сохранения исходного кода нашего проекта). Но с управлением версиями типа SVN и TFS обязательно, чтобы сервер был связан с ним.

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

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

      VSTS: — VSTS — это продукт Microsoft для онлайн-хранилища с контролем версий, который можно рассматривать как альтернативу git-хабу. Начиная с Microsoft, VSTS поддерживает как git-технологию, так и TFS (базовый контроль версий TFVC-team). Поскольку TFS является еще одним старым продуктом Microsoft для достижения этого контроля версий. Постепенно я предполагаю, что VSTS будет постепенно выгружать TFS, поскольку git является известной технологией в этой области и является открытым исходным кодом.

      Github — что это такое? Как работать с сайтом github.com?

      GitHub — что это такое? Данный ресурс — это веб-платформа для управления версиями и совместной работы для разработчиков программного обеспечения. Поставляется через бизнес-модель с программным обеспечением как услуга был запущен в 2008 году. Ресурс основан на Git — системе управления исходным кодом, созданной Линусом Торвальдсом для ускорения разработки программного обеспечения.

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

      GitHub — что это?

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

      Как работать в GitHub?

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

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

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

      Терминология

      Три важных термина, используемых разработчиками в среде GitHub.com, — это fork, pull request и merge.

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

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

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

      Продукты и функции

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

      Другие продукты и особенности приложения включают:

      Gist — позволяет программистам GitHub делиться фрагментами кода или другими заметками.

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

      Pages — являются статическими веб-страницами для размещения проекта и получения информации непосредственно из репозитория GitHub отдельного лица или организации.

      Desktop — позволяет получать доступ к GitHub с настольных компьютеров Windows или Mac.

      Student Developer Pack — бесплатное предложение инструментов разработчика, которое ограничено количеством участников. Включает облачные ресурсы, средства программирования, поддержку и доступ к ресурсу.

      Социальное кодирование как основа проекта

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

      Хотя этот термин часто ассоциируется с сайтами социального кодирования, например, GitHub, BitBucket, CodePlex и Google Code, его вполне можно использовать для описания любой среды разработки, которая предполагает обсуждение и совместное использование.

      Репозиторий

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

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

      Социальный нетворкинг

      Социальные сети как общий принцип GitHub — что это? Это практика расширения числа деловых и социальных контактов путем установления связей между людьми, часто через сайты социальных сетей: Facebook, Twitter, LinkedIn и Google+.

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

      Записки программиста

      Моя шпаргалка по работе с Git

      28 декабря 2011

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

      В чем состоит отличие Git от Subversion?

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

      Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

      В результате имеем:

      • Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
      • Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
      • Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
      • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
      • Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
      • Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
      • Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
      • Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
      • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
      • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

      Пример использования Git

      Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

      В первую очередь необходимо поставить Git:

      Затем создаем пару ssh ключей, если не создавали ее ранее:

      Топ-пост этого месяца:  Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при
  • Добавить комментарий