Github как пользоваться для чайников: Как пользоваться гитхабом для чайников

Как пользоваться гитхабом для чайников

Github – это очень известная платформа для хранения, распространения и управления исходным кодом открытых проектов. Этот сервис используют множество разработчиков по всему миру, среди которых есть и крупные компании, такие как Microsoft, RedHat и множество других, также сотни разработчиков многих популярных проектов.

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

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

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

1. Создание аккаунта

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

Когда завершите ввод, нажмите кнопку «Sign Up Free»:

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

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

Никакая настройка github не нужна, достаточно лишь несколько кликов мышкой.

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

На открывшейся странице, это главная страница для авторизованных пользователей, нажмите кнопку «Start a project»:

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

Вы можете сразу же инициализировать репозиторий, создав файл Readme, для этого нужно отметить галочку «Initialize this repository with a README» внизу страницы.

Когда все будет готово, выберите «Create project», будет создан новый проект с файлом README, в котором находится описание и файлом лицензии.

Дальше все самое интересное как работать с github.

3. Добавление веток

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

Текущая ветка обозначена в верхнем левом углу после слова «Branch». Чтобы создать новую ветку просто разверните этот список и начните набирать ее имя:

Сайт сам предложит вам создать новую ветку, выберите «Create branch».

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

4. Изменение файлов и коммиты

Любые изменения файлов на Github делаются с помощью коммитов. Коммит выполняется путем внесения самих исправлений и описания этих исправлений. Это необходимо для того, чтобы вы знали что и когда вы меняли, а также позволяет легко отслеживать работу команды. Слово коммит можно перевести как «фиксировать». То есть мы можем внести изменения в несколько файлов, а затем их зафиксировать. Давайте для примера изменим файл README. Для этого найдите в в правой стороне панели кнопку с кисточкой и нажмите на нее:

Откроется текстовый редактор, где вы можете ввести нужные вам исправления:

После того как вы сделаете все что вам нужно, необходимо заполнить поле «Commit» внизу страницы. Кратко опишите что было изменено, а затем нажмите кнопку «Commit changes»:

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

5. Создание запросов слияния (Pull Request)

GitHub для начинающих может показаться очень сложным именно из-за таких возможностей, но это очень удобно если разобраться. Запрос слияния или Pull Request – это возможность, благодаря которой любой разработчик может попросить другого, например, создателя репозитория просмотреть его код и добавить его в основной проект или ветку. Инструмент работы с запросами слияния использует инструмент сравнения diff, поэтому вы можете увидеть все изменения, они будут подчеркнуты другим цветом. Pull Request можно создать сразу же после создания коммита. Давайте отправим Pull Request из нашей testing ветки в основную. Сначала откройте вкладку

Здесь нажмите кнопку «Create Pull Request»:

Дальше вам нужно будет выбрать ветку, которую нужно слить с основной, в нашем случае «testing».

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

Дальше нажмите зеленую кнопку «Create Pull Request» и введите описание, как и для коммита:

6.

Теперь, на той же вкладке Pull Requests мы видим только что созданный запрос на слияние и нам остается только принять его нажав

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

Дальше можно подтвердить Pull Request:

Затем код будет импортирован в основную ветку, а ветка testing может быть безопасно удалена.

7. Отчеты об ошибках

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

Дальше вам осталось ввести заголовок, текст и нажать «Create new issue».

8. Релизы

Последнее что мы сегодня рассмотрим – это релизы. Когда продукт достиг определенной стадии можно выпустить релиз, чтобы пользователи и вы могли быть уверенны что там все стабильно и никто ничего не сломал неверным Pull Request в Master. Сначала нужно перейти на главную страницу проекта, затем на вкладку

Дальше нажмите кнопку «Create New Release»:

На этой странице нужно указать версию в поле «Tag Version», затем имя релиза и небольшое описание. Если у вас есть скомпилированные архивы с бинарниками то их тоже нужно прикрепить сюда. Затем нажмите «Create Release»:

После создания релиза будет создана такая страничка:

Ссылки на исходный код в tar.gz и zip будут созданы автоматически, все остальные файлы вам придется добавлять вручную.

Выводы

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

В первую очередь надо установить клиент git: обязательно потребуется консольный клиент, доступный по ссылке http://git-scm.com/downloads (поддерживаются основные ОС), графический клиент можно установить по желанию, исходя из своих предпочтений. На Unix системах можно воспользоваться менеджером пакетов (yum на fedora и подобных или apt-get на debian, ubuntu и подобных) вместо того, чтобы скачивать установщик с сайта.

Далее работа с git будет объясняться на примере работы с консольным клиентом по следующим причинам:

• Чтобы у вас складывалось понимание происходящего и при возникновении проблем вы могли четко объяснить, что вы делали, и было видно, что пошло не так.
• Все нажатия кнопок в графических клиентах в итоге сводят к выполнению определнных команд консольного клиента, в то же время возможности графических клиентов ограничены по сравнению с консольным
• У тех, кто будет работать в классе на стоящих там компьютерах, не будет другого выбора, кроме как пользоваться консольным клиентом (на сколько мне известно, никаких графических клиентов для git там не установлено)

Аккаунт и репозитории на github. com

Затем надо зарегистрироваться на https://github.com/. После чего можно будет создавать свои репозитории или присоединиться к работе над проектами коллег, сделав fork другого репозитория. Вам предлагается начать с создания fork-а к заведенному мной репозиторию https://github.com/andreiled/mipt-cs-4sem, где я буду выкладывать примеры кода к занятиям и задания. О механизме обмена кодом между пользователями мы поговорим на следующем занятии.

Работа с кодом из репозитория на локальном компьютере

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

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

1. Открываем консольный клиент.

• На Windows после установки клиента появляется пункт Git Bash в контекстом меню папки. Достаточно перейти в желаемую папку и воспользоваться этим пунктом меню.
• На Unix системах достаточно открыть терминал и перейти в нужную директорию. При стандартной установке консольного клиента будет доступна команда git без дополнительных усилий.

1. Выполняем команду git clone https://github.com/%user_login%/%repo_name%.git . Полную https ссылку на репозиторий для его выкачивания можно также найти на странице самого репозитория на github. После этого в текущей папке появится новая папка с именем %repo_name% , содержащая копию удаленного (remote) репозитория.
2. Переходим в свежесозданную папку репозитория и настраиваем его:
3. git config user.name ivan.ivanov
4. git config user.email [email protected]

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

1. Воспользовавшись командой git status можно узнать, на какой ветке (branch) репозитория вы сейчас находитесь, какие изменения присутствуют в вашей рабочей копии и другую информацию.
   Рабочей копией называется совокупность файлов в локальной папке репозитория за исключением служебных файлов.
2. После внесения каких-либо изменений в рабочую копию их можно закоммитить в локальный репозиторий:
3. сначала нужная часть изменений подготавливается к коммиту с использованием команды git add %file_path%
4. после чего производится коммит командой git commit
   Использование команды без аргументов откроет текстовый редактор, где надо будет написать комментарий для коммита, коммит обязательно должен иметь комментарий. Другим вариантом задания комментария к коммиту является использование команды git commit -m «%commit_message%»
5. Историю изменений можно посмотреть командой git log или git log –name-only . Если вся история изменений не умещается на экране, то можно пользоваться клавишами прокрутки на клавиатуре («стрелочки», PgUp, PgDown), выход из режима просмотра изменений осуществляется нажатием клавиши «q».

Загрузка локальных изменений в удаленный репозиторий

После того, как были выполнены нужные локальные коммиты, изменения можно загрузить в удаленный репозиторий с помощью команды git push origin master . GIT клиент при этом запросит имя пользователя и пароль для доступа к github.
Выполнение этой команды может закончиться с ошибкой, если в локально репозитории отсутствуют последние изменения, имеющиеся в удаленном репозитории. Для решения этой проблемы надо выполнить команду git pull , которая скачает последние изменения из удаленного репозитория и смержит их с вашими локальными правками, после чего можно повторить команду git push .

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

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

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

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

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с «научкой» становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

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

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

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

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

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

Цель такой системы – поддержание актуальной версии проекта у всех ее пользователей.

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

Виды современной системы контроля версий

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

1. Существует только один репозиторий.
2. Простые номера версий файлов (1, 2, 3 и т.д.).
3. У пользователей хранится только текущая версия проекта.
4. Требуется подключение к интернету.
5. Просто, но медленно.
6. Сложности в одновременной работе над одним файлом.

Распределенная.

На один проект приходится много репозиториев.

1. Каждый пользователь создает локальную копию всего репозитория на основе главного облачного.
2. Номера версий сложные.
3. Возможность работать офлайн.
4. Работать быстро и удобно.
5. Требуется синхронизация репозиториев, так как проект — один.

Теперь можно дать определение и слову Git.

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

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

Как работает GitHub

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

Принципы работы с репозиторием GitHub

1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
3. Просим клиента внести изменённые файлы в репозиторий.
   Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
4. После коммита версия вашего локального репозитория изменилась.
5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

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

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

Способы решения конфликта:

1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

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

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development – ветка для непосредственной разработки; dev-adaptive – ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

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

Размещение на GitHub Pages — Основы HTML, CSS и веб-дизайна

Хостинг

Мы уже изучили вкратце такие темы, как хостинг и HTTP-запросы в уроке Хостинг курса «Введение в веб-разработку». Стоит освежить память, перечитав тот урок, если следующие термины вам не сразу понятны:

• хостинг
• сервер
• IP-адрес
• хост
• DNS
• HTTP
• whois

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

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

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

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

1. Операционная система делает запрос в жёсткий диск или оперативную память.
2. Жёсткий диск или оперативная память отдают содержимое файла.
3. Операционная система направляет содержимое файла в программу «браузер».
4. Браузер обрабатывает файлы (потому что знает как это делать, ведь файлы написаны по стандартам HTML и CSS) и формирует внешний вид.

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

GitHub

Если вы проходите наши курсы по порядку, в рамках программ обучения (например, «Бэкенд JS-программист» или «Фронтенд JS-программист»), то в скором будущем вас ожидает курс по Git. Один из уроков там будет посвящён GitHub.

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

Страницы, размещённые на GitHub Pages, могут быть доступны на их поддомене (например, https://guides.hexlet.io/) или на домене второго уровня (например, мой блог https://rakh.im/), если у вас есть свой домен.

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

Начнём:

1. Зарегистрируйтесь на https://github.com/, если ещё не сделали этого.
2. Создайте новый репозиторий с именем username.github.io, где username — ваш ник на GitHub.
3. Создайте новый файл. Когда репозиторий не пуст, то в верхнем правом углу есть кнопка «Create New File», но сейчас, когда ещё нет ни одного файла, создать первый можно по прямой ссылке https://github.com/username/username.github.io/new/master, где username — ваш ник.
4. Введите имя index.html и скопируйте туда содержание файла index.html, который у вас получился в предыдущем уроке.
5. Нажмите кнопку «Commit new file».
6. Повторите то же самое для файла style.css.
7. Подтвердите публикацию на GitHub Pages. В настройках репозитория: Settings -> Раздел Options -> Секция GitHub Pages.
8. Через несколько мгновений страница станет доступна по вашему адресу https://username.github.io

(Если вы умеете работать с Git и собираетесь делать всё локально, то при создании репозитория советую выбрать «Initialize this repository with a README» — в таком случае репозиторий сразу создастся непустым, и его можно будет клонировать. В противном случае нужно будет инициализировать репозиторий локально и добавить удалённый репозиторий).

Остались вопросы? Задайте их в разделе «Обсуждение»

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

Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

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

Об обучении на Хекслете

DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

Что такое git? git – это распределенная система управления версиями.

Не так давно проект “Google API в Delphi” успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git. Для чего и почему мы это сделали – это вопрос второстепенный, а вот работа с Git, по крайней мере для меня, стала основной. По сути этот пост ни что иное как шпаргалка для себя любимого по выполнению основных операций при работе Git, но может эта шпаргалка поможет кому-то как и мне начать работу с этой DVCS.

Небольшое введение. О чем вообще пойдет речь

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

То обстоятельство, что система создавалась “под Linux” уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать “консоль отстой, git – в печь” и все такое. Поверьте – консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство – чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайника, как я.

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

Это обстоятельство и поставило меня в начале работы с Git в тупик.
Как это так commit и не в центральный репозиторий?
Как правильно отправлять данные на сервер?
Как вообще начинать работу?
Эти и ещё многие другие вопросы посещали меня на старте работы с Git. Сейчас я не буду углубляться далеко в теоретические вопросы Git, да и вообще любых систем контроля версия – всего этого полно в Сети. А затрону один практический момент – как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потерянные исходники.

Качаем и устанавливаем софт

Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовали в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подобного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git – TortoiseGit.
По сути TortoiseGit после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit – то, что Вам нужно.
Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:

1. msysgit – качаем Git-1.7.1-previewXXXXXXXX.exe (11,6 Mb) Git For Windows
2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне “Choose SSH Client” второе значение:

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

Получаем доступ к репозиторию

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

1. Регистрация на GitHub’e.

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

Профиль на GitHub.com

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык – Git Bush – вот с помощью него и запускаем консоль.

1. Набираем в консоли следующую команду
   

   ssh-keygen -t rsa -C “E-Mail из Вашего профиля”

2. На экране появится запрос “Enter file in which to save the key”. Пока оставим значение по умолчанию. Жмем Enter.
3. Нас попросят ввести пароль. Эту часть тоже пропускаем – впоследствии пароль можно будет установить, а пока – учимся. Жмем опять Enter.
4. Сгенерируются два файла один из которых – публичный ключ для доступа.

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

C:/Documents and Settings/UserName/.ssh/

Заходим в директорию, открываем с помощью “Блокнота” файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
2. Выбираем пункт “SSH Public Keys”
3. Жмем ссылку “Add another public key”

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key – поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

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

Работа со своим первым репозиорием Git

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

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

1. Вызываем контекстное меню и выбираем пункт “TortoiseGit — Settings“:

В появившемся окне переходим сразу к пункту “Git – Config” и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем “Git Clone..“:

В открывшемся окне в поле URL вставляем скопированный адрес и жмем “Ok”:

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

cd path/to/dir
git clone URL

После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню “TortoiseGit — Create Branch“:

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

Выбираем в меню “TortoiseGit – Switch/Checkout…“:

В открывшемся окне выбираем нашу новую ветку и жмем “Ок”. Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

checkout -b new-branch

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

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

1. Вносятся изменения в проект

2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

git commit

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

git push origin <свое имя бранча>

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

Для этого выбираем новый файл, вызываем меню и выбираем “Add…”:

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем “Ok”.

После того как файл добавлен, можно сразу же сделать Commit – кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

Заполняем поле с описанием, жмем “Ок”  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

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

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе – нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Вот пожалуй все, что мне пока потребовалось использовать при работе с новой для меня системой контроля версий. Надеюсь эта мини-шпаргалка поможет кому-нибудь кроме меня. А если Вас заинтересовала работа с консолью, то как раз сейчас я изучаю Вот такие топики на habrahabr.ru:
1. Git Workflow.
2. Git Wizardry
Статьи написаны понятным простым языком и касаются как раз работы с Git с нуля.

Книжная полка

0 0 голоса

Рейтинг статьи

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

В этом уроке:

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

Весь плейлист: тут

Как работать с файлом .gitignore:

• Одна строчка — одно правило,
• Пустые строки игнорируются,
• Комментарии доступны через решётку(#) в начале строки,
• Символ «/» в начале строки указывает, что правило применяется только к файлам и папкам, которые располагаются в той же папке, что и сам файл .gitignore,
• Доступно использовать спецсимволы: звёздочка(*) заменяет любое количество символов(ноль или больше), вопросик(?) заменяет от нуля до одного символа. Можно размещать в любом месте правила,
• Две звёздочки(**) используются для указания любого количества поддиректорий, подробнее смотри ниже в примерах,
• Восклицательный знак(!) в начале строки означает инвертирование правила, необходим для указания исключений из правил игнорирования,
• Символ «\» используется для экранирования спецсимволов, например, чтобы игнорировать файл с именем «!readme!.txt«, нужно написать такое правило: «\!readme!.txt«,
• Для игнорирования всей директории, правило должно оканчиваться на слэш(/), в противном случае правило считается именем файла.

Пример файла

# Игнор-лист файлов проекта

# Игнорировать ВСЕ файлы и директории, включая поддиректории и файлы в них

*

# —- ФАЙЛЫ —-

# Игнорирование по типу файла, будут игнорироваться в АБСОЛЮТНО всех директориях

# Например /files/data.zip, /server.log, /uploads/users/data/info.xls

*.zip

*.log

*.pdf

*.xls

# Игнорирование файла во ВСЕХ директориях

# Например /params/db/config.php, /config.php

config.php

# Игнорирование конкретного файла ТОЛЬКО в корне проекта

# (корнём считается расположение файла .gitignore)

# Например НЕ БУДЕТ проигнорирован файл /db/config.php

/config.php

# Игнорирование конкретного файла ТОЛЬКО в указанной директории

# Например НЕ БУДЕТ проигнорирован файл /prod/params/config.php

/params/config.php

# —- ДИРЕКТОРИИ —-

# Игнорирование всех файлов и папок ТОЛЬКО в конкретной директории(включая поддиректории и файлы в них)

# Например /images/user.jpg, /images/company/logo.png

# НЕ БУДУТ проигнорированы файлы и папки /prod/images/user.jpg

/images/*

# Игнорирование всех файлов и папок в ЛЮБЫХ директориях с указанным именем

# Например /images/user.jpg, /core/images/user.jpg

images/*

# Игнорирование ВСЕХ html-файлов в ОДНОЙ КОНКРЕТНОЙ директории(НЕ ВКЛЮЧАЯ поддиректории)

# Например /private/index.html

# НЕ БУДУТ проигнорированы файлы в /private/ivan/index.html

/private/*.html

# Игнорирование ВСЕХ html-файлов в КОНКРЕТНОЙ директории ВКЛЮЧАЯ поддиректории

# Например /private/info.html, /private/users/ivan/info.html

/private/**/*.html

# —- РАЗНОЕ —-

# Исключение из игнорирования

# Игнорирование ВСЕХ файлов и папок внутри директории /secret,

# за исключением файла /secret/free.txt, он не будет проигнорирован

/secret/*

!/secret/free.txt

# Игнорирование файла с именем, содержащим спецсимволы

# Например !readme!.txt

\!readme!.txt

# Игнорирование всех JPG и JPEG файлов внутри директорий,

# которые начинаются на «h» и МОГУТ содержать ещё один символ после

# Например /images/h5/user.jpg, /images/h/company.jpeg

/images/h?/*.jp?g

Ссылки:
Скачать установщик Git: тут
Шпаргалка по командам Git: тут
Туториал по Git: тут
Основы работы с редактором VIM: тут

Больше уроков:
Уроки по android разработке: ссылка
Дизайн android приложений: ссылка
Уроки создания игр для android: ссылка
Основы программирования на JAVA: ссылка

<<Git — основы работы с системой контроля версий | Инструменты android разработчика

Как получить список всех установленных приложений на Android>>

Что такое Git и Github – руководство для начинающих

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

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

Что такое Git?

Git – это программное обеспечение для контроля версий. Он был создан Линусом Торвальдсом (парнем, который изобрел Linux). Вам не нужно использовать Linux, чтобы использования git – он также работает на Windows и Mac.

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

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

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

Словарь терминов, связанных с Git

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

Репозиторий (repository)

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

Github

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

Фиксация (commit)

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

Отправка (push)

Фиксация помещает ваши файлы в капсулу времени, а отправка – это то, что запускает капсулу в космос. Отправка – это, по сути, синхронизация ваших сохранений (фиксаций, коммитов) с облаком (опять же, вероятно, Github). Вы также можете использовать несколько коммитов одновременно. Вы можете работать в автономном режиме, сделать много работы, а затем передать все это на Github.

Ветка (branch)

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

Объединение (merge)

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

Клонирование (clone)

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

Ответвление (fork)

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

Запрос на подтверждение (Pull Request)

Запрос на подтверждение – это когда вы отправляете запрос с внесенными вами изменениями (либо в ветке, либо в ответвлении), которые должны быть перенесены (или объединены) в основную ветвь (Master Branch) репозитория. Это великий час, и здесь происходит волшебство. Если запрос на подтверждение будет одобрен, вы официально внесете свой вклад в программное обеспечение, и Github всегда будет показывать, что именно вы сделали. Однако, если запрос отклоняется по какой-либо причине, ревизор сможет дать отзыв о том, почему запрос был отклонен и что вы можете сделать, чтобы он был принят.

Начало работы с Git и необходимые команды

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

В данном уроке мы предполагаем, что вы используете командную строку для взаимодействия с git. Конечно, для этого есть и git-клиенты с графическим интерфейсом (и Github даже позволяет вам делать практически все через свой веб-интерфейс), но здесь мы это рассматривать не будем. Основы работы с терминалом или командной строкой описаны здесь.

Как установить Git

К счастью, установить git очень просто, независимо от того, работаете ли вы на Linux, Mac или Windows.

Для Linux откройте терминал и введите команду sudo apt-get install git-all (если вы находитесь в Ubuntu).

В Windows все просто. Вы скачиваете установщик и запускаете его.

На Mac вам просто нужно открыть терминал и набрать git. Если git не установлен, вы увидите предложение установить его. Нажмите кнопку Установить, и все готово.

Видите? Все очень просто!

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

Здесь начинается самое интересное. Теперь, когда у вас установлен git, пришло время немного покопаться и научиться использовать его. А с чего лучше начать, если не с Github?

Поэтому зайдите и зарегистрируйте свою новую учетную запись на Github (или войдите, если она у вас уже есть).

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

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

Сначала вам нужно настроить хранилище в Github. Вы можете сделать это на своем компьютере, а затем загрузить его, но проще сначала сделать это в Интернете. Нажмите кнопку Создать новый репозиторий (Create a new repository) или же Начать проект (Start a project) на сайте.

Заполните форму и нажмите кнопку Создать репозиторий (Create repository).

Теперь, когда репозиторий существует на Github, пришло время перенести его на локальный компьютер с помощью клонирования. Справа от вашего репо, чуть выше списка файлов, вы увидите зеленую кнопку с надписью Клонировать или загрузить (Clone or Download). Нажмите на нее, и вы увидите возможные варианты загрузки: Открыть на компьютере (если вы уже установили git или GitHub Desktop), а также Загрузить ZIP. Выберите нужный вариант.

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

Первая команда, которую вам нужно выучить, это ls. Она покажет перечень всего в текущем каталоге.

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

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

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

Начните с копирования URL-адреса, который появляется после нажатия зеленой кнопки Клонировать или скачать на Github. Этот адрес будет выглядеть примерно так: https://github.com/SebWeo/test.git

Команды для клонирования Git-репозитория из Github:

git clone https://github.com/SebWeo/test.git
ls
cd firstrepo – или как вы назвали свой репо
ls

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

Основы работы с репо на локальной машине

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

Добавление и фиксация в Git-репозитории

• git status – эта команда покажет вам, какие файлы не были добавлены в список для следующей фиксации. В большинстве терминальных приложений не добавленные/добавленные файлы будут красного/зеленого цвета соответственно.
• git add . – добавив точку в конце команды, вы говорите git включить все в каталоге. Если вы хотите добавить один файл, просто используйте его имя вместо точки.
• git commit -m "краткое сообщение" – когда вы фиксируете эти файлы, вы также должны оставить краткое сообщение (заметку), чтобы ваши коллеги по команде точно знали, что было в этом коммите. Стандартные соглашения git говорят, что вы должны быть как можно более краткими и конкретными и начинать сообщение, используя настоящее время глагола. Эти заметки видны на Github в перечне файлов.

Отправка на удаленный Git-репозиторий, такой как Github

Используйте следующие команды:

• git status – вы всегда должны проверять, как все выглядит, и убедиться, что вы находитесь на правильной ветке.
• git push
• Введите ваше имя пользователя и пароль для Github. Имейте в виду, что поле пароля будет оставаться пустым даже при вводе. Все в порядке. Просто наберите его и нажмите Enter. Если вы используете SSH, у вас не будет этого шага.

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

Ветвление и слияние

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

Вот примеры команд:

• git checkout -b "branch2" – эта команда создаст новую ветвь (с именем branch2), и переключит вас на нее как на рабочую ветку. Эта команда объединяет команды git checkout и git branch в одну удобную строку кода.
• touch some.html – это простая команда создания нового HTML-файла.
• git status
• git add some.html
• git commit -m "create some.html"
• git status – снова убедитесь, что все в порядке.

Вы можете переключиться обратно на основную ветку с помощью команды git checkout master (на этот раз без checkout -b).

• git status – как всегда.
• git merge branch2 – поскольку все в этой ветке в порядке, мы можем идти дальше и заняться объединением.
• git push – команда для синхронизации.

Проверьте свою учетную запись Github – вы увидите, что все, что вы сделали, отражается там. Вы можете увидеть различные сообщения: количество веток и коммитов, которые вы сделали, а также всех участников (contributor) репо и того, что они сделали.

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

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

Начинаем работать с git, github и visual studio code

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

Что такое GIT

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

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

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

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

Установка GIT

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

Установка GIT в Linux (Ubuntu)

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

sudo apt install git

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

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

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

Установка в Windows

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

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

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

Настройка Git

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

git config --global user.name "ВАШЕ_ИМЯ"

git config --global user.email АДРЕС

Заменив значения ВАШЕ_ИМЯ и АДРЕС вашими значениями.

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

git config --global --list

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

GITHUB

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

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

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

Копирование репозитория Git в локальную папку

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

Копировать или клонировать репу c GitHub можно по HTTPS или SSH.

Команда для копирования репозитория:

git clone ССЫЛКА_НА_РЕПОЗИТОРИЙ

После клонирования переходим в папку репозитория:

cd НАЗВАНИЕ_РЕПОЗИТОРИЯ 

Смотрим статус:

git status

Добавление данных в Git или коммит (commit)

Создаем файл с текстом:

echo "This example Git text file" > example.txt

Смотрим статус:

git status

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

git add example.txt

Снова смотрим статус, видим что у нас появился новый файл example.txt, добавляем данный файл в репозиторий используя git commit:

git commit -m "This first example text file"

Отправка данных в онлайн Git репозиторий

Отправить данные в репу можно используя команду git push:

git push origin master

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

Обратите внимание, что если вы используете двухфакторную авторизацию на github и являетесь пользователем linux, то вам нужно в настройках, в разделе «Developers setting» создать новый Personal access tokens и данный токкен использовать вместо пароля при аутентификации.

VISUAL STUDIO CODE

Данное ПО является хорошим выбором для комфортной работы с GIT и GITHUB. В VS Code есть встроенный терминал, который можно вызвать с помощью комбинации клавиш:

ctrl + `

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

Настройка терминала VS Code в Windows

По умолчанию консоль VS Code в Windows запускает стандартную командную строку Windows, которая не может работать с GIT, чтобы все работало нужно запустить терминал bash, для этого выполним следующие действия:

1. Убедимся, что ранее нами был скачан и установлен git, подробнее данный процесс был описан выше.
2. Запускаем Visual Studio Code.
3. Зажимаем сочетание клавиш Ctrl + Shift + P вводим open user setting и из выпадающего меню выбираем Open User Settings.
4. В параметры поиска вводим terminal.integrated.shell.windows и заменяем cmd.exe на C:\\Program Files\\Git\\bin\\bash.exe (если вы установили git в другую директорию то ссылка будет иметь вид относительно установленной вами директории).
5. Перезагружаем Visual Stuio Code
6. Открываем терминал и проверяем, что запущен bash терминал

Хорошие ссылки по данной теме

sys-adm.in/programming/623-git-for-beginning.html

htmlacademy.ru/blog/187-git-console

Что такое GitLab, как и для чего он используется

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

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

В этой статье мы рассмотрим установку бесплатной версии GitLab Community Edition (GitLab CE) на сервер с Ubuntu 20.04 LTS x86_64, сравним GitLab с GitHub, разберемся с возможностями платных и бесплатных версий GitLab и расскажем как пользоваться GitLab. Но для начала подготовим выделенный сервер для разворачивания демо-стенда.

Чтобы создать сервер, откроем панель управления my.selectel.ru и перейдем в меню Серверы и оборудование, затем нажмем кнопку Заказать сервер.

В нашем примере для GitLab используется выделенный сервер фиксированной конфигурации EL09-SSD с процессором Intel Xeon E-2236, 16 Гб оперативной памяти, двух SSD-дисков по 480 Гб и операционной системой Ubuntu 20.04 LTS 64-bit.

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

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

Возможности GitLab

Возможности GitLab делятся на следующие категории:

• управление (Manage),
• планирование (Plan),
• создание (Create),
• проверка (Verify),
• упаковка (Package),
• безопасность (Secure),
• релизы (Release),
• конфигурирование (Configure),
• мониторинг (Monitoring),
• защита (Defend).

Мы расскажем про основные в каждой категории.

Управление

• Аутентификация и авторизация. Двухфакторная аутентификация, интеграция с пользовательскими каталогами (AD/LDAP), гранулярный доступ к объектам в GitLab, поддержка токенов и SSO.
• Аналитика. Аналитика продуктивности разработчиков, трекинг выполнения задач группами пользователей.

Планирование

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

Создание

• Управление исходным кодом. График коммитов, запросы на слияния веток разработки, интеграция с Jira.
• Веб-консоль для редактирования кода. Веб-представление кода в интерфейсе, редактирование кода, синхронизация файлов с исходным кодом.

Проверка

• Поддержка процесса Continuous Integration (CI). Встроенные инструменты CI/CD, интеграция с Github, просмотр пайплайнов разработки, онлайн-визуализация HTML-артефактов.
• Проверка качества кода и тестирование. Отчеты по качеству кода, юнит-тестам, нагрузочное тестирование, тесты на доступность и юзабилити.

Упаковка

• Управление репозиториями. Поддержка репозиториев C/C++, Maven (Java), NPM, NuGet (.NET), Composer (PHP), PyPi (Python) и других.
• Управление контейнерами. Поддержка работы с Docker, управление репозиторием через API и вебхуки, приватных контейнерных репозиториев.

Безопасность

• Поддержка SAST и DAST. Работа с Static Application Security Testing и Dynamic Application Security Testing включая возможности отчетности.
• Сканирование зависимостей и управление уязвимостями. Gitlab поддерживает автоматизированное выявление зависимостей в коде и позволяет строить отчеты по возможным уязвимостям.

Релизы

• Поддержка процесса Continuous Delivery (CD). Возможность запуска CI/CD в различных окружениях (Windows, Mac, Linux), поддержка канареечных релизов, обеспечение безопасности пайплайнов.
• Оркестрация релизов. Отслеживание релизов, ассоциация релизов с этапами, управление доступом к защищенным окружениям.

Конфигурирование

• Управление Kubernetes. Поддержка работы с несколькими кластерами Kubernetes, разворачивание в кластере Kubernetes, управление переменными в зависимости от окружения.
• ChatOps и бессерверные вычисления. Разворачивание и другие операции из чата и поддержка выполнения функций через Knative.

Мониторинг

• Метрики. Мониторинг производительности приложений, кластеров kubernetes и самого Gitlab с возможностью отправки уведомлений.
• Управление инцидентами и логирование. Автоматическое создание инцидентов в случае превышения порогов и отправка логов во внешние системы.

Защита

• Web Application Firewall и безопасность контейнеров. Блокировка атак на веб-интерфейс и отслеживание жизненного цикла контейнеров.
• Сетевая безопасность. Поддержка микросегментации контейнеров для изоляции потенциально опасных контейнеров и применение политик безопасности.

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

Как установить и настроить GitLab на Ubuntu

Пока вы узнавали о возможностях GitLab, сервер успешно установлен и готов к работе. Подключаемся по SSH к серверу, переходим в директорию /tmp и загружаем установочный скрипт репозиториев GitLab:

# cd /tmp
# curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh

После загрузки скрипта, он необходимо добавить права на его исполнение:

# chmod 777 script.deb.sh

Теперь скрипт готов к исполнению и можно его запускать:

# bash /tmp/script.deb.sh

После установки репозитория, можно запускать менеджер пакетов apt и начинать установку GitLab:

# apt install gitlab-ce

После выполнения установки, появится сообщение о готовности GitLab к работе:

Для доступа к GitLab через веб-интерфейс, его необходимо настроить. Для этого откроем для редактирования конфигурации в файле /etc/gitlab/gitlab.rb и укажем переменной external_url в качестве значения URL-адрес сервера.

# vi /etc/gitlab/gitlab.rb

В нашем демо вместо имени используется IP-адрес.

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

# gitlab-ctl reconfigure

После окончания процесса конфигурации, откроется интерфейс GitLab и запрос на изменения пароля администратора.

После изменения пароля необходимо выполнить вход в GitLab:

GitLab полностью готов к работе и даже имеет тестовый проект.

Однако, GitLab по умолчанию работает по протоколу http. Чтобы переключить его на протокол https, необходимо изменить значения переменных letsencrypt[‘enable’], letsencrypt[‘contact_emails’] и в переменной external_url указать протокол https:

letsencrypt['enable'] = true
external_url "https://<внешний IP-адрес>"
letsencrypt['contact_emails'] = ['[email protected]']

После внесения изменений в конфигурацию, выполним реконфигурацию GitLab:

# gitlab-ctl reconfigure

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

Если GitLab установлен во внутренней сети и к нему требуется доступ извне, одним из вариантов организации такого доступа может быть настройка проксирования на nginx-сервере (или proxy_pass) с установкой на него ключа Let’s Encrypt. В этом случае в настройках GitLab можно спокойно оставлять доступ по протоколу http.

Иногда, при попытке доступа через веб-интерфейс, GitLab возвращает ошибку 502. Причины могут быть разные, но основные это: нехватка оперативной памяти, остановка службы gitlab-workhorse и изменение прав доступа к файлу /var/opt/gitlab/gitlab-workhorse/socket. В первом случае проблему решит добавление оперативной памяти, во втором перезагрузка сервисов GitLab, а в третьем предоставление сервису nginx доступа к файлу.

Как работать с GitLab

Чтобы упростить работу с репозиториями из командной строки, необходимо добавить собственные ssh-ключи в GitLab. Генерируем пару ssh-ключей:

# ssh-keygen -t rsa -f ~/.ssh/gitlab

Следующий шаг — вывод содержимого публичного ключа и его копирование в буфер обмена:

# cat ~/.ssh/gitlab.pub

В интерфейсе GitLab перейдем в раздел Settings:

Далее в раздел SSH Keys, где нужно вставить скопированный ключ. После этого можно нажать Add key.

Появится следующий экран:

На этом настройка к репозиториям через SSH-ключ завершена и пришло время создать новый проект. Для этого достаточно нажать на + в центральной части экрана и далее на New project.

Проекту нужно присвоить имя, а также выбрать тип проекта:

• приватный (Private),
• внутренний (Internal),
• публичный (Public).

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

Нажимаем на кнопку Create project:

После создания проекта можно перейти к его настройке. Например, на представлении Members в проект можно пригласить новых пользователей с различными ролями: Guest, Reporter, Developer, Maintainer:

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

# git remote add origin git@<внешний IP-адрес>:root/selectel-test-project.git

Теперь загрузим репозиторий в GitLab:

# git remote add origin git@<внешний IP-адрес>:root/selectel-test-project.git

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

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

# git clone git@<внешний IP-адрес>:root/selectel-test-project.git

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

Теперь разберемся, как в GitLab работать с ветками репозитория. По умолчанию работа ведется в ветке master и все предыдущие действия мы выполняли именно в ней. Для реализации изменений и их отслеживание, разработчику важно иметь собственную ветку, код из которой в дальнейшем можно будет передать в master-ветку.

Чтобы создать новую ветку, достаточно в выпадающем меню рядом с символом + нажать на пункт меню New branch:

Новую ветку также можно создать в локальном репозитории Git и затем загрузить её в GitLab. В веб-интерфейсе появится соответствующая запись о новой ветке.

Мы создали в проекте новую ветку development. В меню Settings — Repository можно выбрать ветку, используемую по умолчанию. После выбора нужно нажать на кнопку Save changes.

Поскольку разработка чаще всего ведется в нескольких ветках, в определенный момент времени появится необходимость выполнить их слияние. Cлияние веток — основа GitLab. В GitLab для реализации этого процесса предназначены запросы на слияние (Merge requests). Создадим в локальном репозитории новую ветку и назовем ее staging:

# git checkout -b staging

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

# vi new-staging.txt

Добавим этот файл к репозиторию:

# git add new-staging.txt

Выполним коммит с комментарием:

# git commit -m "add feature"

И, наконец, загрузим новую ветку в GitLab:

# git push --set-upstream origin staging

Теперь можно проверить наличие новой ветки staging в интерфейсе GitLab. Перейдем в раздел Repository — Branches и обнаружим созданную ветку. Если перейти в нее, там будет созданный на предыдущих шагах файл new-staging.txt.

Перейдем в эту ветку и нажмем кнопку Create merge request:

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

На следующем экране можно опционально нажать Approve, а затем нажать Merge:

Слияние веток репозитория выполнено.

Чем отличаются GitLab и GitHub

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

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

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

Какие существуют версии и тарифы GitLab

GitLab имеет две версии — Community Edition (CE) и Enterprise Edition (EE). У первой (именно ее мы устанавливали в этой статье) полностью открытый исходный код, а вторая построена на базе первой, но имеет дополнительные функции, код которых, увы, не открыт для всех желающих. Версия EE также бесплатная в базовой комплектации и производитель рекомендует использовать именно её, если планируется дальнейший переход на платные тарифы.

Линейка тарифов представлена на скриншоте ниже. Цена за пользователя зависит от тех функций, которые включены в подписку.

Ключевой особенностью подписок уровня Premium и Ultimate является поддержка производителя в режиме 24/7. По этой ссылке можно получить полное представление о возможностях каждой из подписок.

Заключение

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

GitHub для чайников. Все, что вам нужно знать о… | автор: Made Lapuerta

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

Только после семи лет программирования я наконец научился использовать GitHub. Я знаю, я знаю — * вздох *.

Во время стажировки по связям с разработчиками в Google я быстро обнаружил, что мне нужно начать понимать GitHub быстро , поскольку большая часть разработки кода, обмена и анализа кода моей командой происходила на платформе.Спустя девять недель и множество поисковых запросов Google я наконец понимаю, как использовать GitHub в качестве инструмента, даже если он находится на уровне «новичка». Осмелюсь ли я зайти так далеко, что назову себя техническим братом ?

GitHub, который самопровозглашается как «ведущая в мире платформа для разработки программного обеспечения», позволяет разработчикам публиковать свой код, делиться своим кодом и участвовать в социальных сетях в отношении своего кода. Ботан! GitHub также позволяет вам сохранять и просматривать каждый черновик файла кода, который вы когда-либо создавали, легко позволяя вам не только отслеживать прогресс, но и возвращаться к более ранним версиям файла, если (когда) возникают ошибки.Кроме того, хотя можно вручную добавлять, удалять и изменять файлы прямо с GitHub.com, можно также адаптировать более технически подкованную версию: работу с GitHub полностью из командной строки.

Итак, хотя в этом посте я буду обсуждать только основы git / использования GitHub, приведенные ниже команды были всем, что мне было нужно во время стажировки в Google.

Первым шагом в редактировании и совместном использовании кода в GitHub является создание репозитория . Думайте о репозитории как о простом файле, который позже будет содержать все ваши файлы кода и историю для конкретного проекта кодирования.Вы можете вручную создать репозиторий (или, как его называют дети, «репо»), перейдя на главную страницу GitHub и нажав зеленую кнопку «NEW». Назовите свое репо чем-нибудь простым, например MyProject.

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

Подобно тому, как мы публикуем в Instagram только свои лучшие фотографии, мы размещаем только лучшие версии нашего кода на GitHub.

 git clone https://github.com/YourUsername/YourRepoName.git 

После выполнения указанной выше команды git clone с вашего терминала вы увидите новую папку под названием MyProject в ваших локальных файлах.

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

Используя командную строку, команда git status уведомит вас о любых изменениях, которые ваше репозиторий GitHub распознает в вашей локальной папке, которые еще не существуют в сети. При вводе git status ваш index.html будет отображаться красным цветом, что указывает на то, что еще не отправлено в ваше репозиторий GitHub.

 git add index.html 
 git commit -m "добавлен файл index.html" 
 git push 

Размещение — это трехэтапный процесс. Во-первых, git add index.html означает, что вы хотите добавить файл index.html в репозиторий GitHup. Во-вторых, git commit -m «message» , заменяя сообщение заполнителя на , что означает вашего добавления этого файла. Лучше всего сохранять конкретные сообщения коммитов, чтобы, когда вы делитесь своим кодом, коллеги (и ваши подписчики) могли точно понять процесс создания вашего кода.Наконец, git push отправит ваши добавленные файлы и сообщение о фиксации в репозиторий GitHub.

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

 git pull 

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

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

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

Итак, давайте создадим новую ветку и внесем в нее некоторые изменения кода.

 git checkout -b branch-name 

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

 git add.
 git commit -m "сообщение фиксации" 

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

 git push --set-upstream origin имя-ветки 

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

 git checkout имя-ветки 

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

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

Известный под псевдонимом «PR», запрос на вытягивание — это, по сути, когда вы просите кого-то набрать код , который вы указали на GitHub. После добавления кода в новую ветку перейдите на GitHub.com, чтобы просмотреть эту ветку прямо в браузере, и вам будет предложено создать запрос на перенос.

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

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

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

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

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

 git pull 

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

Невозможно разрешить хост

Часто, когда я пытаюсь отправить код в репозиторий, я получаю сообщение об ошибке:

 фатальный: невозможно получить доступ к 'your-repo-url': не удалось разрешить host: github.com 

Это просто означает, что вы работаете за брандмауэром, и это можно легко исправить, переключив сеть Wi-Fi или сбросив http-прокси:

 git config --global --unset http.proxy 
 git config --global --unset https.proxy 

Diverged Branches

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

 Ваша ветка и origin / xxx разошлись, 

Эта ошибка возникает, когда ваша локальная ветка не обновлена ​​со всеми коммитами, существующими удаленно в этой ветке (например, если кто-то недавно совершил фиксацию в той же ветке).Самый простой способ разрешить этот конфликт веток — это git pull или отразить все удаленные изменения в вашей локальной базе. Если это извлечение не решает проблему, попробуйте перебазировать вашу попытку фиксации в удаленное состояние вашей ветки:

 git rebase origin / your-branch-name 

Reverting Commits

Итак, вы сделали фиксацию, которую не должны ‘ нет… Хорошая новость в том, что GitHub предлагает простой однострочный способ отменить любые необходимые вам коммиты.

Если вы введете git log в командную строку, вы сможете увидеть историю ваших коммитов и заметите, что каждая фиксация идентифицируется уникальным идентификатором («SHA» или хешем).Для того, какой коммит вы хотите отменить, скопируйте и вставьте его уникальный идентификатор и введите в командную строку:

 git revert your-commit-id 

Видите? Легкий.

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

Помощь в настройке GitHub

Помощь с ветвями GitHub

GitHub Branches & Master

Глоссарий терминов GitHub

Поисковая система для GitHub Help

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

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

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

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

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

Что такое GitHub?

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

Из этого туториала Вы узнаете основы GitHub, такие как репозиториев , веток , коммитов и запросов на извлечение .Вы создадите свой собственный репозиторий 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. Щелкните раскрывающийся список в верхней части списка файлов, в котором указано ветвь: основная .
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

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

Когда вы закончите с сообщением, нажмите Создать запрос на перенос !

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

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

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

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

Празднуйте!

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

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

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

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

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

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

Последнее обновление 24 июля 2020 г.

Руководство для начинающих по Git и GitHub

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

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

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

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

Система ветвей в Git позволяет разработчикам работать индивидуально над задачей (например: Одна ветвь -> Одна задача ИЛИ Одна ветвь -> Один разработчик). В основном думайте о Git как о небольшом программном приложении, которое контролирует вашу базу кода, если вы разработчик.

  sudo apt update  

  sudo apt-get install git  

  git - версия  

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

  git clone [АДРЕС HTTPS]  

  cd [НАЗВАНИЕ ХРАНИЛИЩА]  

  cd [НАЗВАНИЕ ХРАНИЛИЩА]  

  git status  

  git add [FILENAME] [FILENAME] [. ..]  

  git add sample.html  

  git commit -m «Добавлен образец HTML-файла, который содержит базовый синтаксис»  

  git remote  

  git push origin master  

 : q  

  git init  

  git status  

  git add [FILENAME] [FILENAME] [...]  

  git add.  

  git commit -m «Добавление формы веб-опроса»  

  git remote add origin [HTTPS ADDRESS]  

  git remote  

  git remote add [REMOTE NAME] [HTTPS ADDRESS]  

  git push origin master  

  git удаленное добавление  
  

  git удаленное добавление источника 
  

  git add.

git commit -m "добавить .gitignore"
  

  git push origin master