Содержание

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

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 ветки в основную. Сначала откройте вкладку «Pull Request».

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

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

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

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

6.

Просмотр и одобрение запросов на слияние

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

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

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

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

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

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

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

8. Релизы

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

«Releases»:

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

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

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

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

Выводы

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

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

В первую очередь надо установить клиент 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.

Если Вы работаете в Delphi, то в этой статье представлено пошаговое руководство по настройке и работе с Git непосредственно из IDE Delphi

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

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 с нуля.

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

Описание: Рассмотрены практические вопросы по разработке клиент-серверных приложений в среде Delphi 7 и Delphi 2005 с использованием СУБД MS SQL Server 2000, InterBase и Firebird. Приведена информация о теории построения реляционных баз данных и языке SQL. Освещены вопросы эксплуатации и администрирования СУБД.

Описание: Рассмотрены малоосвещенные вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные режимы их работы, особенности для протоколов TCP и UDP и др.

0 0 голоса

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

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

В этом уроке:

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

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

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

Основные правила синтаксиса файла .gitignore:
  • Одна строчка — одно правило,
  • Пустые строки игнорируются,
  • Комментарии доступны через решётку(#) в начале строки,
  • Символ «/» в начале строки указывает, что правило применяется только к файлам и папкам, которые располагаются в той же папке, что и сам файл .gitignore,
  • Доступно использовать спецсимволы: звёздочка(*) заменяет любое количество символов(ноль или больше), вопросик(?) заменяет от нуля до одного символа. Можно размещать в любом месте правила,
  • Две звёздочки(**) используются для указания любого количества поддиректорий, подробнее смотри ниже в примерах,
  • Восклицательный знак(!) в начале строки означает инвертирование правила, необходим для указания исключений из правил игнорирования,
  • Символ «\» используется для экранирования спецсимволов, например, чтобы игнорировать файл с именем «!readme!.txt«, нужно написать такое правило: «\!readme!.txt«,
  • Для игнорирования всей директории, правило должно оканчиваться на слэш(/), в противном случае правило считается именем файла.
Пример файла
.gitignore:
    # Игнор-лист файлов проекта
    # Игнорировать ВСЕ файлы и директории, включая поддиректории и файлы в них
    *
    # —- ФАЙЛЫ —-
    # Игнорирование по типу файла, будут игнорироваться в АБСОЛЮТНО всех директориях
    # Например /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 [email protected]<внешний IP-адрес>:root/selectel-test-project.git

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

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

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

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

# git clone [email protected]<внешний 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 как о небольшом программном приложении, которое контролирует вашу базу кода, если вы разработчик.

Показывает, как работает Git.

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

Репозиторий (или для краткости «Репо») — это проект, содержащий несколько файлов. В нашем случае репозиторий будет содержать файлы на основе кода.

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

Существует три популярных хостинга Git: GitHub (принадлежит Microsoft), GitLab (принадлежит GitLab) и BitBucket. Мы будем использовать GitHub в качестве нашей службы хостинга.

Git упрощает участие в проектах с открытым исходным кодом

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

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

Документация

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

Варианты интеграции

GitHub может интегрироваться с распространенными платформами, такими как Amazon и Google Cloud, с такими сервисами, как Code Climate, для отслеживания ваших отзывов и может выделять синтаксис более чем на 200 различных языках программирования.

Отслеживайте изменения в вашем коде в разных версиях

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

GitHub решает эту проблему, отслеживая все изменения, внесенные в репозиторий.

Как и в случае использования Microsoft Word или Google Drive, вы можете иметь историю версий вашего кода, чтобы предыдущие версии не терялись при каждой итерации.Легко вернуться к предыдущей версии и поделиться своей работой.

Продемонстрируйте свою работу

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

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

Создание учетной записи GitHub

Чтобы создать учетную запись, вам необходимо перейти на веб-сайт GitHub и заполнить регистрационную форму.

Официальная веб-страница GitHub

Установка Git

Теперь нам нужно установить инструменты Git на наш компьютер. Мы будем использовать CLI для связи с GitHub.

Для Ubuntu:

  1. Сначала обновите свои пакеты.
  sudo apt update  

2. Затем установите Git и GitHub с помощью apt-get

  sudo apt-get install git  

3. Наконец, убедитесь, что Git установлен правильно

  git - версия  

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

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

Мы будем работать с проектами GitHub двумя способами.

Тип 1: Создайте репозиторий, клонируйте его на свой компьютер и работайте над ним. (Рекомендуется)

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

Создайте новый репозиторий, нажав кнопку «Новый репозиторий» на веб-странице GitHub.

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

Молодец! Ваш первый репозиторий GitHub создан.

Ваша первая миссия — получить копию репозитория на вашем компьютере. Для этого вам необходимо «клонировать» репозиторий на вашем компьютере.

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

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

  git clone [АДРЕС HTTPS]  

Эта команда создаст локальную копию репозитория, размещенного по данному адресу.

Выходное сообщение команды «git clone»

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

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

Как вы можете видеть на картинке выше, имя моего репозитория — «My-GitHub-Project», и эта команда заставила меня перейти в этот конкретный каталог.

ПРИМЕЧАНИЕ: При клонировании Git создаст репозиторий на вашем компьютере. Если вы хотите, вы можете получить доступ к своему проекту с помощью пользовательского интерфейса компьютера, а не с помощью указанной выше команды «cd» на терминале.

Теперь в этой папке мы можем создавать файлы, работать с ними и сохранять их локально.Чтобы сохранить их в удаленном месте, например на GitHub, мы должны выполнить процесс, называемый «фиксация». Для этого вернитесь к своему терминалу. Если вы закрыли его, как я уже говорил, используйте команду «cd».

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

Теперь в терминале вы находитесь в каталоге хранилища. Коммит состоит из 4 шагов: «status», «add», «commit» и «push». Все следующие шаги должны быть выполнены в рамках вашего проекта. Давайте рассмотрим их один за другим.

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

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

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

В нашем случае мы добавим простой HTML-файл.

  git add sample.html  

3. «commit»: Теперь, когда мы добавили файлы по нашему выбору, нам нужно написать сообщение, чтобы объяснить, что мы сделали.Это сообщение может быть полезно позже, если мы захотим проверить историю изменений. Вот пример того, что мы можем использовать в нашем случае.

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

4. «push»: Теперь мы можем разместить нашу работу на GitHub. Для этого мы должны «протолкнуть» наши файлы в Remote. Remote — это дубликат нашего репозитория, который находится где-то еще на удаленном сервере. Для этого мы должны знать имя пульта (в основном удаленный называется origin). Чтобы узнать это имя, введите следующую команду.

  git remote  

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

  git push origin master  

Теперь, если мы зайдем в наш репозиторий на веб-странице GitHub, мы увидим файл sample.html, который мы отправили на удаленный компьютер — GitHub!

ПРИМЕЧАНИЕ : Иногда, когда вы используете команды Git в терминале, это может привести вас к текстовому редактору VIM (текстовый редактор на основе интерфейса командной строки).Итак, чтобы избавиться от этого, вы должны ввести

 : q  

и ENTER.

Описывает, как работают pull & push.

Pulling — это процесс получения от GitHub.

Отправка — это отправка на GitHub.

Тип 2: работайте над своим проектом локально, затем создайте репозиторий на GitHub и отправьте его на удаленный компьютер.

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

Я объясню вам это с помощью веб-проекта формы опроса, который я сделал ранее, но не был добавлен в GitHub.

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

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

  git init  

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

  git status  

Итак, в этом каталоге есть два файла, которые нам нужно «добавить» в наше репо.

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

ПРИМЕЧАНИЕ : Чтобы «добавить» все файлы в наш репозиторий, мы можем использовать следующую команду:

  git add.  

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

Если эти конкретные файлы выделены зеленым цветом, как на рисунке ниже, вы сделал свою работу!

Затем мы должны «зафиксировать» с описанием в нем.

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

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

Итак, чтобы добавить этот пульт, мы должны сначала зайти на GitHub. Создайте новый репозиторий и назовите его как хотите, чтобы сохранить в GitHub. Затем нажмите кнопку «Создать репозиторий».

ПРИМЕЧАНИЕ : В Типе 2, пожалуйста, не инициализируйте репозиторий с помощью файла README при создании нового репозитория на веб-странице GitHub.

После нажатия кнопки «Создать репозиторий» вы увидите изображение ниже в виде веб-страницы.

Скопируйте адрес HTTPS. Теперь создадим пульт для нашего репозитория.

  git remote add origin [HTTPS ADDRESS]  

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

  git remote  

И если он выводит «origin» вы добавили пульт в свой проект.

ПРИМЕЧАНИЕ : Просто помните, что мы можем указать любое имя для пульта дистанционного управления, изменив имя «origin». Например:

  git remote add [REMOTE NAME] [HTTPS ADDRESS]  

Теперь мы можем без проблем отправить наш проект на GitHub!

  git push origin master  

После выполнения этих шагов один за другим, если вы перейдете на GitHub, вы сможете найти свой репозиторий с файлами!

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

Посмотрите мою оригинальную статью в Medium.

Спасибо.

Удачного кодирования!

Как использовать GitHub | GitHub Tutorial For Beginners

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

В этом блоге «Как использовать Github» вы узнаете:

Шаг 1. Что такое Github?

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

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

Почему Github так популярен?

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

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

Теперь позвольте мне перечислить способы, которыми GitHub упрощает git:

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

Итак, приступим к работе с GitHub.

Шаг 2. Как создать репозиторий GitHub?

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

  • Перейдите по ссылке: https://github.com/. Заполните форму регистрации и нажмите «Зарегистрироваться на Github».
  • Щелкните «Начать новый проект».

См. Снимок экрана ниже, чтобы лучше понять.

  • Введите любое имя репозитория и нажмите «Создать репозиторий».Вы также можете дать описание своему репозиторию (необязательно).

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

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

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

Шаг 3: Создание веток и выполнение операций

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

Как показано на изображении выше, существует ветвь master / production, у которой есть новая ветка для тестирования. В этой ветке выполняются два набора изменений, и по завершении они объединяются обратно в основную ветвь. Вот как работает ветвление!
Давайте поговорим о том, как использовать блог GitHub, и узнаем, как создать ветку.

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

  • Щелкните раскрывающийся список «Branch: master»
  • Как только вы нажмете на ветку, вы сможете найти существующую ветку или создать новую. .В моем случае я создаю новую ветку с именем «readme- changes». Обратитесь к приведенному ниже снимку экрана для лучшего понимания.

После того, как вы создали новую ветку, у вас теперь есть две ветки в вашем репозитории, то есть read-me (основная ветка) и readme- changes. Новая ветка — это просто копия основной ветки. Итак, давайте внесем некоторые изменения в нашу новую ветку и сделаем ее отличной от основной.

Как использовать GitHub: Операции
Команда фиксации:

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

  • Щелкните файл «readme-changes», который мы только что создали.
  • Щелкните значок «редактировать» или значок карандаша в правом верхнем углу файла.
  • Как только вы нажмете на это, откроется редактор, где вы можете ввести изменения или что-то еще.
  • Напишите сообщение фиксации, которое идентифицирует ваши изменения.
  • В конце нажмите «Принять изменения».

Обратитесь к приведенному ниже снимку экрана для лучшего понимания:

Мы успешно сделали нашу первую фиксацию. Теперь этот файл «readme-changes» отличается от основной ветки.Затем давайте посмотрим, как мы можем открыть запрос на перенос.

Как использовать GitHub | Что такое GitHub | Учебное пособие по Git и GitHub | Обучение DevOps | Edureka

Эта Edureka «Как использовать GitHub» даст вам практическую демонстрацию того, как получить доступ к GitHub и работать с его различными операциями.

Команда извлечения

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

  • Щелкните вкладку «Запросы на вытягивание».
  • Нажмите «Новый запрос на извлечение».
  • После того, как вы нажмете запрос на вытягивание, выберите ветку и щелкните файл «readme-changes», чтобы просмотреть изменения между двумя файлами, присутствующими в нашем репозитории.
  • Щелкните «Создать запрос на вытягивание».
  • Введите любой заголовок, описание ваших изменений и нажмите «Создать запрос на вытягивание». См. Скриншоты ниже.

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

Команда слияния

А вот и последняя команда, которая объединяет изменения в главную главную ветвь. Мы увидели изменения в розовом и зеленом цвете, теперь давайте объединим файл «readme-changes» с основной веткой / read-me.Выполните следующие шаги, чтобы объединить пулреквест.

  • Щелкните «Merge pull request», чтобы объединить изменения в главную ветку.
  • Нажмите «Подтвердить слияние».
  • Вы можете удалить ветку после того, как все изменения будут внесены, и если нет конфликтов. См. Скриншоты ниже.

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

Шаг 4: Клонирование и форк репозитория GitHub

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

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

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

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

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

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

  • Перейдите в раздел «Обзор» и выполните поиск общедоступных репозиториев.
  • Щелкните «вилка». Обратите внимание, что это «касательное» хранилище уже было разветвлено 27 раз и находится под учетной записью «google» . См. Изображение ниже для лучшего понимания.

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

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

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

Если вы нашли этот блог «Как использовать GitHub » релевантным, ознакомьтесь с курсом DevOps от Edureka, надежной компании онлайн-обучения с сетью более 250 000 человек. ученики распространяются по всему миру.Курс Edureka DevOps Certification Training помогает учащимся получить опыт работы с различными процессами и инструментами DevOps, такими как Puppet, Jenkins, Nagios и GIT, для автоматизации нескольких этапов в SDLC.

Git и GitHub в двух словах: подробное руководство для начинающих


Добавление Git в существующий проект

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

  1. Убедитесь, что в вашем терминале вы находитесь в каталоге проекта,
  2. Инициализировать git с помощью git init
  3. Создайте файл .gitignore и укажите файлы и папки, которые следует игнорировать (если в этом нет необходимости, вы можете перейти к шагу 4)
  4. Настройте файлы с помощью git add. Зафиксируйте свои изменения соответствующим сообщением о фиксации, например: git commit -m "первая фиксация"

1. Работа с пультами

Давайте создадим удаленный репозиторий на GitHub. Как только вы войдете в систему и окажетесь на главной странице, вы увидите кнопку в верхнем левом углу под названием «Новый» (см. Рисунок ниже).

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

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

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

В нашем проекте уже есть файл README и .gitignore , поэтому мы можем не отмечать параметры инициализации с README и .gitignore .


2. Отправка кода на GitHub

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

Git предоставляет удаленную команду, чтобы помочь в этом. Команда git remote позволяет Git отслеживать удаленные репозитории и связывать локальные репозитории с этими удаленными. Например, предположим, что мы хотим добавить наш удаленный репозиторий к локальному. Формат команды:

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

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

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

Примечание: Источник имени — это, по сути, более понятный для человека способ ссылки на удаленный репозиторий вместо того, чтобы всегда использовать фактический URL-адрес. origin — просто условное имя, но мы можем использовать и любое другое имя.

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

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

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

  git add.

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

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

  git push origin master
  

Вот и все. Вы успешно отправили свой код в удаленный репозиторий.


3. Обновление локального репозитория

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

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

GitHub Primer для чайников. Простое руководство по использованию GitHub для размещения… | Сэм Либман

К сожалению, нажатие создать репозиторий — это только первый шаг в этом процессе (спойлер: на самом деле это не создает ваше репозиторий). Следующий шаг включает использование вашего терминала для инициализации вашего Git и отправки вашего первого коммита.Git — это не то же самое, что GitHub, хотя они связаны. Git — это система контроля версий, которая помогает управлять историей исходного кода и правками, а GitHub — это веб-сайт, на котором размещены репозитории Git. Проще говоря, Git делает снимок вашего проекта во время каждой фиксации и сохраняет ссылку на это точное состояние. Чтобы инициализировать Git для вашего проекта, с помощью терминала войдите в каталог на вашем компьютере, где он хранится, и введите git init в командную строку. Введите git add FILENAME , чтобы загрузить свой первый файл.Следующий шаг — сделать вашу первую фиксацию или ревизию. Введите git commit -m "ваш комментарий здесь" в командную строку. Комментарий должен содержать краткие сведения о том, какие изменения были внесены, чтобы вам было легче отслеживать свои изменения. Фиксация добавляет изменения в локальный репозиторий, но не отправляет изменения на удаленный сервер. Следующим шагом является ввод git remote add origin https: //project_repo_link.git в командную строку, чтобы создать удаленный сервер на GitHub, на котором будет размещаться ваша работа.Наконец, введите git push -u origin master , чтобы отправить изменения на удаленный сервер и сохранить свою работу.

Данные Git хранятся в виде снимков проекта с течением времени — Источник: https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

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

Процесс добавления изменений в ваше репозиторий GitHub похоже на процесс инициализации. Вы можете добавить все файлы в каталог проекта одним махом или добавить каждый файл отдельно по мере внесения изменений.По множеству причин, обнаруженных методом проб и ошибок, я настоятельно рекомендую загружать каждый файл отдельно. Во-первых, он будет содержать ваш репозиторий в чистоте и порядке, что полезно при предоставлении ссылок на ваш профиль / репозиторий GitHub в LinkedIn, резюме или заявления о приеме на работу. Во-вторых, это позволит вам отслеживать изменения в каждом файле отдельно, а не выдвигать расплывчатое описание фиксации. В-третьих, это предотвратит случайное добавление файлов, которые не предназначались для добавления в ваше репо.Это могут быть файлы, содержащие личную информацию, например ключи API, которые могут быть опасны при публикации в открытом доступе. Это также предотвратит загрузку наборов данных, размер которых превышает 100 МБ, что является пределом размера для бесплатных учетных записей. После того, как файл добавлен в репозиторий, его чрезвычайно сложно удалить, даже если он еще не был отправлен или зафиксирован. Исходя из опыта, мне приходилось многократно удалять репозиторий после случайной загрузки файла, который мне не нужен, поэтому я подчеркиваю важность тщательного выбора файлов для загрузки.

Интерфейс Vim

Чтобы добавить новый файл, войдите в каталог проекта через терминал и введите git add FILENAME в командную строку. Для совершения фиксации есть два варианта: вы можете выполнить тот же процесс, что и при создании репо, и ввести git commit -m "описание фиксации" или использовать Vim, текстовый редактор на основе Unix для обработки изменений. Vim — это нелогичный текстовый редактор, который реагирует только на клавиатуру (без мыши), но предоставляет несколько сочетаний клавиш, которые можно перенастроить, а также возможность создавать новые персонализированные сочетания клавиш.Чтобы войти в текстовый редактор Vim, введите в командной строке git commit и нажмите клавишу ВВОД. Это приведет вас к редактору Vim; чтобы перейти к написанию вашего коммита, введите i , чтобы войти в режим --INSERT-- , а затем введите свое сообщение о коммите. После завершения нажмите esc , чтобы выйти из режима --INSERT - , а затем сохраните и выйдите из Vim, введя : wq , чтобы написать и выйти из текстового редактора. Оттуда все, что вам нужно сделать, это ввести git push в командную строку, чтобы отправить ваши изменения в GitHub.

Git Ignore

Чтобы игнорировать определенные файлы при отправке в репо, вы можете создать файл .gitignore , который указывает намеренно неотслеживаемые файлы, которые следует игнорировать. Чтобы создать файл, нажмите кнопку новый файл на домашней странице репозитория и назовите файл .gitignore или используйте один из предоставленных образцов шаблонов. Есть несколько способов указать файл или папку, которые нужно игнорировать. Первый способ — просто написать имя файла в .gitignore файл. Например, если у вас есть файл с именем AWS-API-KEY-DO-NOT-STEAL.py , вы можете записать имя этого файла с расширением в файл .gitignore .

Создание файла .gitignore на GitHub

Чтобы игнорировать все имена файлов с определенным расширением, например файлы .txt, введите * .txt в файл .gitignore . Наконец, вы можете игнорировать всю папку, набрав в файле имя_папки / . После того, как вы добавили все файлы, которые вы хотите игнорировать, в .gitignore , сохраните его и поместите в корневую папку вашего проекта. Теперь, если вы попытаетесь добавить и отправить эти файлы в репозиторий, они будут проигнорированы и не будут включены в репозиторий. Однако, если файлы уже были добавлены в репо перед добавлением в файл .gitignore , они все равно будут видны в репозитории Git.

Разветвления и ответвления

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

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

Microsoft выпускает автоматизированного чат-бота поддержки GitHub.

Филиалы можно создавать локально с вашего терминала, если у вас есть клонированная версия репозитория, сохраненная локально.Чтобы увидеть все ветки в вашем репо, введите git branch в командную строку из каталога вашего проекта. Если ветви не были созданы, на выходе должно быть * master , со звездочкой, указывающей, что ветвь в настоящее время активна. Чтобы создать новую ветку, введите git branch , а затем введите git checkout , чтобы переключиться на новую ветку, чтобы вы могли работать с ней. Команда git checkout позволяет пользователю перемещаться между различными ветвями репозитория.Фиксация изменений в ветке происходит так же, как фиксация в мастере, только убедитесь, что вы знаете, в какой ветке вы работаете.

GIT для чайников — DEV Community

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

Хорошо, обо всем по порядку. Вы хотите начать новый проект. С чего начать? Если бы я был новичком в git / GitHub и хотел бы иметь самую простую настройку, я бы начал с создания репо на Github. Запуск этого способа позволит вам избежать подключения существующего проекта на локальном компьютере к удаленному репозиторию на GitHub.(Да, есть сайты, отличные от Github, но если вы начинаете, вероятно, именно там вы и находитесь)

Итак, зайдите в Github, создайте новый репозиторий для своего проекта, а затем приступим к командам …

git clone

В новом репо вы получаете область с надписью «Быстрая установка со ссылкой на ваше репо. Скопируйте это.


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

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

git clone your_repo_link_here

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

git pull origin master

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

git pull origin master

Краткое примечание о том, что такое УДАЛЕННЫЙ репозиторий.Когда на вашем компьютере локально запущен git, это репозиторий, как и репозиторий на Github. Термин удаленный относится к репозиторию в другом месте. Чаще всего в начале, особенно в этом руководстве, удаленный репозиторий также является «источником», откуда репозиторий был изначально клонирован. Но вы можете иметь несколько удаленных репозиториев, настроенных, например, на разных компьютерах, и иметь возможность обновлять их все с одного компьютера. В этом случае удаленный репозиторий просто означает репо на Github, которое мы начали с

.

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

В будущем вы можете работать над другими ветвями репозитория, в этом случае вы можете загрузить код из Github, набрав git pull origin what_branch_name_here .

git checkout

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

Мой любимый способ создать новую ветку — использовать команду git checkout -b new-branch-name .Технически есть команда git branch для создания ветки и команда git checkout для переключения на ветку, но git checkout -b с именем после позволяет вам создать новую ветку и переключиться на все это сразу!

git добавить

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

Очень важное замечание, вы, вероятно, захотите добавить файл .gitignore в корень вашего проекта. Здесь вы можете добавлять файлы для автоматического игнорирования. Вы определенно захотите добавить node_modules , а также другие вещи, которые вы не хотите отслеживать, такие как переменные .env или сгенерированные папки из таких вещей, как Next, Gatsby, create-response-app и т. Д.Вы делаете это, вводя имя файла и / или папки в каждой строке отдельно.

Я обычно стараюсь делать это регулярно, поскольку работаю над каждым конкретным аспектом / функцией, поэтому обычно я добавляю все свои файлы сразу в промежуточную область, набирая git add * , но при желании вы можете добавлять файлы по отдельности используя git add filepath / name_here .

git совершить

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

Итак, чтобы сделать коммит, мы используем команду:
git commit -m 'здесь описательное сообщение'

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

git push

Теперь та часть, которая действительно синхронизирует вещи!

До сих пор в основном все было на вашем локальном компьютере, но как только вы сделаете коммит (или несколько), мы можем отправить все коммиты на Github, и исходное / удаленное репо онлайн будет отражать то, что у нас есть на нашем машина.

Поскольку вы ДОЛЖНЫ работать с веткой, вы должны использовать команду:
git push origin the_branch_name

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

Если вы непослушный или просто работаете над своим собственным проектом, вы также можете сделать:
git push origin master
, который обходит процесс PR и немедленно переносит ваш новый код в главную ветку. Не делай этого.

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

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

  1. git pull origin master : убедитесь, что все обновлено! Вы также можете извлечь из ветки, над которой вы работаете, вместо основной ветки, используя git pull origin branch_name .
  2. git checkout -b some-branch-name : Создать и оформить заказ (перейти) и создать новую ветку для вашей работы, чтобы вы не испортили то, что делают другие.
  3. git add * : добавьте все файлы, которые вы изменили, чтобы вы могли сделать фиксацию, как только вы действительно что-то сделали.
  4. `git commit -m ‘некоторый полезный комментарий’: Зафиксируйте свои изменения, чтобы вы могли отправить их в удаленный репозиторий.
  5. git push origin branch-name : отправьте все ваши коммиты в удаленный репозиторий на Github в вашу конкретную ветку.
  6. Сделайте пиар на Github. Ваш код после нажатия все еще находится в отдельной ветке в сети, поэтому вам нужно сделать запрос на перенос, чтобы объединить его с основной кодовой базой.

Отличная работа! Вы работали, синхронизировали все и, надеюсь, не испортили чужой код!

.