10 репозиториев на GitHub для новичка


Оглавление (нажмите, чтобы открыть):

Начинаем работать с git — пошаговая инструкция

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

Наверное, пора узнать…

Секреты командной разработки

Разработка – это почти всегда командная игра. Пора учиться работать в команде.
Даже если пока что в твоей команде только монитор, системник (или старенький ноутбук) и острое желание стать программистом, всё равно пора учиться.

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

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

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

Шаг 1. Выбираем git-хостинг

Git-хостинг на разных условиях предлагают десятки компаний.
Самые известные из них: Github, Sourceforge, Google Code, GitLab, Codebase. Выбери удобный интерфейс и регистрируйся на понравившемся хостинге.
В этой статье мы рассмотрим работу с git-хостингом на примере Github’а.

Шаг 2. Регистрация

Процедура регистрации на Гитхабе простая и интуитивно понятная даже для тех, чей уровень английского далёк от Upper Intermediate.

Логин, пароль, почта –> подтверждение, и связь с мировым сообществом программистов налажена.

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

Ты можешь создать любое количество репозиториев, у каждого из которых будет issue tracking, wiki, условия для проведения code review и многое другое.
Политика разработчиков Github предполагает бесплатное использование хостинга для всех open-source проектов.

Чтобы создать новый репозиторий нажмём кнопку + в верхней части экрана и выберем New repository

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




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

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


Жмём волшебную кнопку Create внизу экрана, и репозиторий готов.

Шаг 4. Работа с репозиторием

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

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

Шаг 5. Выбираем Гит-клиент

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

Но вернёмся к git-клиентам.

Самыми популярными гит- клиентами на данный момент являются:

SmartGit


Удобное приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.

GitHub Desktop

«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.

Зато отлично подходит для начала работы с git.

GitKraken


Поддерживает GitHub, Bitbucket и Gitlab.
Кракен очень любят программисты – фрилансеры, которым периодически приходится менять команды, а значит, и условия командной разработки. Возможность работы с разными git-хостингами через привычное приложение со знакомым интерфейсом в таких случаях играет важную роль.


SourceTree

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

Шаг 6. Работа со SmartGit


В этой статье мы рассмотрим работу с SmartGit.

Скачать SmartGit можно, например, отсюда:
Устанавливаем и запускаем.

Основные операции для работы с git


Clone


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


Затем копируем ссылку репозитория, созданного на Гитхабе (шаг 2)

Ссылка на репозиторий


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

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

Commit

Репозиторий готов – пора приступать к работе.
Написанный код мы помещаем в локальный репозиторий — папку .git (путь к которой мы указали в операции clone).

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


Если всё прошло успешно, в окошке SmartGit’а появится скопированный файл.

Новый файл в SmartGit



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

В открывшемся окне пишем пояснительный комментарий к сохраняемому файлу и снова нажимаем кнопку Commit

Пояснения к Commit’у



Файл сохранён, а изменения внесены в журнал.

Файл отправлен в локальный репозиторий

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



К слову, отправить изменения в удалённый репозиторий, нам предлагают ещё в точке Commit’а


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



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

Перенос информации из сторонних репозиториев на Гитхаб

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

Кнопка New gist на этой панели предназначена для мгновенного обмена информацией.

А кнопка New organization открывает массу возможностей для командной разработки.

Заключение

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

Благодаря своей политике (поддержка open-sourse проектов) Github предоставляет удивительную возможность детально рассматривать программы, написанные как новичками, так и признанными гениями – программистами.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 репозиториев на 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 — после ввода команды попросит пароль.

Мастер Йода рекомендует:  Задачка на Python расшифруйте строку

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

Сообщение отредактировал 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) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

.1 Основы Git — Создание Git-репозитория

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

Для создания Git-репозитория существуют два основных подхода. Первый подход — импорт в Git уже существующего проекта или каталога. Второй — клонирование уже существующего репозитория с сервера.

Создание репозитория в существующем каталоге

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

Эта команда создаёт в текущем каталоге новый подкаталог с именем .git содержащий все необходимые файлы репозитория — основу Git-репозитория. На этом этапе ваш проект ещё не находится под версионным контролем. (В главе 9 приведено подробное описание файлов содержащихся в только что созданном вами каталоге .git )

Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью нескольких команд git add указывающих индексируемые файлы, а затем commit :

Мы разберём, что делают эти команды чуть позже. На данном этапе, у вас есть Git-репозиторий с добавленными файлами и начальным коммитом.

Клонирование существующего репозитория

Если вы желаете получить копию существующего репозитория Git, например, проекта, в котором вы хотите поучаствовать, то вам нужна команда git clone . Если вы знакомы с другими системами контроля версий, такими как Subversion, то заметите, что команда называется clone , а не checkout . Это важное отличие — Git получает копию практически всех данных, что есть на сервере. Каждая версия каждого файла из истории проекта забирается (pulled) с сервера, когда вы выполняете git clone . Фактически, если серверный диск выйдет из строя, вы можете использовать любой из клонов на любом из клиентов, для того чтобы вернуть сервер в то состояние, в котором он находился в момент клонирования (вы можете потерять часть серверных перехватчиков (server-side hooks) и т.п., но все данные, помещённые под версионный контроль, будут сохранены, подробнее см. в главе 4).

Клонирование репозитория осуществляется командой git clone [url] . Например, если вы хотите клонировать библиотеку Ruby Git, известную как Grit, вы можете сделать это следующим образом:

Эта команда создаёт каталог с именем grit , инициализирует в нём каталог .git , скачивает все данные для этого репозитория и создаёт (checks out) рабочую копию последней версии. Если вы зайдёте в новый каталог grit , вы увидите в нём проектные файлы, пригодные для работы и использования. Если вы хотите клонировать репозиторий в каталог, отличный от grit , можно это указать в следующем параметре командной строки:

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

Git и GitHub на windows от новичка (часть 2)

Что такое публичный и приватный ssh-ключ? Эта пара ключей для одного пользователя? Если так, то для каждого пользователя я должен в настройки GitHub-а сохранить его публичный ключ? Или достаточно одного публичного ключа для всех?

Зачем нужен пароль (passphrase) для соединения по ssh к репозиторию на GitHub? Этот пароль нужен только для доступа к паре ssh ключей, которые хранятся в папке

/.ssh ( имя_пользователя/.shh )? Или этот пароль так же знает репозиторий на GitHub?

Пара ключей ssh хранится в папке пользователя на винде. Если я захочу присоединиться к другому репозиторию по ssh, то значит мне надо будет изменить эту пару ssh ключей?

Если удалить ветку, то удаляться и все его коммиты? Хотя если подумать, то ветка это всего лишь указатель на коммит, значит удалится этот указатель, а не сами коммиты. Так?

Я уже запутался с этими командами перехода_на_коммит / изменения_коммита / удаления_коммитов и т. п. Какие именно команды удаляют коммиты навсегда, а не просто из виду убирают? reset (soft/hard)? revert ? еще что-нибудь?

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

MS Visual Studio 2010 создал файл main.cpp . При попытки его (и другие файлы с кодом от MS VS) индексировать выводится ошибка:

Fatal: CRLF would be replaced by LF in main.cpp.

Искал в гугле и что-то было про это, но как решить эту проблему я не понял.

1 ответ 1

1) Что такое публичный и приватный ssh-ключ?


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

Эта пара ключей для одного пользователя?

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

Если так, то для каждого пользователя я должен в настройки GitHub’а сохранить его публичный ключ? Или достаточно одного публичного ключа для всех?

Насколько мне известно github не позволяет использовать один и тот же ключ в нескольких аккаунтах. Придётся генерировать пару для каждого аккаунта.

2) Зачем нужен пароль(passphrase) для соединения по ssh к репозиторию на GitHub?

Чтобы повысить уровень защиты. Оберегает доступ в случае кражи приватного ключа.

Этот пароль нужен только для доступа к паре ssh ключей, которые хранятся в папке

/.ssh(имя_пользователя/.shh)? Или этот пароль так же знает репозиторий на GitHub?

Этот пароль никакого отношения к github не имеет, только к ключу. Указывается в момент генерации ключа.

3)Пара ключей ssh хранится в папке пользователя на винде. Если я захочу присоединиться к другому репозиторию по ssh, то значит мне надо будет изменить эту пару ssh ключей?

Нет. Ключи используются для доступа к серверу с определённого компьютера. Можно сгенерировать пару, и использовать её для доступа к github, bitbucket, какие-то свои сервера. Ну и добавив ключ в настройках аккаунта вы пользуетесь им для работы со всеми репозиториями которые предоставляет сервис.

4) Если удалить ветку, то удаляться и все его коммиты? Хотя если подумать, то ветка это всего лишь указатель на коммит, значит удалится этот указатель, а не сами коммиты. Так?

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

5)Я уже запутался с этими командами перехода_на_коммит/изменения_коммита/удаления_коммитов и т.п. Какие именно команды удаляют коммиты навсегда, а не просто из виду убирают? reset(soft/hard)? revert? еще что-нибудь?

revert не удаляет, лишь обращает изменения новым коммитом.

По-вопросу: не знаю, мне всегда хватало reset .

6)Как сделать так, чтобы перестало просить пароль при использовании ssh соединения? Например, когда использую git push или git fetch.

Сгенерировать новый ключ, во время ввода пароля ничего не вводить.

7)MS Visual Studio 2010 создал файл main.cpp. При попытки его(и другие файлы с кодом от MS VS) индексировать ошибка: Fatal: CRLF would be replaced by LF in main.cpp. Искал в гугле и что-то было про это, но как решить эту проблему я не понял.

Windows-specific problem. По-идее ничего страшного, на SO предлагают добавить

сижу на линуксах, поэтому тут помочь не могу.

ДОБАВЛЕНО:

А что если через один аккаунт, но на разных компьютерах или пользователей в винде?

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

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

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

10 альтернатив GitHub, который купила Microsoft

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

4 июня состоялась сделка Microsoft по покупке GitHub за 7,5 миллиарда долларов, о чём рассказали в блоге GitHub. GitHub — крупнейший в мире веб-сервис для хостинга и совместной разработки IT-проектов. Его покупка корпорацией Microsoft шокировала многих пользователей, особенно приверженцев и разработчиков Open Source.

У Microsoft есть одна неприятная особенность. Собственные разработки компании хороши, но когда Microsoft покупает какой-нибудь популярный проект вроде Skype, LinkedIn, Nokia или Wunderlist, то в лучшем случае его ожидает стагнация, в худшем — деградация. Пользователи GitHub перевели больше 40 тысяч проектов на другие веб-сервисы. Хештег #movingtogitlab на Twitter использовали почти 3 тысячи раз.

Мастер Йода рекомендует:  3 популярных VPN-сервиса оказались не защищены от утечки пользовательских IP-адресов

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

1. GitLab


GitLab — альтернатива GitHub номер один. GitLab предоставляет не только веб-сервис для совместной работы, но и программное обеспечение с открытым исходным кодом.

Многие проекты с открытым исходным кодом, такие как GNOME и GIMP, используют GitLab.

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

Стоимость

  • Core — бесплатная версия GitLab. Для развёртывания на вашем собственном хостинге или сервере.
  • Starter — 4 доллара в месяц с каждого пользователя. Для небольших команд.
  • Premium — 19 долларов в месяц с каждого пользователя. Для организаций.
  • Ultimate — 99 долларов в месяц с каждого пользователя. Для крупных компаний.

2. BitBucket

BitBucket — это служба хостинга репозиториев и управления версиями от Atlassian. Она тесно интегрирована с другими инструментами Atlassian — Jira, HipChat и Confluence.

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

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

Стоимость

  • Free — бесплатно для команд, в которых не больше пяти разработчиков.
  • Standart — 2 доллара в месяц с пользователя. Для небольших и средних команд. Неограниченное число пользователей.
  • Premium — 5 долларов в месяц. Для больших команд, которым нужны расширенные возможности.

3. SourceForge

SourceForge — ещё одна крупная альтернатива GitHub, сконцентрировавшаяся на Open Source. Многие дистрибутивы и приложения Linux обитают на SourceForge.

В своё время популярность сервиса упала под натиском более простого и интуитивно понятного GitHub. Однако SourceForge переработал свой интерфейс, став гораздо привлекательнее и, главное, удобнее.

Стоимость

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

4. Launchpad

Launchpad — платформа для совместной работы над программным обеспечением от Canonical, компании-разработчика Ubuntu. На ней размещены PPA-репозитории Ubuntu, откуда пользователи загружают приложения и обновления.

Сервис Launchpad существует уже много лет, но он не снискал такой популярности, как GitHub и другие его альтернативы. Однако это хороший выбор для разработчиков Open Source: неважно, создаёте ли вы софт для Ubuntu-подобных систем или других дистрибутивов Linux.

Стоимость

Вы можете размещать или импортировать репозитории Git на Launchpad совершенно бесплатно.

5. Apache Allura

Allura — это бесплатное решение от Apache. Сервис поддерживает отслеживание проблем в коде и комментарии кодов с разметкой. Apache Allura работает с Git, Hg и Subversion (SVN).

С Allura вы легко сможете создавать внутренние вики-страницы для документации.

Стоимость


Бесплатно. Но вам придётся разместить Allura на своём хостинге или сервере.

6. Cloud Source

Cloud Source — средство управления версиями Git от Google. Вы можете создавать любое количество частных репозиториев Git, позволяющих организовать код. Сервис интегрирован с инструментами облачной диагностики Google, такими как отладчик Stackdriver Debugger и Stackdriver Error Reporting. Так что вы без труда сможете отслеживать ошибки в коде.

Cloud Source позволяет подключать репозитории GitHub или Bitbucket. Вы можете использовать код из своих репозиториев в проектах Cloud Platform.

Стоимость

  • Up to 5 Users — 1 доллар в месяц с пользователя. До пяти пользователей в команде.
  • 50 GB Storage — 0,10 доллара в месяц за каждый использованный ГБ. Неограниченное количество пользователей.

7. AWS CodeCommit

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

CodeCommit тесно интегрирован с другими сервисами Amazon, так что, если вы используете инфраструктуру этого облачного гиганта, CodeCommit — ваш выбор.

Стоимость

  • Бесплатно с ограничениями: до пяти активных пользователей, до 50 ГБ хранилища и до 10 000 запросов Git в месяц.
  • Платно — 1 доллар в месяц с каждого пользователя сверх пяти. 10 ГБ хранилища и 2 000 запросов Git в месяц для каждого активного пользователя.

8. FogCreek/DevHub

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

Стоимость

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

9. Beanstalk

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

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

Стоимость

  • Bronze — 15 долларов в месяц, 3 ГБ хранилища, 10 репозиториев, до пяти пользователей.
  • Silver — 25 долларов в месяц, 6 ГБ хранилища, 25 репозиториев, до 20 пользователей.
  • Gold — 12 ГБ хранилища, 50 репозиториев, до 40 пользователей, а также расширенные возможности.
  • Platinum — 24 ГБ хранилища, 120 репозиториев, до 100 пользователей, расширенные возможности.
  • Diamond — 60 ГБ хранилища, 300 репозиториев, до 200 пользователей, расширенные возможности.

10. GitKraken


GitKraken обладает прекрасным интерфейсом. Он ориентирован на скорость и простоту использования Git. Цель платформы — экономить время на сборку и тестирование кода.

С GitKraken работают такие гиганты, как Blizzard, IBM, Google и Microsoft. GitKraken можно установить на компьютерах с Windows, Mac и Linux.

Как создать репозиторий на GitHub

  • написана командой Vertex Academy. Надеемся, что она Вам будет полезна. Приятного прочтения!
  • это одна из статей из нашего «Самоучителя по Java»

Привет! Это одна из статей из руководства «GIT основы: Курс молодого бойца»

Как создать репозиторий на GitHub

Как только Вы создали эккаунт на GitHub (см. статью «Как зарегистрироваться на GitHub»), перед Вами должно появиться похожее окно:

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

Но сейчас, давайте начнем с основ. Сверху слева находится поисковая строка:

Справа вверху — небольшое меню:

Колокольчик — это уведомления.

Если нажать на иконку справа, появится меня для управления учётной записью:

Если же нажать на плюс, откроется выпадающее меню:

Как видите, можно:

  • создать новый репозиторий («New repository»)
  • импортировать репозиторий («Import repository»)
  • новый gist («New gist») — что-то наподобие статьи в блог
  • новая организация («New organisation») — например, Вы можете создать организацию, с которой можно связывать учётные записи на GitHub.

Три способа создать репозиторий на GitHub:

Cпособ 1: нажать на «New repository».

Способ 2: нажать на большую кнопку «Start a project» («Создать проект»):

Способ 3: нажать на зеленую кнопку «New repository» («Новый репозиторий») в окошке Repositories («Репозитории»):

Создаем репозиторий на GitHub

Вы уже знаете три способа создать новый репозиторий! �� Тогда создайте репозиторий, использовал любой из 3 способов.

Создали? Отлично, тогда Вы должны увидеть вот такую страницу:

Отлично! Давайте разберем по частям.

Сверху, Вы видите собственника репозитория («Owner»), и название репозитория («Repository name»). Давайте назовем его «first-repo»:

Как выбирать имя для репозитория

В языке Java есть определенные Naming Conventions (Code Conventions), т.е. соглашение о том, как нужно называть переменные, классы, методы и т.д. Как Вы наверное помните, в Java принято использовать CamelCase (по-другому CamelStyle).

На GitHub таких правил нет. Тем не менее, часто можно увидеть запись через дефис (как сделали мы), или тем же CamelCase.

Для примера, можно посмотреть на репозитории:

  • Google (https://github.com/google)
  • Facebook (https://github.com/facebook)
  • Microsoft (https://github.com/Microsoft)

Вот так выглядит репозиторий Google.

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


Возвращаемся к созданию репозитория

Итак, дальше идёт описание («Description»). Писать его не обязательно (справа от «Description» серым написано слово «optional»). Но если Вы хотите чтобы работодатель, который будет смотреть на Ваш аккаунт, или другие программисты, смогли понять о чём идёт речь и оценили Вашу работу, желательно подробно описывать проекты. В частности, это можно сделать с помощью README (об этом позже).

В описании давайте напишем «Первый проект на Git»:

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

На этом мы можем остановиться и нажать большую зеленую кнопку «Создать репозиторий» («Create repository»). Тем не менее, есть еще несколько настроек, которые мы можем сделать.

Во-первых, Вы видите галочку «Initialise this repository with a README» (Создать репозиторий с README). README — это еще один способ рассказать людям, просматривающим Ваш репозиторий, о Вашем проекте.

Хорошо расписанные README будет выглядет примерно так:

Но написание таких файлов — отдельная наука. Файл README имеет расширение .md, свой синтаксис и метки. Подробнее то, как следует писать файл README, мы рассмотрим в следующих статьях.

Кроме создания README, у нас есть еще две опции — добавлять ли файл .gitignore (по умолчанию None — не добавлять), и добавлять ли лицензию (по умолчанию тоже None).

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

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

Дело в том, что на GitHub размещают много open-source проектов, то есть бесплатных программ с открытым кодом. Интересно, что обычно лицензия используется не для того, чтобы ограничить доступ в проекту, а наоборот, чтобы позволить другим людям использовать Ваш код. Когда Вы ничего не указываете в поле «лицензия», использование кода из репозитория считается кражей.

Итак, отлично! Мы разобрались с основными полями, которые надо заполнить. Теперь, нажмем большую зеленую кнопку «Создать репозиторий» («Create repository»).

Теперь Вы должны видеть перед собой похожую страницу:

Мастер Йода рекомендует:  8 заданий по C#, которые могут попасться на собеседовании

Вот мы и создали свой первый репозиторий на GitHub. Теперь он появится у Вас в разделе «Репозитории» на главной странице:

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

Спасибо, что были с нами! ��

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

Начинаем работать с системой контроля версий GIT (для чайников)

(Часть 2. Создаем репозиторий Git)

2. Создаем репозиторий Git.

Да начала создания репозитория необходимо провести базовые настройки Git. Дело в том, что часто над одним проектом работает целая команда разработчиков, поэтому системы контроля версий требуют идентифицировать пользователей, которые сохраняют изменения в репозитории. Не исключение и система контроля версий git, в которой в качестве идентификатора используется два параметра: имя пользователя и e-mail адрес. Эти параметры задаются один раз при настройке git и при каждом сохранении в репозитории напротив «коммита» указывается, кто его сохранил в репозиторий.

Коммит (commit) – единовременная загрузка группы изменений в репозиторий Git c кратким описанием содержания изменения и указания автора загрузки. Коммита – базовая величина изменения репозитория, который состоит из набора коммитов, история добавления которых показывается в виде древа коммитов.

Чтобы задать имя пользователя (в моем случае имя пользователя — Poisov) в консоли необходимо выполнить команду:

git config —global user.name «Poisov»

Чтобы задать e-mail (в моем случае e-mail: poisov@yandex.ru) в консоли необходимо выполнить команду:

git config —global user.email «poisov@yandex.ru»

На этом необходимый минимум настроек выполнен и можно приступить к созданию репозитория. Первое, что надо сделать – выбрать рабочий каталог, в котором вы будете разрабатывать свое программное обеспечение. Каталог может быть как пустым если вы только собираетесь начать разработку, так уже содержать результаты вашей работы. В качестве рабочего каталога я выберу пустой каталог: home/poisov/programs.

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

И создать Git-репозиторий, для чего находясь в каталоге home/poisov/programs в консоле набираем команду:

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

/programs$ git init
Initialized empty Git repository in home/poisov/programs/.git/
poisov@ubuntu:

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


Git и GitHub на windows от новичка (часть 2)

Что такое публичный и приватный ssh-ключ? Эта пара ключей для одного пользователя? Если так, то для каждого пользователя я должен в настройки GitHub-а сохранить его публичный ключ? Или достаточно одного публичного ключа для всех?

Зачем нужен пароль (passphrase) для соединения по ssh к репозиторию на GitHub? Этот пароль нужен только для доступа к паре ssh ключей, которые хранятся в папке

/.ssh ( имя_пользователя/.shh )? Или этот пароль так же знает репозиторий на GitHub?

Пара ключей ssh хранится в папке пользователя на винде. Если я захочу присоединиться к другому репозиторию по ssh, то значит мне надо будет изменить эту пару ssh ключей?

Если удалить ветку, то удаляться и все его коммиты? Хотя если подумать, то ветка это всего лишь указатель на коммит, значит удалится этот указатель, а не сами коммиты. Так?

Я уже запутался с этими командами перехода_на_коммит / изменения_коммита / удаления_коммитов и т. п. Какие именно команды удаляют коммиты навсегда, а не просто из виду убирают? reset (soft/hard)? revert ? еще что-нибудь?

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

MS Visual Studio 2010 создал файл main.cpp . При попытки его (и другие файлы с кодом от MS VS) индексировать выводится ошибка:

Fatal: CRLF would be replaced by LF in main.cpp.

Искал в гугле и что-то было про это, но как решить эту проблему я не понял.

1 ответ 1

1) Что такое публичный и приватный ssh-ключ?

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

Эта пара ключей для одного пользователя?

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

Если так, то для каждого пользователя я должен в настройки GitHub’а сохранить его публичный ключ? Или достаточно одного публичного ключа для всех?

Насколько мне известно github не позволяет использовать один и тот же ключ в нескольких аккаунтах. Придётся генерировать пару для каждого аккаунта.

2) Зачем нужен пароль(passphrase) для соединения по ssh к репозиторию на GitHub?

Чтобы повысить уровень защиты. Оберегает доступ в случае кражи приватного ключа.

Этот пароль нужен только для доступа к паре ssh ключей, которые хранятся в папке

/.ssh(имя_пользователя/.shh)? Или этот пароль так же знает репозиторий на GitHub?

Этот пароль никакого отношения к github не имеет, только к ключу. Указывается в момент генерации ключа.

3)Пара ключей ssh хранится в папке пользователя на винде. Если я захочу присоединиться к другому репозиторию по ssh, то значит мне надо будет изменить эту пару ssh ключей?

Нет. Ключи используются для доступа к серверу с определённого компьютера. Можно сгенерировать пару, и использовать её для доступа к github, bitbucket, какие-то свои сервера. Ну и добавив ключ в настройках аккаунта вы пользуетесь им для работы со всеми репозиториями которые предоставляет сервис.

4) Если удалить ветку, то удаляться и все его коммиты? Хотя если подумать, то ветка это всего лишь указатель на коммит, значит удалится этот указатель, а не сами коммиты. Так?

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

5)Я уже запутался с этими командами перехода_на_коммит/изменения_коммита/удаления_коммитов и т.п. Какие именно команды удаляют коммиты навсегда, а не просто из виду убирают? reset(soft/hard)? revert? еще что-нибудь?

revert не удаляет, лишь обращает изменения новым коммитом.

По-вопросу: не знаю, мне всегда хватало reset .

6)Как сделать так, чтобы перестало просить пароль при использовании ssh соединения? Например, когда использую git push или git fetch.

Сгенерировать новый ключ, во время ввода пароля ничего не вводить.

7)MS Visual Studio 2010 создал файл main.cpp. При попытки его(и другие файлы с кодом от MS VS) индексировать ошибка: Fatal: CRLF would be replaced by LF in main.cpp. Искал в гугле и что-то было про это, но как решить эту проблему я не понял.

Windows-specific problem. По-идее ничего страшного, на SO предлагают добавить

сижу на линуксах, поэтому тут помочь не могу.

ДОБАВЛЕНО:

А что если через один аккаунт, но на разных компьютерах или пользователей в винде?

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

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

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

10 репозиториев на 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) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.
Добавить комментарий