GitHub и GitHub Desktop — как делать commit
Как обновить новыми данными Git репозиторий. Другими словами как правильно коммитить (commit), иначе – вносить изменения и правки на гит. Разберем на примере программы GitHub Desktop.
GitHub Desktop
Вы сделали какое-то изменение в файлах, это сразу отразится в программе. В левой части будут показаны, какие файлы изменены в сравнении с тем, что находится в репозитории. Отмечаем галочкой нужные файлы.
Затем внизу в поле Summary заносим короткое описание изменений. При желании можно описать более подробно в окошке Description. Далее нажать «Commit to название ветки».
Последним действием в программе нажимаем на Fetch Origin вверху рабочей области, чтобы отправить изменения на сервер.
github.com
После отправки заходим на Github в ту ветку с которой вы работаете (куда отправили изменения). Там появится новая кнопка: Compare & pull request. Нажимаем на неё.
Следующим действием, уже в новом окне. Там где указан base: master выбираем нужную ветку либо оставляем master. А с правой стороны compare уже указана наша рабочая ветка.
Если в комментариях ничего нет или нужно добавить, здесь же пишем. Затем нажимаем Create pull request.
Если никаких конфликтов нет, то будет предложено совместить ветки. Это делается с помощью кнопки Merge pull request. Однако, если вы работаете в большой компании и не являетесь руководителем проекта, функцию совмещения ветки следует оставить тому, кто проект знает лучше. Пусть он проверит код за вами и затем сам сделает совмещение проектов.
Читайте также
Кстати, на сайте нет рекламы. У сайта нет цели самоокупаться, но если вам пригодилась информация можете задонатить мне на чашечку кофе в макдаке. Лайкнуть страницу или просто поблагодарить. Карма вам зачтется.
Summary github что это
Разберемся с терминами
Потому что это пугает больше всего.
Git — это распределенная система контроля версий кода. Она помогает разработчикам сохранять все изменения, внесённые в код, отслеживать изменения в файлах и работать совместно с командой.
Github — это cервис для хостинга (то есть хранения) репозиториев. На Github есть возможность контролировать разные версии кода, управлять исходным кодом и работать вместе с командой. То есть делать то же, что и Git.
И вот в чем разница между ними: Git — это инструмент, который просто впервые позволил одновременно команде править код и работать над одним проектом вместе, а GitHub — это платформа для проектов, использующих Git.
Open Source — это прозрачный подход к созданию проектов. Разработчики открывают код продуктов, над которыми работают — над ним можно вместе работать, а ещё — копировать. И всё это на Github.
Коммит (commit) — это публичное сохранение, фиксация (в архиве, репозитории и др.) изменений в коде.
Репозиторий (repo) — это хранилище версий кода какого-то проекта**.** В репозитории есть журнал коммитов, которые были добавлены в него. У репозитория могут быть разные ветки — у каждого своя история и происхождение. По умолчанию основная ветвь называется «мастер». Как правило, весь готовый код объединяется в мастер.
Форк (fork) — клон репозитория. В копии репозитория можно вносить свои собственные изменения, редактировать файлы. Например, вы решили внести изменения в чей-то репозиторий, внесли, а теперь можете поделиться им и отправить автору оригинального репозитория. Это будет считаться запросом на слияние и называться pull request.
Вот, смотрите, справа от Scala иконка форкнутого репозитория.
Issue — это условные карточки-задачи, которые вы можете создавать, чтобы отслеживать работу над багами, внедрение новых функций или других запросов. Как тикеты в Trello.
Readme — это файл, который в первую очередь нужно прочитать, когда вы открываете репозиторий. У хорошего проекта с открытым исходным кодом обычно есть файл Readme с объяснением того, для чего он предназначен, где он опубликован, и некоторой документацией по его использованию.
Contribution — это действия пользователя Github, по которым считается его активность на платформе:
Что ещё важно знать?
Давайте вернемся к вопросу: что такое Github в принципе. Это платформа, где разработчики и компании (да, в том числе) могут хранить проекты, редактировать их вместе. Но мы видим только часть репозиториев — те, что доступны всем.
Итак, пример. Разработчик, который активен на Github (у него регулярно что-то появляется), является автором или участником крупного проекта с открытым исходным кодом (open source). Делаем вывод, что, скорее всего, у него большой разработки на языке проекта. То есть активность и ценность вклада разработчика в целом рассказывает нам об уровне его навыков.
Но! Не каждый разработчик использует Github, и не каждый может — есть много компаний, которые запрещают ребятам участвовать в open source проектах.
На что обратить внимание в профиле?
1. Стек
Github — идеальный инструмент, чтобы узнать больше про технологический стек. Вы можете просто посмотреть, репозиториев с какой технологией больше всего или над чем он работал в последнее время.
И тут вам пригодятся вот эти инструменты:
О Git, начинающих и статьях о Git для начинающих
Пятница тринадцатое отличный день для очередного holywar обсуждения «как я готовлю Git, и почему я готовлю его неправильно».
Итак, у каждого программиста будь то под Linux, будь то под Windows всегда найдётся кто-то, кто вращается соответственно в кругах программистов под Windows или Linux. Так и у меня есть программисты из мира Microsoft и Windows. Похвально, что такие люди начинают двигаться в сторону OpenSource и Git. Но сейчас не об этом.
При рассказе я иногда буду опираться на известную книгу Pro Git, написанную Скотом Чаконом (Scott Chacon).
В одной из бесед в интернете была упомянута статья для начиниющих в Git, а именно вот эта. Также кто-то высказал мысль, что статьи «как я готовлю Git» содержат в себе нюансы, от которых трудно впоследствие избавиться, как от вредной привычки. Я всё же не поленился и прочитал статью. И смею согласиться с приведенным мнением.
Почему я считаю эти советы не очень хорошими, которые могут превратиться во вредные привычки со временем?
Вот примерный шаблон, как оформляются изменения:
In general, it’s very important to write a good commit message. For open source projects, it’s generally a rule to write your message more or less in this format:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); some git tools can get confused if you run the
two together.
Further paragraphs come after blank lines.
— Bullet points are okay, too
— Typically a hyphen or asterisk is used for the bullet,
preceded by a single space, with blank lines in
between, but conventions vary here
Случай 2: как сделать rebase на устаревший feature-branch?
На что ещё я обратил внимание, уже в беседе, которую я упомянул в начале статьи. Это процесс, которым люди пользуются, а именно вот такая последовательность действий:
В первом случае необходимо иметь локальную копию master в рабочем дереве, переключение — checkout — дорогая операция, так как надо работать с файловой системой, представили уже репозиторий на пару десятков тысяч файлов, в котором, скажем, по шаблону что-то недавно изменили?
Второй способ позволяет обновить индекс, причём можно сразу для всех remote, затем в одну операцию обновить feature-branch, и третьей залить в master или ещё куда. В первом способе этого не было, кроме фактического обновления master.
Таким образом предлагается вначале наделать себе локально изменений, разобраться с ними, оформить в нормальную серию и залить дальше, считая, что это всё уже на публике. С другой стороны даже если это внутренний репозиторий найти концы какой-то проблемы будет ой как сложно. Видимо не так много людей представляет себе, что происходит реально на производстве.
Бонус
Полезность оцените сами, в частности, если положить в одно дерево сразу Linux kernel и несколько подсистем, как-то: linux-pm, linux-tty, …
Как писать сообщения коммитов в Git
Введение: Почему так важны сообщения коммитов
Взгляни на логи случайного git репозитория. Сообщения коммитов в большем или меньшем беспорядке. Так выглядели мои коммиты в начале работы в Spring:
Мда. Сравни это с моими последними коммитами из того же репозитория:
Ранние комментарии хаотически меняются по длине и форме, поздние — краткие и последовательные. Первые — норма в публичных репозиториях. Вторые же не появятся в них случайно.
Пока логи большинства репозиториев выглядят как первый пример, есть и ислючения. Ядро Linux и репозиторий Git — отличные примеры. Еще взгляни на Spring Boot или любой другой репозиторий, который управляется by Tim Pope.
Контрибьюторы этих репозиториев знают, что сформировать хорошее сообщение в коммите — лучший способ сообщения о изменении контекста другим разработчикам и себе в будущем. Результаты изменений покажут что изменилось, но только сообщение в коммите скажет зачем это произошло. Peter Huttere высказался здесь:
Воссоздание контекста для куска кода — расточительство. Нельзя избежать этого полностью, но всё должно вести к его уменьшению (насколько это возможно). Сообщения коммитов помогают в этом и показывают, насколько их автор умеет сотрудничать с другими разработчиками.
Если ты не задумывался над тем, в чём польза правильного сообщения коммита, то возможно недостаточно поработал с git log и другими связанными утилитами. Но здесь возникает замкнутый круг: так как история коммитов неструктурирована и непоследовательна, то не стоит тратить время на ее использование и уход за ней. А так как этим никто не занимается, то она остаётся неструктурированной и непоследовательной.
Ухоженная история коммитов — полезная вещь. git blame, revert, rebase, log, shortlog и другие утилиты оживают благодаря ей. Рассмотрение коммитов и пул-реквестов других людей становится стоящим и внезапно может быть сделано независимо от них. Понимание того, из-за чего коммит произошел месяцы или годы назад, становится возможным и эффективным.
Долгосрочный успех проекта зависит (среди прочего) от его ремонтопригодности, а у мейнтейнера почти нет инструментов мощнее чем лог проекта. Стоит потратить время, чтобы научиться правильно ухаживать за ним. Вскоре это становится привычкой и источником гордости и продуктивности для всех участников.
Сейчас я обращаюсь только к самому базовому элементу хранения здоровой истории коммитов: как писать сообщение отдельного коммита. Существуют и другие важные практики: склейка коммитов (git squash), обзора которых здесь нет. Возможно, я сделаю это в следующем посте.
Языки программирования имеют соглашения по поводу именования, форматирования и т. д. Есть разные варианты этих соглашений, но все разработчики согласны с тем, что выбрать и придерживаться чего-то одного лучше, чем оставлять хаос. Он возникает, когда каждый делает по-своему.
Подход команды к истории коммитов не должен отличаться. Сначала согласовывают стиль сообщений, который включает как минимум три вещи:
Стиль. Синтаксис разметки, поля переноса, грамматика, заглавные буквы, пунктуация. Обсудите эти вещи, уберите догадки и сделайте все как можно проще. В итоге вы получите журнал логов, который не только приятно читать, но и который реально будет постоянно читаться.
Контент. Какую информацию должен содержать текст сообщения коммита? Есть ли он вообще? Что в нем не должно содержаться?
Метаданные. Как нужно ссылаться на идентификаторы issues, номера пул-реквестов и т. д.?
Существуют общепринятые соглашения о сообщениях Git. Многие из них ожидаются в способах работы некоторых команд Git. Не нужно придумывать велосипед. Просто следуй семи правилам ниже.
Семь правил отличного сообщения к коммиту Git
С главной страницы git commit:
Хотя это и необязательно, рекомендуется начинать сообщение коммита с одной короткой (менее 50 символов) строкой, суммирующей изменение, после чего следует пустая строка, а затем более подробное описание. Текст до первой пустой строки в сообщении фиксации рассматривается как заголовок коммита, и этот заголовок используется во всем Git. Например, git-format-patch (1) превращает коммит в электронную почту и использует заголовок строки в теме письма, а остальную часть коммита — в теле.
Не каждый коммит требует как темы, так и тела. Иногда хватает и одной строки, особенно когда изменение настолько простое, что не требуется никакого дополнительного контекста. Например:
Когда коммит заслуживает немночто-то подобноего объяснения и контекста, нужно написать тело. Например:
Разделение темы и тела окупается при просмотре лога. Вот полная запись в логе:
Или git shortlog, которая группирует коммиты по пользователям, снова для краткости показывая только тему:
В Git есть другие места, в которых учитываются заголовок и тело коммита, но ничто не работает как нужно без пустой строки между ними.
2. Ограничь строку темы 50 символами
Совет: если сложно подвести общий итог, ты, возможно, хочешь объединить слишком много изменений сразу. Стремись к атомарным коммитам (тема для отдельного поста).
GitHub полностью осведомлен об этих соглашениях. Он предупредит, если превысить лимит:
И усекает любую тему длиной более 72 символов многоточием:
3. Начинай строку темы с заглавной буквы
Это действительно так просто. Начинай тему коммита с большой буквы.
4. Не завершай строку темы точкой
В строке темы точка в конце не обязательна. Еще это даст дополнительное место для правила №3 про 50 символов.
5. Используй повелительное наклонение в строке темы
Повелительное наклонение означает «устное или письменное распоряжение, команда или инструкция». Несколько примеров:
Каждое из семи правил в этой статье написано в императиве («Начинай тему с заглавной буквы» и т. д.).
Повелительное наклонение кажется грубым, поэтому мы не часто используем его. Но оно отлично подходит для написания тем коммитов. Одна из причин этого то, что сам Git использует его всякий раз, когда создает коммит от вашего имени.
Сообщение по умолчанию, созданное при использовании git merge:
И затем например используем git revert:
Или когда мы кликаем кнопку «Merge» на пул-реквесте в Github:
Когда пишешь свои сообщения коммитов в императиве — следуешь встроенным соглашениям Git. Например:
Сначала может быть неудобно. Мы больше привыкли говорить в изъявительном наклонении, в котором все сводится к освещению фактов. Вот почему сообщения коммитов часто выглядят следующим образом:
Иногда коммиты записываются как описание их содержимого:
Чтобы устранить путаницу, попробуй простое правило:
Правильно сформированная тема коммита Git должна всегда иметь возможность завершить следующее предложение:
Обрати внимание на то, как это не работает для других неправильных форматов:
Помни: использование императива важно только в строке темы. Можно отменить это ограничение, когда пишешь тело коммита.
6. Ограничь тело 72 символами в ширину
Git никогда не делает автоматического обтекания текстом. Когда пишешь тело коммита, нужно помнить о его правой границе и переносить текст вручную.
Рекомендация говорит о том, что это нужно делать на 72 символах. Так Git будет иметь достаточно места для отступов текста и сохранит ширину в 80 символов.
Здесь поможет хороший текстовый редактор. Легко настроить Vim для переноса текста на 72-ом символе когда пишется коммит Git. Так сложилось, что возможности IDE в этой ситуации ужасны (хотя в последних версиях IntelliJ IDEA, с этим стало лучше).
7. Используй тело, чтобы объяснить, «что» и «почему», а не «как»
Взгляни на full diff и подумай, сколько времени коллег и будущих контрибьюторов автор спасает, потратив время на хорошее описание контекста. Без этого он, вероятно, был бы потерян навсегда.
В большинстве случаев можно опустить данные о том, как было сделано изменение. Код, как правило, не требует объяснений. Если код настолько сложный, что его нужно объяснять в прозе — используй комментарии. В первую очередь сосредоточься на выяснении причин, по которым ты сделал изменения: как все работало до изменения (и что было не так), как все работает сейчас, и почему ты решил проблему именно так.
Будущим мейнтейнером, который будет благодарен тебе, возможно станешь ты сам!
Советы
Научись любить командную строку. Оставь в покое IDE
По целому ряду причин (например из-за подкоманд Git) разумно использовать командную строку. Git безумно мощный. IDE тоже, но по-своему. Я использую IDE каждый день (IntelliJ IDEA) и активно использовал другие (Eclipse), но никогда не видел интеграции с Git, которая могла бы посоперничать с легкостью и мощью командной строки.
Некоторые функции Git, которые реализованы в IDE, имеют неоценимое значение. Например вызов git rm при удалении файла и правильное использование git при его переименовании. Но все разваливается, когда ты начинаешь пытаться закоммитить, смержить, сделать rebase или выполнить сложный анализ истории через IDE.
Независимо от того, что ты используешь (Bash или Z shell), есть сценарии завершения табуляции, которые решают бОльшую часть боли из-за запоминания подкоманд и переключателей.
Прочитай Pro Git
Книга Pro Git доступна онлайн бесплатно. И это фантастика. Воспользуйся этим и прочти ее!
Git Wizardry
1 Введение
В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.
Данный же топик задумывался как непосредственное введение в работу с git, нечто
среднее между tutorial и обобщенной справкой, до которого все же рекомендуется
прочитать упомянутое выше введение. Сознательно избегаются технические
подробности работы git, употребляются только общие для СКВ термины и
ограничивается список упоминаемых команд.
2 Работа с локальным репозитарием
Сила любых распределенных систем — в наличии у каждого разработчика локального
репозитария, в котором возможно организовывать произвольную личную схему
разработки. В git есть несколько основных команды для ведения работы на месте и
множество вспомогательных.
2.1 Базовые команды
Базовые команды — те, без которых невозможно обойтись в разработке.
2.1.1 git init — создание репозитария
Команда git init создает в директории пустой репозитарий в виде директория
.git, где и будет в дальнейшем храниться вся информация об истории коммитов,
тегах — ходе разработки проекта:
Другой способ создать репозитарий — команда git clone, но о ней чуть позже.
2.1.2 git add и git rm — индексация изменений
Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры
использования:
git add EDITEDFILE — индексация измененного файла, либо оповещение о
создании нового.
git add. — внести в индекс все изменения, включая новые файлы.
Из индекса и дерева одновременно проекта файл можно удалить командой git rm:
git rm FILE1 FILE2 — отдельные файлы
git rm Documentation/\*.txt — хороший пример удаления из документации к git,
удаляются сразу все файлы txt из папки.
Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset:
git reset — сбросить нафиг весь индекс.
git reset — EDITEDFILE — удалить из индекса конкретный файл.
Команда git reset используется не только для сбрасывания индекса, поэтому дальше
ей будет уделено гораздо больше внимания.
2.1.3 git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы
Команда git status, пожалуй, можно считать самой часто используемой наряду с
командами коммита и индексации. Она выводит информацию обо всех изменениях,
внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей
ветки; отдельно выводятся внесенные в индекс и неиндексированные
файлы. Использовать ее крайне просто:
Кроме того, git status указывает файлы с неразрешенными конфликтами слияния и
файлы, игнорируемые git.
2.1.4 git commit — совершение коммита
Коммиты — базовое понятие во всех системах контроля версий, поэтому совершатся
он должен легко и по возможности быстро. В самом своем простом виде достаточно
после индексации набрать:
Если индекс не пустой, то на его основе будет совершен коммит, после чего
пользователя попросят прокомментировать вносимые изменения вызовом команды
edit(например, в Ubuntu обычно вызывается простенький текстовый редактор nano, у
меня же — emacs). Сохраняемся, и вуала! Коммит готов.
Есть несколько ключей, упрощающих работу с git commit:
git commit FILENAME — внесет в индекс и создаст коммит на основе изменений
единственного файла.
2.1.5 git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние
проекта до какого-либо коммита в истории. В git данное действие может быть двух
видов: «мягкого»(soft reset) и «жесткого» (hard reset).
«Мягкий» (с ключом «—soft») резет оставит нетронутыми ваши индекс и все дерево
файлов и директорий проекта, вернется к работе с указанным коммитом. Иными
словами, если вы обнаруживаете ошибку в только что совершенном коммите или
комментарии к нему, то легко можно исправить ситуацию:
Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку
последнего коммита». Подробней описан синтаксис такой относительной адресации
будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно,
HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета
указывает на оригинальный коммит.
Естественно, можно вернуться и на большую глубину коммитов,
1 — больше никто и никогда не увидит этот позорный коммит.
3 — вернее, три последних коммита. Никто. Никогда.
Если команда достигнет точки ветвления, удаления коммита не произойдет.
Для команд слияния или выкачивания последних изменений с удаленного репозитария
примеры резета будут приведены в соответствующих разделах.
2.1.6 git revert — отмена изменений, произведенных в прошлом отдельным коммитом
Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным
коммитом. Git revert создает новый коммит, накладывающий обратные изменения:
git revert config-modify-tag — отменяем коммит, помеченный тегом.
git revert 12abacd — отменяем коммит, используя его хэш.
Для использования команды необходимо, чтобы состояние проекта не отличалось от
состояния, зафиксированного последним коммитом.
2.1.7 git log — разнообразная информация о коммитах в целом, по отдельным файлам и различной глубины погружения в историю
Иногда требуется получить информацию об истории коммитов, коммитах, изменивших
отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих
целей используется команда git log.
Простейший пример использования, в котором приводится короткая справка по всем
коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
подробно узнать можно ниже, в разделе «Ветвления и слияния»):
За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
—summary:
Для исследования истории отдельного файла достаточно указать в виде параметра
его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):
или, если версия git не совсем свежая:
Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):
Можно отталкиваться от тегов:
git log v1… — все коммиты, начиная с тега v1.
git log v1… README — все коммиты, включающие изменения файла README, начиная с
тега v1.
git log v1..v2 README — все коммиты, включающие изменения файла README, начиная с
тега v1 и заканчивая тегом v2.
Создание, выведение списка, назначение тегов будет приведено в соответствующем
разделе ниже.
В принципе, формат вывода можно определить самостоятельно:
Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
—graph.
2.1.8 git diff — отличия между деревьями проекта; коммитами; состоянием индекса и каким-либо коммитом.
Своего рода подмножеством команды git log можно считать команду git diff,
определяющую изменения между объектами в проекте: деревьями (файлов и
директорий):
git diff — покажет изменения, не внесенные в индекс.
git diff HEAD — изменения в проекте по сравнению с последним коммитом
git diff HEAD^ — предпоследним коммитом
Можно сравнивать «головы» веток:
git diff master..experimental
Ну или активную ветку с какой-либо:
git diff experimental
2.1.9 git show — показать изменения, внесенные отдельным коммитом
Посмотреть изменения, внесенные любым коммитом в истории можно командой git
show:
git show COMMIT_TAG
2.1.10 git blame и git annotate — вспомогательные команды, помогающие отслеживать изменения файлов
При работе в команде часто требуется выяснить, кто именно написал конкретный
код. Удобно использовать команду git blame, выводящую построчную информацию о
последнем коммите, коснувшемся строки, имя автора и хэш коммита:
Можно указать и конкретные строки для отображения:
Аналогично работает команда git annotate, выводящая и строки, и информацию о
коммитах, их коснувшихся:
git annotate README
2.1.11 git grep — поиск слов по проекту, состоянию проекта в прошлом
git grep, в целом, просто дублирует функционал знаменитой юниксовой
команды. Однако, он позволяет слова и их сочетания искать в прошлом проекта, что
бывает очень полезно:
git grep tst — поиск слова tst в проекте.
git grep tst v1 — поиск в старой версии проекта.
Команда позволяет использовать логическое И и ИЛИ:
2.2 Ветвление
Операции ветвления и слияния — сердце и душа git, именно эти возможности делают такой
удобной работу с системой.
2.2.1 git branch — создание, перечисление и удаление веток
Работа с ветками — очень легкая процедура в git, все необходимые механизмы
сконцентрированы в одной команде:
git branch — просто перечислит существующие ветки, отметив активную.
git branch new-branch — создаст новую ветку new-branch.
2.2.2 git checkout — переключение между ветками, извлечение отдельных файлов из истории коммитов
Команда git checkout позволяет переключаться между последними коммитами (если
упрощенно) веток:
Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:
git checkout somefile — вернуть somefile к состоянию последнего коммита
git checkout HEAD
2 somefile — вернуть somefile к состоянию на два коммита назад по ветке.
2.2.3 git merge — слияние веток (разрешение возможных конфликтов).
Слияние веток, в отличие от обычной практики централизованных систем, в git
происходит практически каждый день. Естественно, что имеется удобный интерфейс к
популярной операции:
git merge new-feature — попробует объединить текующую ветку и ветку new-feature.
В случае возникновения конфликтов коммита не происходит, а по проблемным файлам
расставляются специальные метки а ля svn; сами же файлы отмечаются в индексе как
«не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить
будет нельзя.
Например, конфликт возник в файле TROUBLE, что можно увидеть в git status:
git merge experiment — произошла неудачная попытка слияния.
git status — смотрим на проблемные места.
edit TROUBLE — разрешаем проблемы.
git add. — индексируем наши изменения, тем самым снимая метки.
git commit — совершаем коммит слияния.
Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать
конфликт, достаточно набрать:
Если же коммит слияния был совершен, используем команду:
2.2.4 git rebase — построение ровной линии коммитов
Предположим, разработчик завел дополнительную ветку для разработки отдельной
возможности и совершил в ней несколько коммитов. Одновременно по какой-либо
причине в основной ветке также были совершены коммиты: например, в нее были
залиты изменения с удаленного сервера; либо сам разработчик совершал в ней
коммиты.
В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия
разработки, что бывает нежелательно в слишком больших проектах, где участвует
множество разработчиков.
Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления.
Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки
master:
2.2.5 git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом
Если ведется сложная история разработки, с несколькими длинными ветками
разработками, может возникнуть необходимость в применении изменений, внесенных
отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).
git cherry-pick BUG_FIX_TAG — изменения, внесенные указанным коммитом будут
применены к дереву, автоматически проиндексированы и станут коммитом в активной
ветке.
2.3 Прочие команды и необходимые возможности
Для удобства работы с git было введено дополнительное понятие: тэг. Кроме того
дальше будет пояснена необходимость в хэшах, и его применение; показан способ
обращаться к коммитам при помощи относительной адресации.
2.3.1 Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с
огромной вероятностью уникальный) хэш из 40 символов, который определяется
хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты,
файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла,
то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки
в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом
смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров
использования хэшей в качестве способа адресации:
git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2 — найти разницу текущего
состояния проекта и коммита за номером… Ну сами видите, каким.
git diff f292ef5 — то же самое, но оставляем только шесть первых символов. Git
поймет, о каком коммите идет речь, если не существует другого коммита с таким
началом хэша.
git diff f292 — иногда хватает и четырех символов.
git log febc32. f292 — читаем лог с коммита по коммит.
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были
введены другие объекты — тэги.
2.3.2 git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя
автора, собственное имя и некоторый комментарий. Кроме того, разработчик может
оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» («lightweight
tags»), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко:
git tag stable-1 — создать «легковесный» тэг, связанный с последним
коммитом. Если тэг уже есть, то еще один создан не будет.
git tag stable-2 f292ef5 — пометить определенный коммит.
После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:
git diff stable-1.1. stable-1
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо
информации, вроде номера версии и комментария к нему. Иными словами, если в
комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по
имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию»:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от
команд для «легковесных» тэгов.
2.3.3 Относительная адресация
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один
механизм — относительную адресацию. Например, можно обратиться прямо к предку
последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:
git diff HEAD^2 — найти изменения по сравнению со вторым предком последнего
коммита в master. HEAD здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки
нужно погрузиться:
git diff master^^ — что привнес «дедушка» нынешнего коммита.
Обозначения можно объединять, чтобы добраться до нужного коммита:
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых
редакторов, временные файлы и прочий мусор.
Заставить git status игнорировать можно, создав в корне или глубже по дереву
(если ограничения должны быть только в определенных директория) файл
.gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.
Пример содержимого такого файла:
#не нужны объектники и архивы
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать
из справки git help gitignore.
3 «Вместе мы — сила», или основы работы с удаленным репозитарием
Естественно, что большая часть проектов все-таки подразумевает работу по крайней
мере двух разработчиков, которым требуется обмениваться кодом. Далее будут
перечислены команды, требующиеся для совместной — возможно удаленной — работы.
3.1 Удаленные ветки (remote tracking branches)
Новое понятие здесь — удаленные ветки. Удаленные ветки соответствуют какой-либо
ветке (чаще master) на удаленном сервере. Одна такая создается автоматически при
создании копии удаленного репозитария; все команды, связанные с удаленной
работой, будут по умолчанию использовать именно эту удаленную ветку (обычно
называется «origin»).
Рассмотрим эти команды.
3.2 git clone — создание копии (удаленного) репозитария
Для начала работы с центральным репозитарием, следует создать копию
оригинального проекта со всей его историей локально:
git clone /home/username/project myrepo — клонируем репозитарий с той же машины
в директорию myrepo.
git clone ssh://user@somehost:port/
user/repository — клонируем репозитарий,
используя безопасный протокол ssh (для чего требуется завести у себя на машине
эккаунт ssh).
git clone git://user@somehost:port/
user/repository/project.git/ — у git имеется
и собственный протокол.
3.3 git fetch и git pull — забираем изменения из центрального репозитария (из удаленной ветки)
Для синхронизации текущей ветки с репозитарием используются команды git fetch и
git pull.
git fetch — забрать изменения удаленной ветки из репозитария по умолчания,
основной ветки; той, которая была использована при клонировании
репозитария. Изменения обновят удаленную ветку (remote tracking branch), после
чего надо будет провести слияние с локальной ветку командой git merge.
git fetch /home/username/project — забрать изменения из определенного
репозитария.
Возможно также использовать синонимы для адресов, создаваемые командой git remote:
git remote add username-project /home/username/project
git fetch username-project — забрать изменения по адресу, определяемому
синонимом.
Естественно, что после оценки изменений, например, командой git diff, из надо
создать коммит слияния с основной:
git merge username-project/master
Команда git pull сразу забирает изменения и проводит слияние с активной веткой:
git pull — забрать из репозитария, для которого были созданы удаленные ветки по
умолчанию.
git pull username-project — забрать изменения из определенного репозитария.
Как правило, используется сразу команда git pull.
3.4 git push — вносим изменения в удаленный репозитарий (удаленную ветку)
После проведения работы в экспериментальной ветке, слияния с основной,
необходимо обновить удаленный репозитарий (удаленную ветку). Для этого
используется команда git push:
git push — отправить свои изменения в удаленную ветку, созданную при
клонировании по умолчанию.
git push ssh://yourserver.com/
you/proj.git master:experimental — отправить изменения
из ветки master в ветку experimental удаленного репозитария.
git push origin :experimental — в удаленном репозитарии origin удалить ветку experimental.
git push origin master:master — в удаленную ветку master репозитария origin (синоним
репозитария по умолчанию) ветки локальной ветки master.
4 git-о-день
В этом разделе будут показаны и разобраны подробно несколько обычных и чуть
меньше необычных для работы с git ситуаций.
4.1 Обычный workflow при работе с локальным репозитарием
Git обладает необычайной легкостью в использовании не только как распределенная
система контроля версий, но и в работе с локальными проектами. Давайте разберем
обычный цикл — начиная с создания репозитария — работы разработчика git над
собственным персональным проектом:
Почему именно так? Зачем отказываться от линейной модели? Хотя бы даже потому,
что у программиста появляется дополнительная гибкость: он может переключаться
между задачами (ветками); под рукой всегда остается «чистовик» — ветка
master; коммиты становятся мельче и точнее.
4.2 Workflow при работе с удаленным репозитарием
Предположим, что вы и несколько ваших напарников создали общественный
репозитарий, чтобы заняться неким общим проектом. Как выглядит самая
распространенная для git модель общей работы?
you/proj.git
… возможно, прошло некоторое время.
Итак, первым делом создаем (1) создаем копию удаленного репозитария (по
умолчанию команды вроде git pull и git push будут работать с ним). «Вытягиваем»
последние обновления (2); смотрим, что же изменилось(3); создаем новую ветвь и
переключаемся в нее (4); индексируем все изменения и одновременно создаем из них
коммит (5); переключаемся в главную ветвь (6), обновляем ее (7); проводим
слияние с веткой bad-feature(8) и, обнаружив и разрешив конфликт, делаем коммит
слияния (9).
После совершения коммита отслеживаем изменения(10), запускаем, например,
юнит-тесты и с ужасом обнаруживаем, что после слияния проект валится на большей
части тестов.
В принципе, тесты можно было прогнать и до коммита, в момент
слияния (между пунктами 8 и 9); тогда бы хватило «мягкого» резета.
Таким образом, приходится совершить «жесткий» (11) сброс произошедшего слияния,
ветки вернулись в исходное до состояние. После чего переключаемся в неудачную
ветку (12), вносим необходимые изменения и переименовываем ветку (13). Совершаем
коммит (14); переходим в главную ветку(15), опять ее обновляем (16). На этот раз
бесконфликтно делаем слияние (17), закидываем изменения в удаленный репозитарий
(18) и удаляем ненужную теперь ветку (19). Закрываем ноутбук, одеваемся и идем
домой под утро.
5 Заключение
В топике не рассмотрено несколько важных вопросов, вроде администрирования
общественного репозитария, интеграции с текстовыми редакторами или IDE,
использования SSH под Линукс и Windows; приветствуются замечания, и особенно
дополнения в раздел «git-о-день».
UPD: замечание по работе с удаленным репозитарием. При работе с git с точки зрения администрирования, создания общественных репозитариев, управления доступом, использования шифрованных соединений и так далее могут возникнуть определенные вопросы; причем в этой заметке они не освещаются никак. Например, выше описана работа с уже готовым удаленным репозитарием; его развертывание никак не освещено.
Это все я сейчас собираю в отдельный топик, которую и выкину сюда через неделю-полторы.