Гитхаб как пользоваться

Как начать работать с GitHub: быстрый старт


Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.
В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.
В статье не будут рассмотрены различия между разными DVCS. Также не будет детально рассматриваться работа с git, по этой теме есть множество хороших источников, которые я приведу в конце статьи.
Итак, сайт github.com позиционируется как веб-сервис хостинга проектов с использованием системы контроля версий git, а также как социальная сеть для разработчиков. Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое. GitHub на данный момент является самым популярным сервисом такого рода, обогнав Sourceforge и Google Code.
Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план:

Начнем с регистрации. Идем по ссылке github.com/signup/free и вводим свои данные.
После регистрации мы попадаем на Dashboard нашего аккаунта:

Сейчас у нас нет ни одного репозитория, и мы можем либо создать новый репозиторий, либо ответвиться (fork) от уже существующего чужого репозитория и вести собственную ветку разработки. Затем, при желании, свои изменения можно предложить автору исходного репозитория (Pull request).
Но для начала установим git и настроим его для работы с сайтом.
Если вы работаете в Windows, качаем и устанавливаем msysgit. Это консольная версия git для Windows (далее расказ будет вестись на примере этой ОС).
Инструкция для MacOS X (eng)
Инструкция для Linux (eng)
Проблем возникнуть не должно, просто везде жмем Next. После установки выбираем в контекстном меню Проводника Git Bash:

или через Git Bash.lnk в папке с установленой программой:

Прописываем в консоли свои данные и настройки переносов строк:
git config —global user.name «ваше имя»
git config —global user.email «ваша почта»
git config —global core.autocrlf true
git config —global core.safecrlf true
Кстати, рекомендую пройти неплохой интерактивный курс по использованию git из консоли. Курс проходится за несколько часов и дает необходимые базовые навыки.
Для тех, кто предпочитает gui — для Windows существует несколько таких инструментов для работы с git. Два основных — это SmartGit (кроссплатформенный) и TortoiseGit. Оба неплохие, и какой использовать — дело вкуса. Я опишу работу с TortoiseGit.
Для маков выбор giu тоже имеется.

  • официальный клиент от GitHub — на мой взгляд пока достаточно сыроват.
  • GitX — лично мне не приглянулся
  • GitBox — наиболее следует mac-way, очень рекомендую попробовать именно его

Качаем по ссылке code.google.com/p/tortoisegit/downloads/list. При установке везде жмем Next.
Теперь возвращаемся к github и создадим новый репозиторий. Находясь на Dashboard, жмем New Repository (https://github.com/repositories/new), вводим данные и жмем Create Repository.

GitHub позволяет работать с репозиториями тремя способами: SSH, HTTP и Git Read-Only, соответственно предоставляя ссылки трех видов для нашего репозитория:
1. git@github.com:habrauser/Hello-world.git
2. habrauser@github.com/habrauser/Hello-world.git
3. git://github.com/habrauser/Hello-world.git

Для того, чтобы просто забрать репозиторий на локальную машину, достаточно внутреннего протокола git (третья ссылка). Это наиболее быстрый и эффективный способ, который обеспечивает анонимный доступ только для чтения.
Если же мы захотим внести изменения в репозиторий на github, нужно пользоваться HTTP или SSH.
Работа по http никаких трудностей не вызывает, в нужный момент просто используется пароль учетной записи на github.
Чтобы использовать SSH, нам нужно создать специальную пару ключей: публичный и приватный. Публичный будет размещен в настройках аккаунта на github, а приватный сохранен на локальной машине.
Для генерации ключей, можно воспользоваться инструментом ssh-keygen, который идет в комплекте с git (описание этого способа можно почитать ). Мы же будем использовать PuTTY (а точнее небольшую программку puttygen, входящую в его состав). PuTTY — это такой клиент для удаленного доступа, в том числе и с использованием SSH.
Качаем последнюю версию с официального сайта (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Кстати, puttygen более старой версии (2007 год) идет в составе TortoiseGit.
После установки PuTTY, запускаем puttygen из папки с установленной программой:

Жмем Generate, двигаем некоторое время курсором мыши, для получения случайных данных, необходимых алгоритму

Вводим пароль, защищающий наш приватный ключ в поле Key passphrase, вводим подтверждение, жмем Save private key, сохраняем.
Далее копируем публичный ключ в формате OpenSSH из текстовой области «Public key for pasting…» и идем в настройки нашего аккаунта на github (Account Settings) в раздел SSH Public Keys:
жмем Add another public Key, вставляем наш публичный ключ:
нажимаем Add key. Все, теперь мы готовы работать с github по ssh. Попробуем забрать наш пустой рерозиторий на локальную машину с использованием TortioшseGit. В контекстном меню проводника выбираем Git Clone…
В поле Url вставляем SSH-адрес нашего репозитория, в поле Load Putty Key указываем путь к нашему приватному ключу, жмем OK.
Pageant запросит у наc пароль для приватного ключа (потом этого делать не потребуется)
Pageant — это агент SSH-аутентификации в составе PuTTY, он позволяет управлять закрытыми ключами.
В трее висит его значек:
Репозиторий успешно склонирован на локальную машину
Теперь попробуем изменить локальный репозиторий и отправить изменения на github. Добавим в локальный репозиторий файл README (файл с именем README обрабатывается github специальным образом — его содержимое будет отображаться в качестве описания репозитория на соответствующей странице)
Закоммитим изменения в локальный репозиторий
и синхронизируем его с репозиторием на github:
нажимаем Push
Теперь зайдя на страницу нашего репозитория мы увидим следующее:

Для каждого репозитория сайт предлагает wiki:
а также простую систему issue tracking-a:
кстати, для тех, кто использует в работе Eclipсe — есть соответствующий mylyn-коннектор для github:
и плагин EGit:
По ссылке Explore GitHub открывается каталог репозиториев, в котором можно искать по множеству других критериев, в том числе по языкам программирования, популярности и т.п.
Резюмируя хочется сказать, что если вы начинающий разработчик, планирующий начать пользоваться системами контроля версий, или же более опытный и присматривающийся к распределенным VCS, но не знающий как начать, то есть смысл попробовать git, используя такой замечательный инструмент как github.com.

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

Для работы с git:
code.google.com/p/msysgit git для windows
www.syntevo.com/smartgit/index.html SmartGit
code.google.com/p/tortoisegit TortoiseGit
http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY
Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» — перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
los-t.livejournal.com/tag/git%20guts цикл постов «внутренности git»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks Линус Торвальдс о git
habrahabr.ru/blogs/Git/80909 книга «Волшебство git»
Про git на английском:
книги

  • progit.org/book книга «Pro Git»
  • rutracker.org/forum/viewtopic.php?t=2808582 книга «Version Control with Git», 2009, O’Reilly
  • book.git-scm.com книга «Git Community Book»
  • rutracker.org/forum/viewtopic.php?t=2808843 книга «Pragmatic Version Control Using Git», 2008, T. Swicegood
  • rutracker.org/forum/viewtopic.php?t=3239579 книга «Pragmatic Guide to Git», 2010, T. Swicegood. Описываемая версия git: 1.7.2.1. Книга в формате двустраничных разворотов — проблема/решение
  • rutracker.org/forum/viewtopic.php?t=900767 книга «Git Internals»
  • http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html книга «Git Magic»

видео

  • rutracker.org/forum/viewtopic.php?t=3520513 видеокурс, посвященный git. Довольно нескучный и с юмором.
  • www.youtube.com/watch?v=8dhZ9BXQgc4 лекция о git от Randal Schwartz
  • excess.org/article/2008/07/ogre-git-tutorial видеотуториал Git The Basics Tutorial

другое

  • gitref.org референс для изучения наиболее используемых команд
  • ftp.newartisans.com/pub/git.from.bottom.up.pdf инструкция по принципу «снизу вверх», т.е. от низкоуровнего устройства git к верхнеуровневым командам. Автор утверждает, что так информация лучше воспринимается
  • ndpsoftware.com/git-cheatsheet.html хороший cheatsheet
  • whygitisbetterthanx.com преимущества git в сравнении с другими VCS
  • devcheatsheet.com/tag/git подборка cheatsheets

Чтобы начать пользоваться GitHub – сначала необходимо зарегистрироваться на github.com. Затем Вы можете перейти к использованию сервиса. Работа с VCS возможна двумя способами: через web-интерфейс и с помощью программы на Windows или Mac. Рассмотрим оба варианта взаимодействия с GitHub.

Также рекомендуем ознакомиться со статьёй “GitHub – что это?“, в которой рассказывается о терминологии, принятой при работе с VCS, и о GitHub вообще.

Как пользоваться GitHub через web-интерфейс сайта

После того, как Вы войдёте в свою учётную запись, можно создать новый репозиторий с помощью кнопки “New repository”.

Затем нужно ввести имя нового репозитория (Repository name), его описание (Description) , выбрать тип: публичное или приватное (платно), указать – следует ли сразу добавить в репозиторий README-файл, а также можно выбрать параметры для файла .gitignore и приложить текст лицензионного соглашения.

После того, как все данные будут заполнены, нажмите кнопку “Create repository” для создания репозитория.

Файл .gitignore описывает файлы и папки, которые Git не будет загружать в хранилище репозитория. Многие среды разработки программного обеспечения создают свои системные файлы, которые нужны только самой IDE и не содержат никакого кода (плюс зачастую ещё и много весят). С помощью .gitignore можно запретить загрузку файлов такого типа в репозиторий.

Затем Вы попадёте на страницу созданного репозитория:

На ней представлен список файлов, находящихся в репозитории, элементы управления и файл Readme.

Чтобы загрузить новые файлы и выполнить коммит – нажмите кнопку “Upload files”.

Переключение между ветками проекта и создание новых – происходит с помощью кнопки “Branch”.

Создание новой ветки проекта

Новый пулл запросов создаётся кнопкой “New pull request”.

Добавление других программистов к проекту происходит в настройках (Settings) на вкладке Collaborators (коллеги). Для добавления соавтора необходимо ввести в текстовое поле его логин на GitHub или электронную почту, указанную при регистрации, и затем нажать кнопку “Add collaborator” (добавить коллегу).

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

При необходимости Вы (или другие разработчики) можете клонировать репозиторий на свой компьютер с помощью Git-клиента и ссылки или скачать его в виде zip-архива. Данные опции доступны при нажатии кнопки “Clone or download” (клонировать или скачать).

Клонирование (с помощью ссылки) или загрузка Git-репозитория

Если Вам нужно удалить репозиторий на GitHub, то для этого перейдите в настройки (Settings) и в самом низу страницы (в Danger Zone), будет кнопка “Delete this repository” (удалить данный репозиторий).

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

Внимание! Будьте осторожны, после удаления – никакие данные невозможно восстановить!

Как пользоваться GitHub с помощью клиента для компьютера GitHub Desktop

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

Интерфейс Git-клиента

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

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

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

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

Изменения, внесённые в файлы подсвечиваются в Git-клиенте. Чтобы сделать коммит в локальное хранилище введём название коммита и описание , затем нажмём кнопку “Commit to”.

Чтобы загрузить изменения в облако (выполнить команду Push), необходимо нажать кнопку “Sync”.

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

Спасибо за прочтение статьи!

Как пользоваться GitHub 4.56 (91.25%) 16 votes
Git, GitHub, VCS, Как пользоваться, Руководство

Git на практике

Существует замечательная книга Pro Git, в которой подробно описаны все команды и возможности гита. Но после ее прочтения у многих остается непонимание того, как это все использовать на практике. В частности, у программистов разного уровня часто возникают вопросы о том, как работать с ветками в Git, когда их заводить и как мержить между собой. Порой мне попадались очень «оригинальные» и неоправданно усложненные схемы работы с гитом. В то время как в сообществе программистов уже сформировалась схема работы с гитом и ветками в нем. В этой статье я хочу дать краткий обзор основных моментов при работе с Git, и описать «классическую» схему работы с ветками. Многое из того что описано в этой статье будет справедливо и для других систем управления версиями.
Эта статья может быть полезна для программистов, которые только начинают осваивать Git, или какую-то другую систему управления версиями. Для опытных программистов эта статья покажется очень простой и банальной.
Для начала давайте разберемся с тем что такое ветка и коммит.

Коммит

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

У коммита есть и другие свойства. Например, дата коммита, автор, комментарий к коммиту и т.п.
В качестве комментария обычно указывают те изменения, которые вносит этот коммит в код, или название задачи которую он решает.
Git это распределенная система управления версиями. Это значит, что у каждого участника проекта есть своя копия репозитория, которая находиться в папке “.git”, которая расположена в корне проекта. Именно в этой папке хранятся все коммиты и другие объекты Git. Когда вы работаете с Git, он в свою очередь работает с этой папкой.

Завести новый репозиторий очень просто, это делается командой
git init
Таким образом у вас получиться новый пустой репозиторий. Если вы хотите присоединиться к разработке уже имеющегося проекта, то вам нужно будет скопировать этот репозиторий в свою локальную папку с удаленного репозитория. Делается это так:
git clone <url удаленного репозитория>
После чего в текущей папке появляется директория .git в которой и будет содержаться копия удаленного репозитория.
Существует несколько основных областей в которых находиться код.

  • Рабочая директория – это файлы в корне проекта, тот код с которым вы работаете.
  • Локальный репозиторий — она же директория “.git”. В ней хранятся коммиты и другие объекты.
  • Удаленный репозиторий – тот самый репозиторий который считается общим, в который вы можете передать свои коммиты из локального репозитория, что бы остальные программисты могли их увидеть. Удаленных репозиториев может быть несколько, но обычно он бывает один.
  • Есть еще одна область, с пониманием которой обычно бывают проблемы. Это так называемая область подготовленных изменений (staging area). Дело в том, что перед тем как включить какие-то изменения в коммит, нужно вначале отметить что именно вы хотите включить в этот коммит. В своей рабочей директории вы можете изменить несколько файлов, но в один конкретный коммит включать не все эти изменения.

В целом работа с гитом выглядит так: вы меняете файлы в своей рабочей директории, затем добавляете эти изменения в staging area используя команду
git add <имя/файла>
При этом можно использовать маски со звездочкой.
Потом вы делаете коммит в свой локальный репозиторий
git commit –m “Комментарий к коммиту”
Когда коммитов накопиться достаточно много, чтобы ими можно было поделиться, вы выполняете команду
git push
После чего ваши коммиты уходят в удаленный репозиторий.
Если нужно получить изменения из удаленного репозитория, то нужно выполнить команду
git pull
После этого, в вашем локальном репозитории появятся те изменения, которые были отправлены другими программистами.
Код в рабочей области проекта образуется применением тех изменений, которые содержаться в коммитах. У каждого коммита есть свое имя, которое представляет собой результат хеш функции sha-1 от содержимого самого коммита.
Просмотреть коммиты можно при помощи команды
git log
Формат ответа этой команды по дефолту не очень удобен. Вот такая команда выведет ответ в более читаемом виде
git log —pretty=format:»%H : %an — %s» —graph —date=format:%c
Что бы закончить просмотр нужно нажать на клавишу q
Посмотреть, что находиться в рабочей директории и staging area можно командой
git status
Рабочую директорию можно переключить на предыдущее состояние выполнив команду
git checkout <hash коммита>
Только перед тем как это делать выполните git status и убедитесь, что у вас нет никаких локальных и не зафиксированных изменений. Иначе Git не поймет, как ему переключаться. git status подскажет вам что можно сделать с локальными изменениями что бы можно было переключиться. Этого правила следует придерживаться и при всяких других переключениях рабочей области.

Ветка

Ветка в Git это подвижный указатель на один из коммитов. Обычно ветка указывает на последний коммит в цепочке коммитов. Ветка берет свое начало от какого-то одного коммита. Визуально это можно представить вот так.

Сделать новую ветку и переключиться на нее можно выполнив команды
git pull
git checkout –b <имя новой ветки>
Просто сделать ветку, не переключаясь на нее можно командой
git branch <имя ветки>
переключиться на ветку
git checkout <имя ветки>
Важно понимать, что ветка берет свое начало не от ветки, а от последнего коммита который находиться в той ветке, в которой вы находились.
Ветка обычно заканчивается специальным merge коммитом, который говорит, что ветку нужно объединить с какой-то другой веткой. В merge коммите содержатся две ссылки на два коммита которые объединяются в одну ветку.

Существует другая ситуация при объединении веток, в которой merge может произойти без merge commit. Дело в том, что если в одной из веток не произошло никаких изменений, то необходимость в merge commit с двумя предками отпадает. В таком случае, при слиянии веток, Git просто сделает пометку о том, что дальше будут идти коммиты той ветки с которой эта ветка была объединена. Такая схема merge называется слияние-перемотка (fast-forward merge), визуально это можно представить вот так.

Во всех этих случаях, после того, как ветка объединяется с другой веткой, все коммиты сделанные в ней, попадают в ветку с которой она была объединена. Так же важно понимать, что merge это не двунаправленная операция. Если смержить ветку задачи в мастер ветку, то в мастер ветке появится код, который находился в ветке задачи, а в ветке задачи не появиться новый код из мастер ветки. Если нужно что бы это произошло, нужно смержить мастер ветку в ветку задачи.
Что бы смержить одну ветку в другую нужно вначале переключиться на ту ветку, в которую вы хотите смержить
git checkout <имя ветки>
Потом получить последние изменения сделанные в этой ветке выполнив
git pull
Затем выполнить команду
git merge <имя ветки>
Так выглядит работа с ветками в общих чертах.
Обратите внимание на то, что перед тем как заводить новую ветку нужно выполнить git pull. Делается это по нескольким причинам.

  • Другой программист мог изменить код, в том числе внести такие изменения, которые повлияют на решение задачи, для которой вы заводите новую ветку. Эти изменения могут вам пригодиться при решении своей задачи.
  • Из-за этих изменений вы можете получить конфликт при мерже.
  • Больше шанс что у вас получится merge commit. Это не так плохо, как два предыдущих пункта. Но если можно избежать лишнего коммита, то почему бы этого не сделать?

Популярные схемы работы с ветками в Git

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

Классическая схема работы с ветками

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

Именная ветка

Неопытные программисты заводят себе именную ветку и работают всегда в ней. Они решают по одной задачи за раз, и когда заканчивают решение одной из задач, делают новый Pull запрос через Web интерфейсе (об этом чуть ниже). Недостаток этого подхода в том, что так можно решать только одну задачу и нельзя быстро переключиться на решение другой задачи. Еще один недостаток в том, что ветки так со временем будут все сильнее расходиться и код в ветке программиста рано или поздно устареет относительно мастер ветки и его придется обновить. Для этого можно либо смержить мастер ветку в ветку программиста, либо завести новую ветку для этого программиста от последнего рабочего состояния в мастер ветке. Правда к тому времени, как это произойдет программист уже может освоить гит в достаточной мере что бы перейти на “классическую” схему работы. Таким образом эта схема имеет место быть для неопытных пользователей Git.

Схема с dev веткой

Другая схема очень похожа на классическую, только в ней помимо мастер ветки есть еще девелоперская ветка, которая деплоится на тестовый сервер. Такую ветку обычно называют dev. Схема работы при этом такая. Программист перед выполнением новой задачи заводит для нее ветку от последнего рабочего состояния в мастер ветке. Когда он заканчивает работу над задачей, то мержит ветку задачи в dev ветку самостоятельно. После этого, совместными усилиями задача тестируется на тестовом сервере вместе с остальными задачами. Если есть ошибки, то задачу дорабатывают в той же ветке и повторно мержат с dev веткой. Когда тестирование задачи заканчивается, то ВЕТКУ ЗАДАЧИ мержат с мастер веткой. Важно заметить, что в этой схеме работы с мастер веткой нужно мержить ветку задачи, а не dev ветку. Ведь в dev ветке будут содержаться изменения, сделанные не только в этой задаче, но и в других и не все эти изменения могут оказаться рабочими. Мастер ветка и dev ветка со временем будут расходиться, поэтому при такой схеме работы периодически заводят новую dev ветку от последнего рабочего состояния мастер ветки. Недостатком этого подхода является избыточность, по сравнению с классической схемой. Такую схему работы с ветками часто используют если в проекте нет автоматизированных тестов и все тестирование происходит вручную на сервере разработки.
Так же следует отметить что эти схемы работы можно комбинировать между собой, если в этом есть какая-то необходимость.

Pull запросы

С этим понятием имеется путаница. Дело в том, что в Git есть две совершенно разные вещи, которые можно назвать Pull запросом. Одна из них, это консольная команда git pull. Другая это кнопка в web интерфейсе репозитория. На github.com она выглядит вот так
Про эту кнопку и пойдет речь дальше.
Если программист достаточно опытный и ответственный, то он обычно сам сливает свой код в мастер ветку. В противном случае программист делает так называемый Pull запрос. Pull запрос это по сути дела запрос на разрешение сделать merge. Pull запрос можно сделать из web интерфейса Git, или при помощи команды git request-pull. После того как Pull запрос создан, остальные участники могут увидеть это, просмотреть тот код который программист предлагает внести в проект, и либо одобрить этот код либо нет. Merge через pull запросы имеет свои плюсы и минусы. Минус в том, что для тесной команды опытных программистов такой подход будет лишним. Это будет только тормозить работу и вносить в нее оттенки бюрократии.
С другой стороны, если в проекте есть не опытные программисты, которые могут сломать код, то Pull запросы могут помочь избежать ошибок, и быстрее обучить этих программистов наблюдая за тем какие изменения они предлагают внести в код.
Так же Pull запросы подходят для широкого сообщества программистов, работающих с открытым исходным кодом. В этом случае нельзя заранее сказать что-то о компетенции таких разработчиков и о том, что они хотят изменить в коде.

Конфликты

Конфликты возникают при мердже веток если в этих ветках одна и та же строка кода была изменена по-разному. Тогда получается, что Git не может сам решить какое из изменений нужно применить и он предлагает вручную решить эту ситуацию. Это замедляет работу с кодом в проекте. Избежать этого можно разными методами. Например, можно распределять задачи так, чтобы связанные задачи не выполнялись одновременно различными программистами.
Другой способ избежать этого, это договориться о каком-то конкретном стиле кода. Тогда программисты не будут менять форматирование кода и вероятность того, что они изменят одну и ту же строчку станет ниже.
Еще один хороший совет, который поможет вам избежать конфликтов при работе в команде, это вносить минимум изменений в код при решении задач. Чем меньше строчек вы поменяли, тем меньше вероятность что вы измените ту же самую строку что и другой программист в другой задаче.
После того, как в мастер ветке достигается состояние, которое можно считать стабильным оно отмечается тегом с версией этого состояния. Это и есть то что называют версией программы.
Делается это вот так
git tag -a v1.0
Что бы передать ветки в удаленный репозиторий нужно выполнить команду
git push –tags
Теги удобны еще и тем, что можно легко переключиться на то состояние кода которое отмечено тегом. Делается это с помощью все той же команды
git checkout <имя тега>
Различные системы деплоя и автоматизированной сборки используют теги для идентификации того состояния, которое нужно задеплоить или собрать. Так сделано потому, что если мы будем собирать или деплоить код последней версии, то есть риск, что какой-то другой программист в этот момент внесет какие-то изменения в мастер ветку, и мы соберем не то что хотели. К тому же так будет проще переключаться между рабочими и проверенными состояниями проектов.
Если вы будете придерживаться этих правил и “классической” схемы работы с ветками, то вам будет проще интегрировать ваш Git с другими системами. Например, с системой непрерывной интеграции или с репозиторием пакетов, таким как packagist.org. Обычно сторонние решения и всякие расширения рассчитаны именно на такую схему работы с гитом, и если вы сразу начнете делать все правильно, то это может стать большим плюсом для вас в дальнейшем.
Это обзор основных моментов при работе с Git. Если вы хотите узнать про Git больше, то я вам посоветую прочитать книгу Pro Git. .
В этой статье была приведена упрощенная схема представления коммитов. Но перед тем как ее написать я решил разобраться как именно хранятся коммиты на диске. Если вас тоже заинтересует этот вопрос, то вы можете прочитать об этом .

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *