Git или github: В чем разница между Git и GitHub? — Хабр Q&A

Про Git, Github и Gitflow простыми словами

Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.

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

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

Git – это распределенная система контроля версий (version control system – VCS).

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

Распределенность git’а отличает его от прочих vcs. Под распределенностью следует понимать, буквально, возможность использования одной системы контроля на проекте множеством разработчиков.

К слову, Git создал вот этот обходительный джентельмен:

Линус Торвальдс, создатель Git и Linux, передает привет Nvidia

Для начала, убедитесь, что у вас установлен Git.

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

Откройте командную строку, и перейдите в Desctop (да, будем оригинальны), а там создайте каталог (например, proglib).

Теперь, проходим в новый каталог и выполняем git init.

Все, у нас есть пустой репозиторий.

Давайте создадим простой README.md файл, что-то вроде:

# Proglib
Hello, readme please

и сохраним.

git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.

Чтобы добавить файл в контроль, используем команду git add README.md. Ну а если нужно добавить сразу много файлов, можно сказать git add . (то есть буквально add all).

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

Чтобы закомминтить изменения в локальный репозиторий, просто напишите в командной строке:

git commit -m "Added the README.md file»

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

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

Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.

Так как мы только что создали репозиторий, будем использовать вариант …or push an existing.

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

Давайте так и сделаем. Выполните в консоли git checkout -b new_feature. Эта команда создаст новую ветку с названием new_feature от ветки мастер (или от любой вашей текущей ветки) и выполнит переход на новую ветку.

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

git add .
git commit -m "New feature changes"
git checkout master
git merge new_feature

Gitflow

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

Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:

Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.

В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.

Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.

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

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

Вот как в теории, происходит рабочий процесс в Gitflow:

1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке

Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:

brew install git-flow-avh

gitflow-avh  – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?

Как условие для начала работы, нам нужен git репозиторий. Если вы не начали читать статью с этого места, то у вас один уже есть. Теперь выполним команду git-flow init, как для git.

Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.

Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:

git-flow feature start new_docs

Затем, откроем README.md и внесем изменения. После, сделаем коммит:

git add .
git commit -m "Added new documentation»

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

git-flow feature finish new_docs

Как можно видеть в выводе в консоли, эта команда сделала следующее:

1. Слила ветки new_docs и develop
2. Удалила new_docs
3. Выполнила переход на ветку develop, чтобы можно было продолжать работу

Допустим, новая фича нас устраивает, она оттестирована и работает исправно. Теперь нам нужно сделать релиз.

Для начала, необходимо выполнить команду:

git-flow release start 2.0

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

Когда работа закончена, просто напишем:

git-flow release finish 2.0

Вам нужно будет добавить несколько сообщений и меток, а потом утилита сделает следующее:

1. Сольет release и master
2. Пометит release как 2.0
3. Сольет release и develop
4. Удалит release
5. Выполнит переход на develop

Иногда совместная работа напоминает классику:

На гитхабе вы можете добавить кого-то, кого вы знаете в сотрудники в настройках Settings-Collaborators. Приглашенные таким образом участники получат разрешение пушить в ваш репозиторий или вы можете создать команду разработчиков и регулировать уровни доступа от проекта к проекту.

Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в github сущестуют pull-request’ы и code review.

Работает это следующим образом: вы делаете какое-то улучшение или фикс на featire-ветке, делаете pull request, кто-то из старших разработчиков, курирующих проект смотрит ваш код (читай, делает code review), возможно, делает какие-то замечания и, в конечном итоге добавляет ваш код в мастер-ветку (или куда-то еще).

На деле отношение к код ревью может быть разным. Буквально, от

до

а иногда даже

И как же к относится к code review? Кончено, это очень важная штука и нужно иметь терпение и делать ревью всех пул реквестов, если речь идет о вашем проекте, например. В долгосрочной перспективе это окупится. И, конечно, легко сказать «just do it», но в некоторых случаях сложившиеся традиции в команде разработчиков могут заставить пересмотреть свое отношение к некоторым вещам.

Создадим новую feature-ветку:

git-flow feature start NewFeatureDocs

Повторим процесс изменения документа и создания коммита.

А теперь сделаем кое-что новенькое:

git-flow feature publish NewFeatureDocs

То есть, отправим пул-реквест. Если зайти на гитхаб, можно его увидеть.

Теперь, нажмите кнопку Compare & pull request:

Здесь можно добавить комментарий к пул-реквесту.

На этом моменте, кто-то из вашей команды должен прийти и проверить ваш код. Вы даже можете дать об этом знать кому следует через инструмент управления проектом, которым ваша команда пользуется (JIRA, Trello, Leankit, Kanbanflow, etc) добавив таск/карточку в соответствующую колонку.

Когда пул-реквест будет подтвержден, вы как автор, должны сделать следующее:

git-flow feature finish NewFeatureDocs

Вы увидите, что Github закрыл пул-реквест и удалил ветку.

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

GitLab или GitHub? Как выбрать ресурс под определённый тип репозитория

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

Отличительные черты GitHub и прогресс прошлого года

Чем отвечает GitLab

Личные и групповые учётные записи

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

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

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

Что хранить на GitLab 🦊

Кроме веб-сервиса GitLab предоставляет открытый исходный код. Систему можно быстро и безболезненно запустить на собственном сервере. Если пользоваться веб-сервисом, то для следующих задач:

• Закрытый контент команд, компаний, организаций.
• Личные рабочие репозитории (для хранения «на всякий случай»).
• Персонализированные данные.
• Проекты учебных материалов.
• Веб-разработка (удобный инструмент – GitLab Pages).

Для всего остального есть GitHub 🐙🐈

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

Применяете ли вы различные системы управления репозиториями для разных задач?

Источники

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, благодаря расширенным возможностям второго. Которые могут сохранить и время и деньги, там самым сделать работу над проектом более оптимизированной и эффективной.

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

Если Вам понравилась статья, то можете поддержать блог переведя N сумму на кофе авторам или оплату хостинга!
В любом случае спасибо! А так же не забывайте про группу в ВК

Почему Git / Хабр

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

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

Все локально

Репозиторий, история, ветки и коммиты.

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

• Создать репозиторий в текущей директории — «git init». Все.
• Всего одна папочка .git и никакой порнографии ввиде .svn в каждой директории.
• Интернет не нужен. Работать одному вообще шикарно — локальный репозиторий, который разворачивается за доли секунды. Работа в распределенной команде — у каждого своя копия репозитория, никто не зависит от доступности центрального сервера.
• Не надо задумываться о создании системы резервного копирования. У каждого участника есть копия, из которой можно поднять оригинал.
  
  Поднимите руки те, кто поднимал потерянный svn-репо из своей копии git-репозитория.
• В своем репозитории вы делаете все, что хотите. Любые ветки, никто их не увидит.
  
  Черт, я помню как мне запрещали в SVN создавать отдельную ветку для работы над экспериментальной версией.

Контроль
В Git можно делать с коммитами и историей все что угодно:

• Удалить коммит, как будто его и не было
• Изменить комментарий коммита
• Поменять коммиты местами
• Объединить несколько коммитов в один, особенно когда нужно «докоммитить» что-то забытое
• Разбить коммит на несколько

Ветки:

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

Очень хорошо это описано здесь: http://gq.net.ru/2009/12/16/git-history-rewrite/
От таких возможностей сносит голову и кому-то это может показаться слишком опасным. Да, пару раз я терял коммиты из-за своих неопытных манипуляций и потом рылся в «корзине», чтобы их восстановить.
Но по мере того, как привыкаешь к этому и понимаешь что и как работает, у тебя вырастают крылья, и ты начинаешь работать намного эффективнее, получая попутно кучу удовольствия от этого.

Ветки

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

• Создать ветку, переключиться в нее, объединить ветки, вернуться назад — это рутинные операции.
• Мерджить одно удовольствие. Есть конфликты или нет, все проходит очень легко и никогда ничего не теряется.
• За исключением релизных, большинство веток очень короткие и живут 1–3 дня.

Коммит
Чтобы сделать коммит, надо указать какие именно изменения нужно туда положить. Изменения, а не файлы. «git add» надо вызывать как для измененных, так и для новых файлов. Таким образом подготавливается временное состояние, которое я называю «временный коммит» (в оригинале «staging area» или «index»).
В чем преимущество:

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

  Последнее время я использую только «git add -p» — Git показывает чанк за чанком (набор изменений в рамках файла) и спрашивает добавить в коммит или нет. Так я вижу, что я изменил и буду коммитить. И поэтому в коммит у меня никогда не попадут отладочный код, комментарии, лишние правки, пробелы. И коммиты получаются четкими и атомарными.

Диф и лог

• Я могу посмотреть диф всей ветки или группы коммитов, чтобы не листать по коммиту, особенно, если они неграмотно оформлены.
• Могу посмотреть разницу между 2 ветками, посмотреть какими коммитами они отличаются.
• Посмотреть диф без учета пробелов (git diff -b -w), если кто-то увлекся форматированием и превратил диф в одну сплошную кашу
• Могу в конфиге настроить кучу алиасов, которые будут выводить логи коммитов в разных форматах, например, сформировать change-log.

Лог — это вообще бездна возможностей.

Stash

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

Bisect

Команда для поиска коммита, в котором была допущена ошибка. Я указываю коммит, где я точно знаю, что этой ошибки нет. И коммит, где эта ошибка уже есть. Далее Git бинарным поиском выбирает коммит для проверки, переключается на него и предлагает ответить, есть здесь ошибка или нет. И так до тех пор, пока не будет найден ошибочный коммит. Если есть возможность, то можно написать скрипт, который будет автоматически проверять наличие ошибки и возвращать соответствующий код. Отдать этот скрипт в bisect и получить битую правку.

git-svn — для тех, кто в подполье

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

Субмодули

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

  $ git submodule add git://github.com/maxim-oleinik/sfDoctrine2Plugin.git plugins/sfDoctrine2Plugin

Git создаст директорию «plugins/sfDoctrine2Plugin» и развернет там еще один репозиторий, а под контроль поставит хеш ревизии. Если зайти в эту директорию, то мы попадем уже в другой проект. Там можно работать и коммитить как обычно, только в родительском проекте Git покажет, что подпроект обновился и предложит сохранить ссылку на новый коммит.

• Удобно работать в основном проекте и одновременно коммитить в разные субмодули.
• В Git нельзя подключить указанную директории из другого проекта, как это делает svn:externals. Только весь проект целиком.
  
  В том и суть, чтобы выделять самостоятельные модули и оформлять их в отдельные репозитарии. Правда, становится немного неудобно работать, когда у субмодулей есть свои субмодули и т.д.

GUI и консоль
Я, честно говоря, не знаю какой есть GUI у Git. Я никогда им не пользовался и рекомендую не лишать себя удовольствия работы с Git’ом в консоли. Не превращайтесь в мартышек, которые ищут нужную кнопку или галочку в интерфейсе, вместо того, чтобы просто набрать команду в консоли.
Ладно, без обид. Я просто хотел сказать, что работа в консоли намного богаче и удобнее.
У кого нет нормальной консоли… ну, тогда выбирайте GUI, IDE или… OS, у которой эта консоль есть.

Единственным окошком, которым я регулярно пользуюсь, — это «gitk -all &». Он показывает дерево коммитов с ветками и тегами. Очень удобно смотреть где ты сейчас находишься, где какие ветки и как они переплетаются. Там есть простой поиск и просмотр дифа.

Работа в команде

• В git нельзя закрыть доступ к определенной ветке или модулю. Или все или ничего. Но это еще ни разу не создало мне проблем. Если кто-то ошибся и закоммитил не туда, куда ему следовало (как мы заранее договорились), тогда я просто откачу эти правки так, как будто их и никогда и не было, и проведу разъяснительную беседу.
  
  Как вариант, можно выделить отдельный репозитарий с ограниченным доступом и рабочий — для всех.
• Все задачи делаются атомарно в ветках и в таком же виде передаются на ревью и мердж. Т. е. при желании, ни один коммит не попадет в основной ствол без ревью.
• Очень удобно проводить ревью задачи, которая выполнена в отдельной ветке. Посмотреть полный диф всех коммитов, что-то исправить, прокомментировать, отправить обратно на доработку, а потом объединить отдельные коммиты и слить в основную ветку.

GitHub
Это классная платформа, где можно бесплатно разместить и опубликовать свой репозиторий. Где живет куча проектов, которые форкаются, развиваются и обсуждаются. Сейчас там лежат все мои проекты.
Бесплатно для открытых проектов и мин 200 руб/мес, чтобы закрыть доступ.

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

У Git’a, конечно, есть и определенные минусы и трудности, но без них не бывает. Да они и не существенны. Чаще всего это вопрос git-way.

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

Что дальше

Дальше — начинать работать. Можно читать кучу обзоров и обсуждать сколько угодно, но до тех пор пока не начнешь работать, ничего не изменится.
За один день я перерыл доку и начал работать, 2 недели привыкал, через месяц учил остальных, через 3 — расправил крылья.

Как начать

1. Скачать, установить и настроить, я думаю, ни у кого не возникнет проблем. Почитаете еще статьи в этом блоге про настройки и прочие фишки.
2. Прочитайте любую книгу из списке указанного ниже. Правда, прочитайте. Хоть по диагонали, зато будете знать, что вообще есть. Это легко сделать за пару часов.
3. И начинайте работать над новым проектом или переносите существующий (импортировать не составить труда).

Есть чит-шит, который поможет с командами на первое время. Есть «git help ». Рекомендую не лениться и регулярно читать хелп для каждой новой команды, а потом еще читать и перечитывать. Так я узнал большинство возможностей, тонкостей и нюансов.
Ну и пишите, если что не понятно. Мне очень трудно понять, какие очевидные для меня вещи, не понятны новичкам. За второй статьей дело не станет.

Ссылки:

Ещё раз о «Mercurial против Git» (с картинками) / Хабр

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

Вот этот граф. Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd? Какое было самое ранее изменение на ветке «release»? Где именно началась ветка «topic»?

Я знаю, это нечестно. Я не показываю вам журнал изменений. Но поверьте мне, вы не захотите его видеть. Он не поможет. Вы думаете, одомашненные приматы^[1] записали там полезные подсказки, которые ответили бы вам на эти вопросы, но они не сделали этого. Хуже того, иногда они врут.

Более умным опровержением моих вопросов было бы спросить «А зачем тебе это нужно знать?» Давайте я отвечу на это последовательно.

1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.

Большая часть помешательства, которая толкает пользователей Git на горячие споры на тему «rebase» против «merge», вызвана тем, что они очень сильно хотят заставить разработчиков значительно переделывать историю в своих локальных репозиториях, для того, чтобы граф изменений на общедоступных серверах не выглядел бы как граф, показанный выше.

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

Видите разницу?

Каждый узел в графе раскрашен, чтобы показать имя своей ветки в Mercurial. Всякая угадайка становится не нужна. Вы твёрдо знаете, что когда-то была ветка с именем «temp», которая затем влилась в ветку «release», а не «master». Вероятно, сейчас она отмечена закрытой, как больше не нужная.

Некоторая первоначальная работа над веткой «topic» ушла в ветку «temp» перед тем тем, как слилась с веткой «release». Позднее, ветка «release» была обратно влита во вновь ведущуюся ветку «topic».

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

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

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

^[1]Одомашненные приматы — вероятно, отсылка к Тимоти Лири или Роберту Антону Уилсону — прим. перев.

Подключение к GitHub с помощью SSH

Документы GitHub

• Все продукты

• GitHub.com

• Начиная

  • Быстрый старт
    • Настроить Git
    • Создать репо
    • Форк репо
    • Быть социальным
  • Изучение GitHub
    • Продукты GitHub
    • Изучение выпусков раннего доступа с предварительным просмотром функций
    • Типы аккаунтов GitHub
    • Часто задаваемые вопросы об изменениях в планах GitHub
    • GitHub CLI
    • GitHub Desktop
    • GitHub для мобильных устройств
    • Разрешения на доступ на GitHub
    • Глоссарий GitHub
    • Шпаргалка по Git
    • Учебные ресурсы Git и GitHub
  • Регистрация на GitHub
    • Регистрация новой учетной записи GitHub
    • Подтверждение адреса электронной почты
    • Настройка пробной версии GitHub Enterprise Cloud
    • Настройка пробной версии GitHub Enterprise Server
  • Изучение проектов на GitHub
    • Поиск способов внести свой вклад в открытый исходный код на GitHub
    • Сохранение репозиториев со звездочками
    • Следуя за людьми
  • Использование GitHub
    • Поддерживаемые браузеры
    • Устранение проблем с подключением
    • Горячие клавиши

• Учетные записи пользователей

  • Управление настройками учетной записи пользователя
    • О вашей личной панели
    • Изменение вашего имени пользователя GitHub
    • Объединение нескольких учетных записей пользователей
    • Превращение пользователя в организацию
    • Удаление вашей учетной записи
    • Уровни разрешений для репозитория учетных записей пользователей
    • Уровни разрешений для пользовательских досок проектов

.

страниц GitHub | Веб-сайты для вас и ваших проектов, размещенные непосредственно из вашего репозитория GitHub. Просто отредактируйте, нажмите, и ваши изменения будут опубликованы.

.

База данных Git — GitHub Docs

Документы GitHub

• Все продукты

• REST API

• Обзор

  • Ресурсы в REST API
  • Типы медиа
  • Другие методы аутентификации
  • Исправление проблем
  • Предварительный просмотр API
  • Библиотеки
  • Конечные точки, доступные для приложений GitHub

• Ссылка

  • Действия
  • Деятельность
  • Программы
  • Биллинг
  • Проверяет
  • Сканирование кода
  • Нормы поведения
  • Эмодзи
  • Администрирование GitHub Enterprise
  • Gists
  • База данных Git
  • Гитиньор
  • Взаимодействия
  • вопросы
  • Лицензии
  • Markdown
  • Мета
  • Миграции
  • OAuth авторизации
  • Организации
  • Проекты

.