Что такое коммит в github
Первый коммит в Github
Руководство по созданию первого коммита в свой репозиторий на Github
В этом мануале представлены основные сведения об инструментах контроля версий программного обеспечения и рассмотрен алгоритм создания локального репозитория, связанного с удалённым.
Основы
GitHub — онлайн-хостинг репозиториев, обладающий всеми функциями системы контроля версий и функциональностью управления (в него входит всё то, что поддерживает Git). Вместе с Git он даёт разработчикам возможность сохранять их код онлайн, а затем взаимодействовать с другими разработчиками в разных проектах.
Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.
GitHub — это сервис для проектов, использующих Git.
Создать коммит (commit) значит зафиксировать изменения любых файлов, входящих в репозиторий.
Репозиторий — каталог файловой системы, в котором могут находится: файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.
Репозиторий бывает:
Для первого коммита на Github необходимо установить Git, создать локальный репозиторий, добавить в него файлы, сделать коммит, подключиться к удалённому репозиторию и отправить в него изменения.
Установка Git
Для Linux:
1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git
Для macOS:
1. Воспользуемся homebrew
2. Вводим в терминале: brew install git
Для Windows, (для macOS и Linux — альтернатива):
1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.
Далее работа с Git будет выполняться в терминале Bash, который станет доступен на любой ОС после установки Git. Так вы будете лучше понимать устройство работы с системами контроля версий и возможности графического клиента ограничены по сравнению с консольным.
Создание и настройка локального репозитория
Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.
2. Настроим имя пользователя и адрес электронной почты:
(где Name – логин пользователя, email@mail.ru — почта)
Теперь каждое наше действие будет отмечено именем и почтой, это вносит порядок в историю изменений.
tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.
find – удаление файлов со специфичным суффиксом.
3. Переходим в папку с проектом Users/Public/Project:
4. Создадим локальный репозиторий в папке с проектом:
Командная строка должна вернуть что-то вроде:
Добавление файлов в локальный репозиторий
1. Теперь создадим любой файл в нашей директории, например, first.txt
2. Добавим его в систему управления версиями:
3. Если нужно добавить все файлы в директории, то используем:
4. Проверить текущее состояние:
Можно отменить добавление файла командой:
Создание версии проекта
После добавления нужного файла в staging area (область подготовленных файлов) можно создать версию проекта.
Ключ –m означает создание пользователем описания этого коммита.
Для удаления всеx файлов в папке, не относящихся к проекту, и не сохраненных в репозитории, можно воспользоваться командой:
Создание репозитория на Github
Все действия до этого раздела производились над локальным репозиторием, который находится у вас на компьютере. Если мы хотим сохранить проект в Интернете, и предоставить к нему доступ, то создадим репозиторий на Github.
1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).
2. Нажимаем кнопочку «+» и вводим название репозитория.
3. Выбираем тип Public (Private доступен только в платной версии).
4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).
5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).
Результат можно увидеть с помощью команды:
Если все правильно сделано, то увидим:
Для отмены регистрации удаленного репозитария, введите:
Этой командой вносятся все изменения, которые были сделаны в локальном репозитории на Github:
-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push
Git commit
Коммит в Git и коммит в SVN
Порядок действий
Снимки состояния, а не различия
Помимо различий между SVN и Git с практической точки зрения, их базовая реализация также основывается на совершенно разных концепциях проектирования. SVN отслеживает различия в файле, тогда как модель управления версиями Git базируется на снимках состояния. Например, в коммите SVN содержатся различия исходного файла и файла, добавленного в хранилище. А Git записывает в каждом коммите все содержимое каждого файла.
Такой подход позволяет выполнять многие операции в Git намного быстрее, чем в SVN, поскольку конкретную версию файла не нужно «собирать» из его различий — во внутренней базе данных Git находится уже готовая редакция каждого файла.
Модель снимков состояния Git влияет практически на все аспекты модели управления версиями, от инструментов ветвления и слияния до рабочих процессов при совместной работе.
Распространенные опции
Коммит проиндексированного состояния кода. Эта команда откроет текстовый редактор с предложением ввести комментарий к коммиту. После ввода комментария сохраните файл и закройте текстовый редактор, чтобы выполнить коммит.
Выполнение коммита состояния со всеми изменениями в рабочем каталоге. Эта команда включает только изменения отслеживаемых файлов (тех, которые были в какой-то момент добавлены в историю с помощью команды git add ).
Этот параметр добавляет команде commit новый уровень функциональности. При передаче этого параметра будет изменен последний коммит. Вместо создания нового коммита проиндексированные изменения будут добавлены в предыдущий коммит. Кроме того, эта команда откроет настроенный текстовый редактор системы с предложением изменить указанный ранее комментарий к коммиту.
Примеры
Сохранение изменений с помощью команды commit
Окрашенный зеленым цветом вывод «new file: hello.py » сообщает о том, что файл hello.py будет сохранен при выполнении следующего коммита. Коммит выполняется с помощью указанной ниже команды.
Эта команда откроет текстовый редактор (настраиваемый через git config ) для ввода комментария к коммиту и покажет список файлов, которые будут зафиксированы в этом коммите:
Особых требований для комментариев к коммиту в Git нет, но обычно первая строка содержит описания коммита длиной до 50 символов, затем следует пустая строка и детальное пояснение того, что было изменено. Пример:
Обычно первая строка комментария к коммиту аналогична теме электронного письма. Остальная часть комментария считается телом сообщения и используется для детального описания набора изменений в коммите. Многие разработчики предпочитают использовать в комментариях настоящее время. Так комментарий становится больше похож на список действий в репозитории, благодаря чему многие операции перезаписи истории становятся более интуитивно понятными.
Обновление коммита (параметр amend)
Продолжим работу с файлом hello.py из приведенного выше примера. Давайте внесем в файл hello.py новые изменения и запустим следующие команды:
Снова откроется настроенный текстовый редактор. Но на этот раз он будет содержать комментарий к коммиту, который мы уже вводили ранее. Это указывает на то, что мы не создаем новый коммит, а редактируем последний.
Резюме
Модели коммитов в SVN и в Git существенно отличаются, но из-за общей терминологии часто возникает путаница. Если вы начинаете работу в Git, имея опыт работы с SVN, вам будет полезно знать, что коммиты в Git — простая операция, которую следует выполнять часто. В SVN коммит — сложная операция, связанная с выполнением удаленного запроса, тогда как в Git коммиты выполняются локально и по более эффективному алгоритму.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Git для начинающих. Урок 4.
Коммиты и история коммитов
Работа с файлами
Видеоурок. Часть 1. Практика, основы работы с коммитами и историей коммитов
Видеоурок. Часть 2. Практика, дополнительные приемы и фишки
Видеоурок. Часть 3. Общие наблюдения и советы. Как делать «хорошие» коммиты
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое коммит
По-научному это сохранение состояния, фиксация или слепок изменений.
Как сделать коммит
Представим, что мы добавляем блок учеников на сайт. Добавляем новую разметку в index.html и новые стили в main.css. Чтобы сохранить изменения, нужно их закоммитить. Но предварительно сообщить git, какие именно файлы мы хотим положить в коммит. Команда git add добавляет (или подготавливает) файлы к коммиту. Можно добавить файлы по отдельности, вот так
Добавлять все файлы сразу удобно, но стоит всегда внимательно проверять, точно ли мы хотим добавить в коммит все измененные файлы. Если ошиблись и какой-то файл добавлять в коммит не нужно, то можно исключить этот файл из подготовленных.
Создаем сам коммит
Состояние файлов в git. Измененные и подготовленные файлы
Подготовленные файлы отличаются от измененных тем, что они «подготовлены» к коммиту, то есть будут добавлены в следующий коммит.
git add filename добавляет или подготавливает файл к коммиту.
git reset filename удаляет файл из подготовленных к коммиту.
Содержимое файлов при этом не меняется. Один файл может одновременно находиться и в измененных, и в подготовленных. Это происходит, если мы добавили файл, но не закоммитили и продолжили делать в нем измения.
Из чего состоит коммит
Каждый коммит имеет
Как добавить файлы и сделать коммит одной командой
Отслеживаемые и неотслеживаемые файлы
История коммитов, git log
Все коммиты можно посмотреть в истории коммитов. История хранит все данные обо всех коммитах проекта. Показывается история командой
История включает в себя все сведения о коммитах: хэш, автор, дата и список изменений. Список изменений смотреть командой git show по хэшу коммита
Если мы сделали коммит, но хотим поправить его commit message
Эта команда перезапишет сообщение последнего коммита. Это перезаписывание истории, операция опасная. Лучше делать ее только до того, как отправили коммит на сервер (push разберем через урок)
Откат коммитов, git revert
Если мы сделали неверный коммит и хотим откатить изменения, сделанные в нем, то поможет команда git revert
Работа с файлами
При работе с файлами нужно учесть, что новые файлы git отправляет в неотслеживаемые. Поэтому при добавлении нового файла стоит сначала его закоммитить, а потом вносить изменения, чтобы они были доступны через git diff
При обычном переименовании файла в файловом менеджере или командой mv git сначала показывает 2 файла: старый удаленный и новый неотслеживаемый. Чтобы git понял, что этот файл именно переименованный, нужно сначала добавить эти файлы в подготовленные к коммиту
Тогда при команде git status файл будет отображаться именно как переименованный
Можно избежать этого промежуточного состояния, если переименовать файл в командной строке таким образом
Тогда файл будет сразу отображаться, как переименованный. То же самое с удалением файла
Командная строка vs IDE
Работа в PhpStorm продемонстрирована в первых двух частях видео.
Как и в прошлом уроке мы видим, что некоторые вещи удобнее делать в IDE. Например, процесс добавления файлов (git add) в PhpStorm при создании коммита почти не привлекает внимания. Но важно понимать, что такое git add и зачем он нужен. И что любая IDE под капотом все равно выполняет базовые команды git. Просто для нас предоставляется удобная обертка, чтобы мы больше сосредоточились на самом проекте, а не на git.
Наблюдения и советы при работе с коммитами
В каждой команде свои правила и соглашения. Но я приведу общие советы и размышления, которые помогут в любом проекте
Используйте удобные инструменты в IDE, но не забывайте командную строку. В ней вы лучше будете понимать, как устроен git, как он работает
Хорошие и плохие коммиты
С точки зрения git коммиты не бывают плохими и хорошими. Но есть удачные и неудачные подписи к коммитам с точки зрения наших коллег. Несколько примеров
Добавлен файл VipClient
Работа с vip-клиентами вынесена в отдельный класс
По первому коммиту можно предположить, что в VipClient мы скорее всего работаем с ВИПами. Во втором коммите это точно понятно, плюс дополнительная информация, что это отдельный класс.
Поправлены стили в main.css
Рефакторинг стилей в main.css
Первый коммит говорит о правке стилей, но непоянтно, что именно поправлено. Бага? Новые значения? Изменен цвет текста по рекомендации дизайнера? Второй коммит ясно указывает, что это рефакторинг
Маленький фикс
Исправлена опечатка в заголовке title страницы «О компании»
Коммит «маленький фикс» даже приблизительно не говорит, в чем он заключается. Второй коммит дает полное представление
Немного о философии коммитов
Концепция коммитов заставляет если не менять подход к разработке, то по-другому к ней относиться. С git нам приходится не просто писать код, а планировать его написание. Планировать задачи, над которыми мы работаем. Декомпозировать задачи, то есть разбивать их на небольшие части.
Мы больше думаем о том, что мы работаем не одни, а в команде. История коммитов общая для всего проекта. Чем лучше мы научимся формировать и подписывать коммиты, тем легче будет ориентироваться в истории нам самим и нашим коллегам.
В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.
На этом все. В следующем уроке мы будем больше работать с историей коммитов и посмотрим различные варианты использования команды git log
Что такое коммит в github
Руководство по написанию коммитов
Это руководство поможет понять, почему важно писать хорошие сообщения коммитов и как это делать.
Также это руководство может помочь прояснить, что такое коммит, почему важно писать хорошие сообщения, узнать лучшие практики и советы по созданию и (пере)написанию истории коммитов.
Простыми словами, коммит — это снимок ваших локальных файлов, записанный в локальный репозиторий. Вопреки распространённому мнению, git хранит не только изменения между файлами, но и в целом полную версию всех файлов. Для файлов, которые не менялись от одного коммита к другому, git хранит только ссылку на предыдущий идентичный файл, который уже был сохранен.
На изображении ниже показано, как git хранит данные с течением времени. Каждая «версия» является коммитом:
Почему сообщения коммитов важны?
Чтобы добиться максимального результата, мы можем использовать некоторые полезные практики и стандарты, описанные в следующем разделе.
Это некоторые практики, собранные из моего опыта, статей и других руководств. Если у вас есть предложение (или вы не согласны с некоторым) не стесняйтесь открыть пулреквест и внести свой вклад.
Используйте повелительное наклонение
Но зачем использовать повелительное наклонение?
Сообщение коммита описывает, что конкретно делают зафиксированные изменения, его конечный результат, а не что было сделано.
В замечательной статье Криса Бимса (Chris Beams) (перевод на русский) приводится шаблон предложения, который может использоваться, чтобы лучше писать сообщения коммитов в императивной форме:
Начинайте сообщение коммита с заглавной буквы
Смысл этой рекомендации простой: в соответствии с правилами грамматики первое слово предложения начинается с заглавной буквы.
Использование этой практики может варьироваться от человека к человеку, от команды к команде или даже от языка к языку. Заглавная или нет, важно придерживаться единого стандарта и следовать ему.
Старайтесь описывать изменения так, чтобы указывать на исходный код
Это полезно во многих случаях (пр. несколько коммитов, различные изменения и рефакторинг), чтобы помочь проверяющим понять о чём думал автор коммита.
Используйте тело сообщения для объяснения «почему», «для чего», «как» и дополнительные детали
Тема и описание сообщения разделены пустой строкой.
Дополнительные пустые строки считаются частью описания.
Избегайте общих сообщений или сообщений без какого-либо контекста
Ограничьте длину строк
Рекомендуется использовать максимум 50 символов для темы и 72 символа для описания.
Сохраняйте согласованность языка
Для владельцев проектов: Выберите язык и пишите все сообщения коммитов используя этот язык. В идеале, он должен совпадать с комментариями в коде, стандартным переводом (для переведенных проектов), и т.д.
Для участников проекта: Пишите сообщения коммитов на том языке, который используется в истории коммитов.
Перебазировка vs. Слияние
Этот раздел является кратким пересказом превосходного руководства «Merging vs. Rebasing» от Atlassian.
Кратко: Применяет ваши коммиты в ветке, один за другим, к базовой ветки (например, master), генерируя новое дерево.
Кратко: Создаёт новый коммит, называемый (соответственно) коммит слияния (merge commit), с различиями между двумя ветками.
Почему некоторые люди предпочитают перебазирование вместо слияния?
Я, в частности, предпочитаю перебазирование вместо слияния. По следующим причинам:
Когда нужно делать объединение коммитов?
Объединение (Squashing) — это процесс объединения множества коммитов в один-единственный коммит.
Это может пригодиться в ряде ситуаций, например:
Когда избегать перебазирования или сжатия?
Избегайте этого в публичных коммитах или в общих ветках, в которых работают несколько человек. Перебазирование и слияние также перезаписывает историю коммитов и существующие коммиты, делая это с коммитами, которые находятся в разных ветках (например, коммиты, отправленные в удаленный репозиторий или коммиты из других веток) могут вызвать путаницу и поэтому можно потерять изменения (как локальные, так и удаленные) из-за различающегося дерева и конфликтов.
Полезные команды git
Используйте их, чтобы объединить коммиты, изменить сообщения, переписать/удалить/изменить порядок коммитов и т.д.
Используйте эту команду, чтобы привести в порядок коммиты, не прибегая к перебазированию. В этой статье есть хорошие примеры того, как и когда это делать.
Эта команда может быть очень полезной для применения коммита, который был сделан в неверной ветке, чтобы не писать код заново.
Давайте представим, что у нас есть следующий список различий: