Github — Затруднения с gitgithub


Содержание

Github — Затруднения с git/github

/Maks/android-kernel-zzz
git init — инициализируем репозиторий
git add . — помечаем для выгрузки все файлы в

/Maks/android-kernel-zzz
git commit -m «first commit» — коммитим изменения, вместо first commit можно написать, что угодно.
git remote add origin https://github.com/твой_ник/имя_репозитория.git
git push -u origin master — после ввода команды попросит пароль.

Тема в стадии развития!

Сообщение отредактировал AndrewP_1 — 29.04.19, 12:01

Предложу альтернативу. :wink_kind:

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

Интеграция чужих наработок в свой репозиторий

  • git remote add name [url репозитория]
  • git fetch name
  • git cherry-pick [id коммита]

Где name это условное имя ветки (может быть каким угодно)

  • Git или Гит — система контроля и управления версиями файлов.
  • GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.
  • Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.
  • Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются на удалённый репозиторий.
  • Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.
  • Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.
  • Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.
  • Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.
  • Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.
  • Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.
  • Мастер (Master) — главная или основная ветка репозитория.
  • Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.
  • Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
  • Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.
  • Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.
  • Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

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

Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

Тогда эта статья специально для вас!

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

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

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте Стене на GitHub.

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

Что такое Git и GitHub?

Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. Это настоящая Мекка для технарей. Здесь вы можете попрактиковаться в разработке и придумать что-то свое, найти множество open-source проектов, передовых технологий, различных функций и дизайнов.

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

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

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

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

Пример: git add . Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py .

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

Затем к ним добавим еще вот эти:

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

Не лишней будет и вот такая команда:

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

(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal ).

Шаг 1: Регистрация и установка

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

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

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

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

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

Теперь вы готовы к работе с Git на локальном компьютере.

Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта.

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

Если у вас есть директория проекта, то просто перейдите в терминал, а в самой директории проекта выполните команду

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

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

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

или добавьте сразу все файлы через:

Создать коммит с этими изменениями можно через команду:

Если изменения вас устраивают, напишите:

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

При внесении изменений следует обновить и сами файлы:

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master .

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

Допустим, вы хотите создать новый репозиторий. Это место, где будет «жить » ваш проект. Если вы не хотите создавать новый репозиторий, то можете склонировать уже существующий. Именно так вы копируете чужой проект или берете нужную вам информацию для работы/учебы. Мы еще к этому вернемся, но чуть позже.

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

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

  • Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
  • Придумайте имя репозитория и добавьте короткое описание.
  • Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
  • Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

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

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

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

  • Для начала перейдите в ваш репозиторий.
  • Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
  • В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
  • Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
  • Нажмите кнопку Commit changes.

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request. Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

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

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

Затем клонируйте туда репозиторий по следующей команде:

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd . Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop . Либо напечатайте cd Desktop . Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop , вам потребуется выбрать нужного пользователя через команду cd (замените на нужное вам имя). Затем снова напечатайте ls , чтобы увидеть весь список. И вот теперь, увидев в списке Desktop , смело печатайте cd Desktop . Сейчас уже можно выполнять git clone !

Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

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

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

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

Добавляем файлы в проект

Вот, чем мы займемся:

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:


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

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

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

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать <> . После внесения изменений создается снимок состояния репозитория, для чего используется команда commit . А через –m добавляется сообщение об этом снимке.

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

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

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

Актуальность версии можно проверить в любое время через команду git status .

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

Урок 6. Git и Github. Репозиторий на Github

Дата публикации: 31-08-2020

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

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

#5 — Введение в GitHub. Работа с удаленным репозиторием

Видеоурок

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

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

  1. Как подключиться к удаленному репозитарию?
Цукерберг рекомендует:  Библиотека Numpy

Для загрузки данных в удаленный репозитарию сначала нужно к нему подключиться. В нашем примере мы используем адрес https://github.com/tutorialzine/awesome-project, однако пользователь может создать собственный удаленный репозитарий на GitHub, BitBucket или другом подобном сервисе. Это занимает некоторое время, однако в дальнейшем полностью себя оправдывает, тем более, что подобные службы имеют пошаговые инструкции для правильно выполнения нужных действий.

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

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

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

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

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

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

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

  1. Как клонировать удаленный репозитарий?

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

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

  1. Как запросить изменения с удаленного репозитария?

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

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

Основы Git. Как работает Git?

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

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

Как работать с Git?

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

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

Обычно, команды Git имеют следующий вид:

В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые — либо — . Они обеспечивают более детальную настройку действия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <> , вы можете менять на собственные значения.

Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help . Если просто нужно напоминание, применяйте git -h либо git —help (в Git -h и —help имеют одинаковое значение).

Установка Git

Если вы пользуетесь Windows, качайте Git отсюда. Что касается macOS, то здесь Git поставляется как часть инструмента командной строки XCode. Наличие Git можно проверить, открыв терминал и набрав git —version . Для Linux используйте команду sudo apt install git-all либо sudo dnf install git-all .

Настраиваем конфигурационный файл

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

Вы можете отредактировать файл .gitconfig напрямую с помощью редактора или, используя команду git config —global —edit . Чтобы отредактировать отдельные поля, подойдёт git config —global — здесь нас интересуют поля user.email и user.name.

Кроме того, есть возможность настройки текстового редактора для написания сообщений коммитов — это поле core.editor. По умолчанию применяется системный редактор. Поле commit.template служит для указания шаблона, который будет задействоваться при каждом коммите.

Есть и много других полей, но самое полезное — alias (привязывает команду к псевдониму). К примеру, git config —global alias.st «status -s» позволит использовать git st вместо git status –s.

А git config —list выведет все поля с их значениями из конфигурационного файла.

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

Чтобы инициализировать новый репозиторий .git используют команду git init . Если хотите скопировать уже существующий репозиторий — git clone .

История коммитов в Git

Git хранит имеющиеся данные в виде набора «снимков», называемых коммитами. Коммиты хранят состояние файловой системы в конкретный момент времени, а также имеют указатель на предыдущие коммиты. Каждый коммит содержит уникальный контрольный идентификатор, который используется Git, чтобы ссылаться на этот коммит. Для отслеживания истории Git хранит указатель HEAD, указывающий на 1-й коммит.

Ссылаться можно как через контрольную сумму коммита, так и через его позицию относительно HEAD. К примеру, HEAD

4 будет ссылаться на коммит, находящийся 4-мя коммитами ранее HEAD.

Система файлов в Git

Git может отслеживать файлы в 3-х основных разделах: — рабочая директория (речь идёт о файловой системе вашего ПК); — область подготовленных файлов (это staging area, где хранится содержание следующего коммита); — HEAD (последний в репозитории коммит).

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

Для этого используют команду git status . Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния: 1) untracked (неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает; 2) modified (изменён). В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите); 3) staged (подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту; 4) без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.

Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать: — git diff — для сравнения рабочей директории с областью подготовленных файлов; — git diff —staged — для сравнения области подготовленных файлов с HEAD.

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

Игнорирование файлов

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

Для игнорирования предусмотрен файл .gitignore, где отмечаются файлы для игнорирования.

Коммиты

Основой истории версий являются коммиты. Для работы с ними используют git commit — эта команда откроет текстовый редактор для ввода сообщения коммита. Кроме того, она принимает следующие аргументы: • -m — позволяет написать сообщение, не открывая редактор, то есть вместе с командой; • -a — служит для переноса всех отслеживаемых файлов в область подготовленных файлов и включения их в коммит (даёт возможность перед коммитом пропустить git add); • —amend — заменяет последний коммит новым изменённым коммитом. Это бывает полезно, когда вы неправильно наберёте сообщение последнего коммита либо забудете включить в него нужные файлы.

Ряд советов по коммитам: — коммитьте часто; — одно изменение — один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю); — комментируя сообщение о коммите, логически дополняйте фразу this commit will ___ и не используйте более 50 символов.

Удалённые серверы

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

Для вывода списка удалённых репозиториев нужна команда git remote –v . С её помощью мы не только загружаем копию репозитория, но и отслеживаем удалённый сервер, находящийся по указанному адресу (ему присваивается имя origin).

Другие часто употребляемые команды: • git remote add — добавляется удалённый репозиторий с заданным именем; • git remote remove — удаляется удалённый репозиторий с заданным именем; • git remote rename — переименовывается удалённый репозиторий; • git remote set-url — репозиторию с именем присваивается новый адрес; • git remote show — показывается информация о репозитории.

Следующий список нужен для работы с удалёнными ветками: • git fetch — для получения данных из ветки заданного репозитория; • git pull — сливает данные из ветки; • git push — для отправления изменения в ветку заданного репозитория. Когда локальная ветка отслеживает удалённую, достаточно использовать git push или git pull .

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

Ветвление в Git

Ключевая особенность Git — ветвление, позволяющее работать над разными версиями проекта. Таким образом, вместо одного перечня с упорядоченными коммитами история может расходиться в некоторых точках, поэтому становится похожей на дерево. И каждая ветвь содержит в Git легковесный указатель HEAD, указывающий на последний коммит в данной ветке. В результате можно легко создать много веток. Делая это, называйте ветки согласно разрабатываемой функциональности. Ветку по умолчанию называют master.

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

Стандартные команды при ветвлении в Git: • git branch — для создания новой ветки с HEAD, указывающим на HEAD. Если аргумент передан не будет, команда выведет список всех имеющихся локальных веток; • git branch -d — для удаления ветки; • git checkout — для переключения на эту ветку. Если хотим создать новую ветку перед переключением, можем передать опцию –b.

И локальный, и удалённый репозиторий могут иметь много веток, поэтому при отслеживании на деле отслеживается удалённая ветка, то есть git clone привязывает ветвь master к ветви origin/master удалённого репозитория.

Парочка команд для привязывания к удалённой ветке: • git branch -u / —текущая ветка привязывается к указанной удалённой ветке; • git checkout —track / — аналогично; • git checkout -b / — создаётся новая локальная ветвь и начинает отслеживать удалённую; • git checkout — создаётся локальная ветвь с таким же именем, как и у удалённой, плюс начинает её отслеживать; • git branch —vv — служит, чтобы показать локальные и отслеживаемые удалённые ветки.

Совмещение веток

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

Слияние

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

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

Маркеры разрешения конфликта:

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

Перемещение


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

Чтобы выполнить перемещение, используют команду git rebase . Она воспроизводит изменения тематической ветви на основной. При этом HEAD тематической ветви указывает на последний воспроизведённый коммит.

Совет: перемещайте изменения лишь на вашей приватной локальной ветке. Не стоит перемещать коммиты, от которых ещё кто-то зависит.

Если хотите откатить коммит: — git revert — создаёт новый коммит, который отменяет изменения, но сохраняет историю; — git reset — перемещает указатель HEAD, и создаёт более чистую историю, как будто коммита никогда не было. Но это также значит, что вы не сможете вернуться обратно к изменениям, если решите, что отмена была лишней. В общем, чище — не значит лучше!

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка в Linux

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

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

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

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

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

Установка в Windows

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

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

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

Настройка Git

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

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

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

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

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

Что такое GitHub?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    /.ssh/

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      GitHub vs GitLab Кто лучше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Как пользоваться GitHub на компьютере с Linux

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

      В данной статье приведены примеры использования сервиса на компьютере под управлением операционных систем семейства Linux. Мы рассмотрим, как создать проект на локальном компьютере и залить его на сервис с помощью командной строки. Рассмотренные варианты использования git также можно применять на desktop системах, запустив окно терминала.

      Установка git

      Управление выполняется с помощью приложения git. Если его нет в системе, установку можно выполнить из репозитория.

      Если используем CentOS / Red Hat:

      yum install git-core

      Если используем Ubuntu / Debian:

      apt-get install git

      Если мы хотим воспользоваться сервисом с компьютера Windows или Mac OS, необходимо скачать и установить desktop версию с официального сайта.

      Синтаксис

      Команды имеют следующий синтаксис:

      * полный перечень опций, команд и аргументов можно получить командой man git.

      Создание проекта на локальном компьютере

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

      Инициализируем проект для git:

      Мы получим ответ похожий на:

      Initialized empty Git repository in /projects/.git/

      Это означает, что репозиторий git создан.

      Теперь добавим файлы в репозиторий:

      * данной командой мы добавили папку и ее содержимое в репозиторий git.

      Отправка данных на GitHub


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

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

      Переходим на портал github.com и входим в систему или проходим несложную регистрацию:

      Проходим процесс подтверждения, что мы не робот. Затем завершаем несколько шагов регистрации, нажимая Submit. В итоге мы получим письмо на адрес электронной почты, которую указали при регистрации. Необходимо будем подтвердить email, перейдя в письме по кнопке Verify email address.

      Создаем репозиторий. Для этого кликаем по иконке профиля и переходим в раздел Your repositories:

      И кликаем по кнопке New. В следующем окне даем название репозиторию и нажимаем Create repository:

      Мы увидим страницу с путем к репозиторию:

      Заливаем проект в репозиторий на GitHub

      Добавляем комментарий к нашему проекту:

      git commit -m «Очередное изменение проекта» -a

      * где Очередное изменение проекта — произвольный комментарий; параметр -a указывает, что комментарий нужно применить ко всем измененным файлам.

      Теперь подключаемся к созданному репозиторию:

      git remote add origin https://github.com/dmosktest/project1.git

      * где dmosktest — логин, который был указан при регистрации на github, а project1 — название, которое мы задали, когда создавали репозиторий.
      * удалить удаленный репозиторий можно командой git remote rm origin.

      Закидываем проект на GitHub:

      git push origin master

      * где master — ветка проекта (веток может быть несколько).

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

      Получение файлов с GitHub

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

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

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

      git remote add origin https://github.com/dmosktest/project1.git

      Скачиваем проект командой:

      git pull https://github.com/dmosktest/project1.git master

      Клонирование проекта

      Например, использую наш репозиторий:

      git clone https://github.com/dmosktest/project1.git

      * данная команда создаст в текущей папке каталог project1 и инициализирует его как локальный репозиторий git. Также загрузит файлы проекта.

      Возможные ошибки

      1. При попытке отправить данные на GitHub, получаем ошибку:

      error: src refspec master does not match any.
      error: failed to push some refs to ‘https://github.com/dmosktest/project1.git’

      * где dmosktest/project1.git — путь к нашему репозиторию.

      Причина: проект ни разу не был зафиксирован (закоммичен).

      Решение: добавляем комментарий к нашему проекту:

      GitHub vs GitLab Кто лучше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Работа с Git на хостинге

      Что такое Git?

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

      Для создания проекта (например, сайта) с использованием Git вам понадобится:

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

      Удалённый репозиторий — система управления репозиториями кода для Git. Например: GitHub, GitLab, Bitbucket. После завершения локальной работы над кодом каждый разработчик проекта отправляет свою часть кода или изменения в удалённый репозиторий, где всё сливается (merge) воедино, а затем разворачивается (deploy) на сервер проекта.

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

      На хостинге REG.RU установлен Git, благодаря чему вы сможете упростить процесс разработки и публикации сайта. Обратите внимание: на хостинге REG.RU по умолчанию используется Git версии 1.7.1. Для запуска версии 2.19.2 используйте алиас git2192.

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

      Подготовка к работе

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

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

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

      Создайте коммит с помощью команды

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

      Отправка изменений в удалённый репозиторий

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

      На локальном компьютере, в терминале, добавьте ссылку удалённого репозитория с помощью команды:

      Затем отправьте изменения в удалённый репозиторий с помощью команды:

      Система запросит ваш логин и пароль от GitHub.

      Готово. После завершения отправки ваши файлы появятся в удалённом репозитории на GitHub.

      Публикация сайта с GitHub на хостинг

      Чтобы клонировать изменения с GitHub на хостинг REG.RU:

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

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

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

      Цукерберг рекомендует:  Портативный монитор - Выбор портативного монитора для ноутбука
  • Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих