wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Git log file: Что такое changelog проекта и как его создать: руководство по Git для начинающих

alexxlab
No Comments

Содержание

Что такое changelog проекта и как его создать: руководство по Git для начинающих

Перевод статьи «A Beginner’s Guide to Git — What is a Changelog and How to Generate it».

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

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

Что такое changelog?

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

«Журнализация изменений
проекта (англ. changelog) представляет
собой программное протоколирование
изменений, вносимых в большой проект.
Обычно записи журнала изменений содержат
информацию об исправлении ошибок, о
новых возможностях и т.д.», — Википедия.

В целом, есть два способа вести
changelog:

  1. простой — создать текстовый файл
    и начать перечислять в нем все вносимые
    изменения с указанием дат;
  2. «программистский» (или ленивый) —
    автоматически генерировать changelog из
    сообщений коммитов.

Мы остановимся на втором способе.

Зачем нужен changelog?

Я думаю, вы задаетесь вопросом, зачем
вообще нужен этот changelog и почему вам
стоит потратить время на его создание.

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

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

Разработчикам, работающим над крупным
проектом, может быть интересно, как этот
проект развивается.

Если вы работаете над проектом с
открытым кодом, вы можете найти файл
CHANGELOG.md в GitHub-репозитории. Этот файл
информирует контрибьюторов о последних
обновлениях проекта.

Где можно найти changelog-и?

Changelog-и встречаются повсюду! Они могут
принимать разные формы и располагаться
в разных местах, но они есть буквально
в каждом проекте.

Вот краткий список мест, где можно
обнаружить журнал изменений:

  • В посте блога. Changelog может вестись
    в отдельной статье, где описываются
    последние изменения в проекте.
  • Файл CHANGELOG.md — в репозитории на
    GitHub.
  • Раздел Changelog на сайте вашего любимого
    ПО. Например, вот
    changelog инструмента для менеджмента
    задач TickTick.
  • Раздел «Что нового» («What’s new») на
    страницах приложений в Android и IOS store.

Раздел «Что нового» приложения TickTick на Android

Раздел «Что нового» приложения TickTick на IOS

Автоматическое генерирование
changelog-а

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

Хорошее, исчерпывающее сообщение
коммита вообще не нужно менять — его
можно вносить в changelog, как есть.

Если вы хотите сгенерировать файл
changelog-а, никак его не украшая и не
персонализируя, я рекомендую воспользоваться
самым простым способом и создать этот
файл из сообщений коммитов.

Примечание. Некоторые сайты,
например, Keep A
Changelog, поясняют, что не следует создавать
changelog путем копипаста сообщений
git-коммитов (простой способ). Я тоже не
советую обращаться к этому способу,
если вы создаете профессиональный
продукт. Но сегодня есть еще и специальные
продвинутые генераторы, которые позволяют
превращать ваши git log-и в changelog-и (более
сложный способ).

Простой способ генерирования
changelog-а

Чтобы сгенерировать changelog простым
способом, вам не нужно никаких
дополнительных инструментов или
предварительных действий. Вам понадобится
лишь ввести несколько команд, находясь
в вашем Git-репозитории.

Начнем с напоминания. Когда вы вводите команду git log, выводится весь список ваших коммитов.

$ git log
// Output
commit f6986f8e52c1f889c8649ec75c5abac003102999 (HEAD -> master, origin/master, origin/HEAD)
Author: Sam Katakouzinos [email protected]
Date:   Tue Mar 10 11:41:18 2020 +1100
docs(developers): commit message format typo Any line of the commit message cannot be longer *than* 100 characters! Closes #17006
commit ff963de73ab8913bce27a1e75ac01f53e8ece1d9
Author: Chives [email protected]
Date:   Thu Feb 6 19:05:57 2020 -0500
docs($aria): get the docs working for the service Closes #16945
commit 2b28c540ad7ebf4a9c3a6f108a9cb5b673d3712d
Author: comet [email protected]
Date:   Mon Jan 27 19:49:55 2020 -0600
docs(*): fix spelling errors Closes #16942

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

Введя git log —oneline —decorate, мы получим
список коммитов, каждый из которых будет
занимать одну строчку.

$ git log --oneline --decorate
// Output
f6986f8e5 (HEAD -> master, origin/master, origin/HEAD) docs(developers): commit message format typo
ff963de73 docs($aria): get the docs working for the service
2b28c540a docs(): fix spelling errors 68701efb9 chore(): fix serving of URI-encoded files on code.angularjs.org
c8a6e8450 chore(package): fix scripts for latest Node 10.x on Windows
0cd592f49 docs(angular.errorHandlingConfig): fix typo (wether --> whether)
a4daf1f76 docs(angular.copy): fix getter/setter formatting
be6a6d80e chore(*): update copyright year to 2020
36f17c926 docs: add mention to changelog
ff5f782b2 docs: add mention to changelog
27460db1d docs: release notes for 1.7.9
add78e620 fix(angular.merge): do not merge proto property

Вид уже получше, но можно и
усовершенствовать.

$ git log --pretty=”%s”
// Output
docs(developers): commit message format typo
docs($aria): get the docs working for the service
docs(): fix spelling errors chore(): fix serving of URI-encoded files on code. angularjs.org
chore(package): fix scripts for latest Node 10.x on Windows
docs(angular.errorHandlingConfig): fix typo (wether --> whether)
docs(angular.copy): fix getter/setter formatting
chore(*): update copyright year to 2020
docs: add mention to changelog
docs: add mention to changelog
docs: release notes for 1.7.9
fix(angular.merge): do not merge proto property

Здесь мы выводим список коммитов в желанном для нас стиле. «%s» относится к названию коммита. Все остальные части вывода можно модифицировать, чтобы результат выглядел так, как вам нужно. Например, можно добавить дефис перед каждым коммитом:

$ git log --pretty="- %s"
// Output
- docs(developers): commit message format typo
- docs($aria): get the docs working for the service
- docs(*): fix spelling errors
- chore(*): fix serving of URI-encoded files on code.angularjs.org
- chore(package): fix scripts for latest Node 10.x on Windows
- docs(angular. errorHandlingConfig): fix typo (wether --> whether)
- docs(angular.copy): fix getter/setter formatting
- chore(*): update copyright year to 2020
- docs: add mention to changelog
- docs: add mention to changelog
- docs: release notes for 1.7.9
- fix(angular.merge): do not merge proto property

Вот и все! Вы создали простой changelog.

Примечание. Если вы хотите сохранить
полученный changelog, не нужно его копипастить.
Просто перенаправьте вывод команды в
файл с нужным названием. Например,

git log --pretty="- %s" > CHANGELOG.md

Более сложный способ
генерирования changelog-а

Здесь сама идея — генерирование
changelog-а на основе сообщений коммитов —
сохраняется, но мы будем пользоваться
специальными инструментами.

При написании сообщений коммитов
рекомендуется придерживаться определенного
стиля. Эти стили зависят от набора
правил, которым вы пользуетесь, а правила
изложены в специальных руководствах.
Например, есть простое руководство
от Udacity. Есть и другие: Conventional
Commits, Angular
Guideline. Следуя прописанным в руководствах
правилам, вы делаете свои сообщения
более структурированными.

Хорошо структурированные коммиты
позволяют вам воспользоваться специальными
инструментами для генерирования
changelog-а. Чаще всего таким образом можно
получить лучший результат, потому что
эти инструменты позволяют создавать
форматированные (markdown) changelog-и.

В нашем примере мы воспользуемся
простым генератором, который работает
с большинством руководств по стилю
коммитов. Он называется «generate-changelog»
и доступен на NPM (Node Package Manager).

Этот инструмент, хотя у него и
небогатый функционал, создаст более
стильный changelog, чем просто текстовый
файл, сгенерированный из командной
строки. Если хотите пойти дальше, обратите
внимание на другие инструменты генерации
changelog-ов:

Установка и использование
generate-changelog

Прежде чем устанавливать этот
инструмент, нужно убедиться, что у вас
установлен NPM. Если нет, установите Node
и NPM, следуя
указаниям на официальном сайте.

Для установки пакета на свой компьютер,
введите в терминале следующую команду:

$ npm install generate-changelog -g
Использование

Чтобы этот инструмент работал, вы
должны при написании сообщений коммитов
пользоваться шаблоном «тип(категория):
описание [флаги]». В этом примере я буду
использовать GitHub-репозиторий Angular.js,
потому что там разработчики придерживаются
именно такого шаблона.

Установив пакет, вы можете перейти в
свой GitHub-репозиторий и выполнить
следующую команду:

$ changelog generate

Файл CHANGELOG.md будет создан автоматически.
Он будет содержать ваши логи в формате
markdown.

Ниже представлен пример вывода команды
(в том виде, в каком он будет доступен к
просмотру на GitHub или при помощи
markdown-ридера).

Заключение

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

наглядная справка. Как пользоваться Git для начинающих

Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды. 

Описание

Git является распределенной системой для управления версиями разрабатываемых файлов. Создана она была в 2005 году автором ОС Linux. Эта система осуществляет синхронизацию работы с сайтом, а также сохраняет и обновляет изменения в файлах. Это очень удобный подход в случае работы над проектом нескольких разработчиков. На сегодняшний день во многих известных проектах используется именно Git. Что такое использование дает? К примеру, разработкой операционной системы Android занимается большое число программистов. Было бы крайне неудобно, если бы один из них вносил изменения, а другие об этом не знали. Git же позволяет всем быть в курсе всех изменений, а в случае ошибок вернуться к предыдущим версиям файлов.

Основные команды

Следующие четыре команды предназначены для копирования файлов между рабочей директорией, сценой, также известной как «индекс», и историей, представленной в форме коммитов.

  • git add файлы копирует файлы в их текущем состоянии на сцену.
  • git commit сохраняет снимок сцены в виде коммита.
  • git reset — файлы восстанавливает файлы на сцене, а именно копирует файлы из последнего коммита на сцену. Используйте эту команду для отмены изменений, внесённых командой git add файлы. Вы также можете выполнить git reset, чтобы восстановить все файлы на сцене.
  • git checkout — файлы копирует файлы со сцены в рабочую директорию. Эту команду удобно использовать, чтобы сбросить нежелательные изменения в рабочей директории.

Вы можете использовать git reset -p, git checkout -p, и git add -p вместо имён файлов или вместе с ними, чтобы в интерактивном режиме выбирать, какие именно изменения будут скопированы.

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

  • git commit -a аналогичен запуску двух команд: git add для всех файлов, которые существовали в предыдущем коммите, и git commit.
  • git commit файлы создаёт новый коммит, в основе которого лежат уже существующие файлы, добавляя изменения только для указанных файлов. Одновременно, указанные файлы будут скопированы на сцену.
  • git checkout HEAD — файлы копирует файлы из текущего коммита и на сцену, и в рабочую директорию.

Использование слепков, а не патчей

Главным отличием Git от других систем контроля версий является то, как она смотрит на данные. Большая часть программ хранит информацию в виде списка изменений, называемых патчами для файлов. Такие системы к хранимым данным относятся как к набору файлов, а также набору изменений, которые сделаны для каждого файла, относительно времени. Как хранит свои данные Git? Что такое есть в этой системе, что отличает ее от других? Вместо патчей, хранимые данные здесь считаются набором слепков маленькой файловой системы. Всякий раз, когда пользователь фиксирует новую версию проекта, система просто сохраняет слепок состояния файлов на текущий момент. Чтобы повысить эффективность в том случае, когда файл не изменялся, система не сохраняет его, а делает ссылку на ранее сохраненный экземпляр, в который были внесены последние изменения.

Это очень важное отличие от других систем контроля, которое присуще Git. Что такое отличие дает? Git становится похожей на маленькую файловую систему, обладающую очень мощными инструментами, которые работают поверх нее.

Преимущественно локальные операции

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

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

Наблюдение за целостностью данных

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

Данные чаще всего добавляются

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

Состояния файлов

Работа с Git для начинающих подразумевает запоминание того, что файл может находиться в одном из трех состояний:

  • Зафиксированное, то есть файл сохранен в локальном хранилище.
  • Измененное, когда правки были внесены, но сохранение еще не выполнено.
  • Подготовленное – измененные файлы, которые отмечены для сохранения.

Так, в проектах, в которых используется Git, имеется три раздела для разных состояний файлов:

  • Каталог Git, где хранятся метаданные, а также база данных объектов. Эта часть системы самая важная.
  • Рабочий каталог, который является извлеченной из базы данных копией какой-то версии проекта.
  • Файл, содержащий информацию о последующем сохранении.

Устанавливаем Git

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

  • Установка Git из исходников.
  • Установка пакета для используемой платформы.

Установка Git из исходников

При наличии такой возможности лучше использовать данный вариант, так как будет получена самая свежая версия. Каждое обновление обычно содержит множество полезных улучшений, касающихся интерфейса пользователя. Именно поэтому, если установка из исходников не слишком для вас затруднительна, лучше предпочесть ее. Да и большинство дистрибутивов Linux включают в себя устаревшие пакеты.

Для установки понадобятся необходимые библиотеки: expat, curl, libiconv, openssl, zlib. После их инсталляции можно загрузить последнюю версию системы контроля версий, скомпилировать ее и установить.

Установка в операционной системе Windows

Если у пользователя нет Linux, а хочется использовать Git, Windows также поддерживает эту систему. И установить ее очень просто. Существует проект msysGit, процедура установки которого является одной из самых простых. Необходимо просто загрузить файл инсталлятора, который можно найти на странице проекта в GitHub, а затем запустить его. По окончании установки на компьютере будет две версии — графическая и консольная.

Первоначальная настройка Git

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

Git включает в себя утилиту git config, позволяющую делать настройки и контролировать работу системы, а также внешний вид. Данные параметры могут сохраняться в трех местах:

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

Пользовательское имя

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

Если указать опцию –global, такие настройки нужно будет сделать один раз.

Выбор текстового редактора

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

Проверка параметров

Чтобы знать основы Git, необходимо уметь проверять используемые настройки. Для этого применяется команда git config –list. Она выводит все доступные параметры, которые сможет найти. Некоторые имена настроек могут присутствовать в списке несколько раз. Это происходит из-за того, что Git считывает один ключ из различных файлов. В такой ситуации для каждого ключа используется последнее значение. Есть возможность проверять значения определенных ключей, вписав в команду вместо «—list» — «{ключ}».

Строим репозитории

В первую очередь нужно понять что такое git-репозиторий? Ответ очень прост: это набор файлов. Папка `.git`. Важно понимать, что это только набор файлов и ничего больше. Раз 20 наблюдал проблему у коллег с авторизацией в github/gitlab. Думая, что это часть git-системы, они пытались искать проблему в конфигруации git, вызывать какие-то git-команды.
А если это просто файлы, то к ним нужно как-то получить доступ, иметь возможность оттуда читать и туда писать? Да! Я называю это «транспортом». Это может и некорректно, но мне так было удобно запомнить. Более правильный вариант: «Протокол передачи данных». Самые распространённые варианты:

  1. FILE — мы имеем прямой доступ к файлам репозитория.
  2. SSH — мы имеем доступ к файлам на сервере через ssh.
  3. HTTP(S) — используем http в качестве приёма/передачи.

Вариантов намного больше. Не важно какой транспорт будет использован, важно чтобы был доступ на чтение или чтение/запись к файлам.
Поэтому, если вы никак не можете клонировать репозиторий с github, и нет в логах никаких подсказок, возможно у вас проблема с транспортом.
В частности, при клонировании вот так:
git clone [email protected]:user/repo.git
урл «превращается» в
git clone ssh://[email protected]:user/repo.git
Т.е. используется SSH и проблемы нужно искать в нём. Как правило, это неправильно настроенный или не найденный ssh-ключ. Гуглить надо в сторону «SSH Auth Key git» или, если совсем по взрослому, проверить, что же происходит:
ssh -vvv [email protected]
Какие протоколы поддерживаются поможет справка (раздел GIT URLS):
git clone —help
Репозиторий можно клонировать, но для начала поиграемся со своими:

  1. Придумаем свой удалённый репозиторий
  2. Сделаем два клона с него, от имени разработчиков (dev1 и dev2)

Кроме самого репозитория есть ещё и workspace, где хранятся файлы с которыми вы работаете. Именно в этой папке лежит сам репозиторий (папка .git ). На серверах рабочие файлы не нужны, поэтому там хранятся только голые репозитории (bare-repo).
Сделаем себе один (будет нашим главным тестовым репозиторием):
$ mkdir git-habr #создадим папку, чтоб не мусорить $ cd git-habr $ git init —bare origin Initialized empty Git repository in /home/sirex/proj/git-habr/origin/
Теперь клонируем его от имени разработчиков. Тут есть только один нюанс, которого не будет при работе с сервером: git, понимая, что репозитории локальные и находятся на одном разделе, будет создавать ссылки, а не делать полную копию. А нам для изучения нужна полная копия. Для этого можно воспользоваться ключом —no-hardlinks или явно указать протокол:
$ git clone —no-hardlinks origin dev1 Cloning into ‘dev1’… warning: You appear to have cloned an empty repository. done. $ git clone —no-hardlinks origin dev2 Cloning into ‘dev2’… warning: You appear to have cloned an empty repository. done.
Итог: у нас есть 3 репозитория. Там ничего нет, зато они готовы к работе.

Создание в данном каталоге

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

Клонирование репозитория

Для получения копии уже существующего репозитория нужна команда git clone. С ее помощью Git получит копию почти всех данных с сервера. Это касается всех версий каждого файла. Очень удобная возможность, так как в случае выхода из строя сервера программист сможет использовать клон на любом клиенте для возврата сервера в то состояние, в каком он был при клонировании. Это похоже на точку восстановления.

Удаленный доступ и его особенности

Командная работа над проектом невозможна без обучения управлению удаленными репозиториями. Каждая модификация проекта хранится в Сети или на сервере системы контроля версий, такой как Git. Вариантов проекта с небольшими отличиями может быть несколько, и все они доступны другим разработчикам. Некоторые репозитории можно только просматривать, в другие разрешено вносить изменения. Для каждого такого действия в системе Git существует несколько специальных команд, позволяющих управлять удаленными копиями проектов. Все они являются модификацией основной команды — git remote.

Управление удаленным репозиторием в Git

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

Особенности удаленного доступа

Записи, зарегистрированные при помощи команды удаленного доступа, используются в сочетании с командами git remote push, fetch и pull. Как git fetch, так и git pull можно использовать для чтения из удаленного репозитория. Команда git remote позволяет создавать, просматривать и удалять подключения к другим репозиториям. Например, push используется для того, чтобы поместить данные в хранилище, а pull, наоборот, чтобы получить. Команда fetch нужна, чтобы извлечь всю информацию, отсутствующую на локальной копии, из удаленного репозитория. После ее выполнения создаются ссылки на все новые ветки, в которых находятся недостающие данные. То есть обновления не сливаются с текущим проектом, а располагаются отдельно.

Впоследствии данные нужно будет сливать вручную, если возникнет такая необходимость. Для автоматического извлечения и соединения репозиториев используется git remote pull. Удаленные подключения больше напоминают закладки, чем прямые ссылки в другие репозитории. Вместо предоставления доступа в режиме реального времени они служат удобными именами, которые могут использоваться для ссылки на не очень удобный URL-адрес.

Команда удаленного доступа по сути является интерфейсом для управления списком записей, которые находятся в файле ./.git/config. Она нужна для управления удаленными хранилищами, удаления несуществующих, отслеживания определенных веток и смены адресов удаленных репозиториев (git change remote).

Отображение удаленных хранилищ

По умолчанию Git удаляет список ранее сохраненных удаленных подключений к другим репозиториям. При этом создается строка, в которой будут указаны имена удаленных репозиториев. Вызов git remote с параметром -v покажет список имен закладок репозитория и, кроме того, соответствующие им URL-адреса. Опция -v означает verbose. Команда git remote add создаст новую запись соединения в удаленном репозитории. После того как удаленная запись была настроена при помощи команды удаленного доступа, ее имя может быть передано другим командам Git для связи с хранилищем.

Конфигурация команды удаленного доступа

Ниже рассмотрены варианты использования команды для управления репозиториями. Простая запись git remote выдает список удаленных подключений. Существует несколько ее конфигураций. Команда удобна для внесения изменений в файл ./.git/config. Также его можно редактировать и вручную при помощи текстового редактора. Команда для удаленного доступа Git является одной из тех, что принимает дополнительные “подкоманды”.

Варианты “подкоманд”:

  1. Команда “git remote add ” используется для создания нового подключения к удаленному репозиторию. После добавления удаленного управления появляется возможность использовать как удобный ярлык для в других коман

Pro Git: Git шпаргалка

Создание локального репозитория

Создание репозитория в папке где выполняется команда
$ git init

Создание репозитория в указанном каталоге
$ git init <directory>


Создание репозитория Git для совместной работы


$ git init —bare —share sharedproject.git

Данная команда создает каталог с именем sharedproject.git c правами на запись в него. Подробнее тут.

Клонирование удаленного репозитория в локальный

Клонирование удаленного репозитория в локальный каталог с именем по умолчанию
$ git clone https://github.com/n0tb0dy/RemoreBranches.git

Клонирование удаленного репозитория в локальный каталог с указанным именем
$ git clone https://github.com/n0tb0dy/RemoreBranches.git LocalBranches

Клонирование локального репозитория на удаленный

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

1. Связываем локальный репозиторий с удаленным
$ git remote add origin https://github.com/n0tb0dy/UpRemote.git

2. Верифицируем что удаленный репозиторий связан с нашим
$ git remote -v

3. Публикуем ветку master на удаленном репозитории
$ git push -u origin master

Более подробно можно почитать тут.

Задаем имя пользователя и электронную почту

Глобально для всех проектов текущего пользователья
$ git config —global user.name «John Doe»
$ git config —global user.email [email protected]

Для конкретного проекта (эти настройки переопределят глобальные)
$ git config —local user.name «John Doe»
$ git config —local user.email [email protected]

Просмотр настроек Git

Всех (глобальных, системных и локальных). Некоторые параметры могут появится в списке несколько раз, так как читаются из трех файлов настроек. Подробнее тут.
$ git config —list

Локальных для определенного проекта
$ git config —local —list

Системных
$ git config —system —list

Получение справки (помощи) по команде Git

$ git help <verb>
$ git <verb> —help

Например выведем справку по команде config (откроется браузер со справкой)
$ git help config

Настройка русских шрифтов (cp1251) в Git

Настраиваем правильное отображение файлов с русскими названиями в командах Git
$ git config —local core.quotepath false

Настраиваем кодировку Windows cp1251 для коммитов в Git
$ git config —local core.pager «iconv.exe -f cp1251 -t utf-8 | less»
$ git config —local i18n.commitEncoding utf8
$ git config —local i18n.logoutputencoding cp1251

Эти команды замечательно работают в msysgit 1.9.5. Как будет в других версия не знаю. Но надеюсь, что в более новых тоже будет работать. Более подробно про настройку русского языка в Git можно почитать тут. Так же они правильно работают  при установке Git из пакетов Cygwin, подробнее можно почитать тут.

Так же можно задать кодовую страницу для файлов проекта командой
$ git config —local i18n.filesEncoding windows-1251

ну или просто строкой в разделе [i18n]
filesEncoding = windows-1251

А вообще лучше вести проекты в кодировке UTF-8, если это возможно конечно.

Просмотр информации о состоянии файлов в Git

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда:
$ git status

И ее более краткий вывод:
$ git status -s

Просмотр разницы (что конкретно было изменено в файлах) между рабочим каталогом и индексом (staged area)
$ git diff

Просмотр разницы между последним коммитом и индексом
$ git diff —staged

Более подробно смотрим тут.

Фиксация изменений (коммит)

Если дать команду git commit без дополнительных параметров, то сперва будет вызван редактор для ввода комментария к коммиту и после сохранения комментария будет произведен коммит (фиксация изменений)
$ git commit

Чтобы включить в комментарий к коммиту информацию о том какие именно были сделаны изменения в каких файлах надо дать команду
$ git commit -v

По существу по данной команде в комментарий будет также помещена дельта diff изменений, таким образом вы сможете точно увидеть всё, что сделано.

Чтобы редактор не вызывался, можно написать комментарий прямо в командной строке в ключе -m
$ git commit -m «Commit Comment»

Автоматически добавить все измененные файлы в коммит
$ git commit -a

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

Удаление файла из отслеживаемых Git, а так же его физическое удаление из рабочего каталога
$ git rm <file_name>

Удаление проиндексированного измененного файла
$ git rm -f <file_name>

Удаление файла из индекса, но сохранение его в рабочем каталоге
$ git rm —cached <file_name>

Более подробно смотрим тут.

Переименование файла

$ git mv <old_file_name> <new_file_name>

Просмотр истории коммитов

Самый простой вариант это git log с разными ключами (смотрим help). Тут приведу просто примеры. А подробнее тут или в мануале.

Вывод простой истории коммитов
$ git log

Вывод последних n записей, в примере вывод двух последних записей
$ git log -2

Вывод дельты (diff) разницы между последними двумя изменениями (на уровне строк)
$ git log -p -2

Вывод изменений между двумя последними коммитами на уровне слов
$ git log -p -2 —word-diff

Вывод краткой статистики по 2 последним коммитам
$ git log -2 —stat

И очень полезный ключ —pretty (позволяет изменить формат вывода лога)
$ git log —pretty=oneline

$ git log —pretty=format:»%h — %an, %ar : %s»

Параметры ключа format

ПараметрОписание выводимых данных
%HХеш коммита
%hСокращённый хеш коммита
%TХеш дерева
%tСокращённый хеш дерева
%PХеши родительских коммитов
%pСокращённые хеши родительских коммитов
%anИмя автора
%aeЭлектронная почта автора
%adДата автора (формат соответствует параметру --date=)
%arДата автора, относительная (пр. «2 мес. назад»)
%cnИмя коммитера
%ceЭлектронная почта коммитера
%cdДата коммитера
%crДата коммитера, относительная
%sКомментарий

Можно так же посмотреть ASCII граф веток коммитов по ключу —graph
$ git log —pretty=format:»%h  %s» —graph

Есть параметры, ограничивающие по времени, такие как —since и —until, весьма полезны. Например, следующая команда выдаёт список коммитов, сделанных за последние две недели:
$ git log —since=2.weeks

Другой полезный фильтр это опция –S, которая как параметр принимает строку и показывает только те коммиты где эта строка была изменена, добавлена или удалена.
$ git log -S<stirng>

Пример будет искать строку MyStringForSearch
$ git log -SMyStringForSearch

Список коммитов с хэшем (короткое число)
$ git log —oneline

Отмена изменений

Изменение комментария к последнему комииту, но только в том случае, если после последнего коммита не было ни каких изменений в рабочем каталоге
$ git commit —amend

Отмена индексации файла (исключение из индекса)
$ git reset HEAD <file>

Отмена изменений файла (до внесения файла в коммит)
$ git checkout — <file>

С этой командой надо быть особо осторожным, подробнее тут.

Удаление раз и навсегда последнего коммита. Его больше ни кто ни когда не увидит. И вы в том числе :). Произойдет откат на предыдущий коммит. Все изменения которые были в последнем коммите будут утеряны. Хорошо подумайте прежде чем это делать.
$ git reset —hard HEAD~1

Работа с удаленными репозиториями

Просмотр удаленных репозиториев
$ git remote

Более подробный вывод о них
$ git remote -v

Добавление удаленного репозитория (вместо origin можно задать любое слово)
$ git remote add origin https://github.com/n0tb0dy/UpRemote.git
$ git remote add tr https://github.com/n0tb0dy/UpRemote.git

Получение изменений с удаленного репозитория под именем tr в локальную ветку tr
$ git fetch tr

Отправка данных на удаленный репозиторий. Формат git push [удал. сервер] [локальная ветка]
$ git push origin master

Инспекция удаленного репозитория git remote show [удал. сервер]
$ git remote show origin

Переименование удаленных репозиториев (по существу переименование локальной ссылки на удаленный репозиторий)
$ git remote rename <old_name> <new_name>
$ git remote rename tr newtr

Удаление удаленного репозитория 🙂 (попросту отключение от него — в примере от origin)
$ git remote rm origin

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

Если у вас свой собственный репозиторий Git на сервере с само подписанным сертификатом, то перед любыми командами работы у удаленным репозиторием (clone, fetch, push, pull и т.п.), Git будет ругаться на само подписанный сертификат. Решить проблему можно изменив чуток конфиг
$ git config —local http.sslVerify false

Или же перед каждой операцией работы с удаленным репозиторием вставлять доп команду
$ git -c http.sslVerify=false push origin newbranch

А вообще настройка своего сервера Git это отдельная тема. Частично рассмотрена мной тут.

Работа с ветками

Посмотреть локальные ветки
$ git branch

Посмотреть последний коммит на каждой из локальных веток
$ git branch –v

Чтобы посмотреть все существующие локальные и удаленные ветки можно дать команду
$ git branch –a

Посмотреть последние коммиты на всех ветках (локальных и удаленных)
$ git branch –a -v

Посмотреть отслеживаемые ветки
$ git branch –vv

Сделать ветку локальную ветку serverfix отслеживаемой
$ git branch -u origin/serverfix

Создать ветку
$ git branch <имя_ветки>

Создать ветку на определенном коммите
$git branch new_branch 5a0eb04

Переименовать ветку
git branch -m <oldname> <newname>

Переименовать текущую ветку
git branch -m <newname>

Переключится на ветку
$ git checkout <имя_ветки>


Создать ветку и сразу же переключится на нее
$ git checkout -b <имя_ветки>


Слияние веток (в примере находимся на ветке master и сливаем с ней ветку hotfix)
$ git checkout master
$ git merge hotfix

Удалить ветку
$ git branch -d <имя_ветки>


Удалить ветку serverfix на удаленном сервере
$ git push origin —delete serverfix

Работа с метками

Посмотреть все (перечисляет в алфавитном порядке, а не по времени их создания)
$ git tag

Посмотреть попадающие под маску
$ git tag -l ‘v1.4.2.*’

Создать метку на текущем коммите (ключ -а) с меточным сообщением (ключ -m)
$ git tag -a v1.4 -m ‘my version 1.4’

Если ключ -m не указывать то откроется окно редактора чтобы ввести сообщение

Создание легковесной метки на текущем коммите
$ git tag <имя_метки>
$ git tag MyTAG

Посмотреть метки вместе с комментариями к коммитам, а так же с именами поставивших метки
$ git show <tag>
$ git show MyTAG

Так же можно выставлять метки и на уже пройденные коммиты. Подробнее о метках тут.

Задание псевдонимов для команд Git

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

Задание псевдонимов в конфигах Git

$ git config —global alias.co checkout
$ git config —global alias.br branch
$ git config —global alias.ci commit
$ git config —global alias.st status

Теперь достаточно давать команды
$ git co
$ git br
$ git ci
$ git st

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

Кроме того в эти команды так же можно подставлять параметры
$ git config —global alias.unstage ‘reset HEAD —‘

Это делает эквивалентными следующие две команды:
$ git unstage fileA
$ git reset HEAD fileA

Более подробно по алисы в конфигах Git читаем тут.

Об алиасах заданных через Bash читаем тут.

Сравнение файла в разных коммитах

$ git diff ffd6b37 c258082 —cc test.txt

С помощью внешних утилит ExamDiffPro и P4Merge

Смотрим изменения файла test.txt между двумя коммитами
$ git difftool 9491cc8 02c1df6 —tool=edp —cc test.txt
$ git difftool 9491cc8 02c1df6 —tool=p4m —cc test.txt

Слияние (merge)

Самая главная и нужная команда слияния, это отмена слияния 🙂
$ git merge —abort

Всяко разно

Просмотр истории перемещения указателя HEAD
$ git reflog

Разбираемся с командами diff и show

Всем привет. Мы продолжаем изучать гит. И давайте напишем какую-то полезную функцию в наш файл 1.js, который мы создали на прошлом уроке.

function addNumber(a,b) {
  return a + b;
}

Если мы напишем git status, то увидим, что у нас есть модифицированные файлы и гит видит, что мы что-то изменили. Давайте посмотрим как гит видит наши изменения. Для этого воспользуемся командой

git diff

Нам в консоль вывелся только 1 файл, который был изменен. Зеленым показаны строчки, которые были добавлены, а красным которые удалены. Сейчас мы видим только зеленые строчки.

Давайте закоммитим наши изменения как в прошлом уроке. Для этого напишем

git add 1.js

чтобы зафиксировать наши изменения.

git commit -m "Added addNumber function"

Чтобы создать коммит.

Если мы напишем git log, то увидим, что у нас сейчас уже 2 коммита. Первый коммит с прошлого урока и коммит, который мы добавили только что.

Если вдруг коммитов у нас много и мы хотим посмотреть изменения определенного коммита, то мы можем написать команду git show и указать id коммита.

git show ID

И на экране мы видим то же самое, что мы видели, когда смотрели дифф незакоммиченых файлов.

Давайте изменим функцию в файле на функцию отнимания

function deductNumber (a, b) {
  return a - b;
}

Если мы теперь напишем git diff, то нам выведемтся в консоль красным что мы удалили, а зеленым что добавили.
Мы удалили слово add и добавили deduct, так же мы поменяли плюс на минус. И гит все эти изменения трекает.
Давайте закоммитим это изменения тоже.

Если вы хотите добавить сразу все файлы, которые вы изменили то можно писать git add .

git add .
git commit -m "Changed addNumber to deductNumber"

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

Руководство по Git. Просмотр истории изменений. – PROSELYTE

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

Для этих целей в Git предусмотрена команда:


 git log

Попробуем выполнить эту команду в нашем проекте:


git log

commit 11f75b7bc8884203624ba1d552438d57a7c3559d
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 19:15:53 2016 +0300

    Adding .gitignore file.

commit 5e0298b007582bec3a8f4f68db74ba4ddfa40838
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 19:15:21 2016 +0300

    Adding .gitignore file

commit 97d5de493ac15f821b109b7b0375d4f94e1f2dd1
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 19:10:41 2016 +0300

    Adding classes Developer.java and Project.java

commit a0f051aa654aa43db508f460b5bd28e8a41fe2ae
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 17:43:12 2016 +0300

    Initial commit of the project.

commit 0853db5f06305eae525b954f587ecc49c62debd9
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 17:41:35 2016 +0300

    Initial commit of the project

commit 5e8179a97b971f8fd11118e64f4d624b5ddf3ea6
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 17:20:53 2016 +0300

    Initial commit of the project

commit 3c199cf96dba9131bb3df299aa819b9cbef6a870
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 17:20:27 2016 +0300

    Initial commit of the project
(END)

Здесь число рядом со словом commit – это SHA-1 идентификатор ID коммита.

Для того, чтобы просмотреть более подробную информацию по коммиту (используя SHA-1 ID коммита) мы можем использовать следующую команду:



git show 11f75b7bc8884203624ba1d552438d57a7c3559d

commit 11f75b7bc8884203624ba1d552438d57a7c3559d
Author: Eugene Suleimanov <[email protected]>
Date:   Wed Aug 17 19:15:53 2016 +0300

Adding .gitignore file.

diff --git a/.idea/workspace.xml b/.idea/workspace.xml
index a4cab11..b0392f8 100644
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@ -1,9 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ChangeListManager">
-    <list default="true" name="Default" comment="">
-      <change type="MODIFICATION" beforePath="$PROJECT_DIR$/.idea/workspace.xml" afterPath="$PROJECT_DIR$/.idea/workspace.xml" />
-    </list>
+    <list default="true" name="Default" comment="" />
<ignored path="GitTutorial.iws" />
<ignored path=".idea/workspace.xml" />
<ignored path="$PROJECT_DIR$/out/" />
@@ -690,12 +688,12 @@
<option name="number" value="Default" />
<option name="presentableId" value="Default" />
<updated>1471442570577</updated>
-      <workItem from="1471442574162" duration="5174000" />
+      <workItem from="1471442574162" duration="5219000" />
</task>
<servers />
</component>
<component name="TimeTrackingManager">
-    <option name="totallyTimeSpent" value="5174000" />
+    <option name="totallyTimeSpent" value="5219000" />
</component>
<component name="ToolWindowManager">
<frame x="0" y="24" extended-state="6" />

Таким образом мы всегда можем получить подробную информацию по всем изменениям в репозитории.

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

Пошаговая инструкция по работе с системой контроля версий GIT и сервисом GitHub для новичков

Наверняка многие слышали о системе контроля версий git. Сегодня мы рассмотрим весь путь от установки git до внесения своих изменений в удаленный репозиторий на примере библиотеки OsEngine.Для начала скачаем клиент git по ссылке и установим его. Вопросов возникнуть не
должно, просто везде жмем Next. Далее взаимодействие с git будет рассмотрено на примере работы с консольным клиентом.Следующим шагом необходимо зарегистрироваться на сайте https://github.com/. Теперь мы можем присоединиться к работе над OsEngine. Для этого перейдем к репозиторию проекта и в правом верхнем углу нажмем кнопку Fork.

Этим действием мы создали fork (другими словами ответвлние), который хранится в репозитории нашей учетной записи и теперь можно вносить в него изменения, не опасаясь чего-то сломать в главной ветке проекта. Далее этот самый наш репозиторий на github мы будем называть удаленным репозиторием.
Теперь приступим к работе с самим git и первым делом нам надо создать на своем компьютере локальную копию удаленного репозитория. Для этого переходим в желаемую папку, в контекстном меню выбираем пункт Git Bash Here и у нас откроется консоль.

Дальше идем на github в наш репозиторий и нажимаем на зеленую кнопку Clone or download (1) и затем на кнопку под номером 2 на снимке.

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

$ git clone «здесь вставляем ссылку без кавычек»

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

Работа с локальным репозиторием

Настройка git

Перед началом работы с git, его необходимо настроить. Откройте git bash, задайте логин и пароль командами:

$ git config —global user.name “ваше имя”
$ git config —global user.email “ваша почта”

Посмотреть файл конфигурации позволяет команда:

$ git config —global —list


Работа с ветками

Ветки в git это тоже самое что и ветки на github. Чтобы создать новую ветку, выполните в консоли команду:

$ git branch желаемое имя

Чтобы переключаться на эту ветвь выполните команду:

$ git checkout имя ветки

для возврата в основную ветку наберите:

$ git checkout master

переименовать ветку:

$ git branch –m новое имя

команда $ git branch позволяет определить в какой ветке сейчас находимся. Удаляет ветку команда

$git branch –D имя ветки

слияние ветки с основной выполняется командой:

$ git merge имя ветки

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

Коммиты

Вся суть использования git в commits (коммиты). Коммит – это так называемый снимок состояния проекта на определенном этапе
разработки. Например: у нас есть библиотека OsEngine, мы добавили в
нее новый индикатор и закоммитили, потом решили подправить какой-либо файл в
движке и после этого приложение крашится или не хочет правильно работать. Чтобы
не делать лишнюю работу и не править все обратно, мы можем просто напросто
откатиться к прошлому коммиту, когда приложение работало как надо. Соответственно
вся работа с git крутится вокруг создания, удаления, редактирования, слияния
коммитов и веток.

Добавление файлов в индекс

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

$ git add README

и файл README будет добавлен в индекс, если надо проиндексировать все обновленные и новые файлы, то выполняем

$ git add .

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

Удаление файлов из индекса

Если вы случайно проиндексировали не нужный файл, то удалить его из индекса поможет команда git reset, например удалить файл README из индекса:

$ git reset README

Если вы передумали оставлять изменения внесенные в файл, выполните команду

$ git checkout — имя файла

и он вернется в то состояние, в котором находился во время последнего коммита, только учтите, что все изменения в этом файле исчезнут.

Создание коммита

Теперь можно коммитить изменения, делается это при помощи команды:

$ git commit –m “Здесь должен быть комментарий в кавычках”

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

$ git log

$ git show покажет только последние изменения. Для выхода из режима просмотра нажмите q.

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

$ git commit –a –m “комментарий в кавычках”

-a означает: добавить все изменения в индекс до передачи.
-m: комментарий.

Редактирование, удаление, коммита

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

$ git revert HEAD

Отсчет комитов ведется с 0 начиная с последнего, например, если нужно отменить третий коммит, то следует выполнить:

$ git revert HEAD~2

Команда $ git reset —soft HEAD~3 удалит 3 последних коммита и откатит проект в состояние четвертого коммита, при этом сохранив в индексе все изменения последних трех коммитов.

$ git reset — hard HEAD~3

полностью удалит три последних коммита.

Состояние файлов

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

Внесение локальных изменений в удаленный репозиторий

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

$ git push origin master

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

$ git pull


Использование SSH ключей

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

$ ssh-keygen

Далее 3 раза нажать enter и в дирректории по умолчанию C:\Users\имя пользователя\.ssh появиться папка с ключами. Нужно открыть файл
id_rsa типа PUB в любом текстовом редакторе и скопировать его содержимое. Затем идем на github в настройки своей учетной записи

После чего в колонке слева выбираем пункт: SSH and GPG keys и жмем зеленую кнопку справа New SSH key

задаем Title, в поле Key вставляем данные, скопированные из ключа и жмем

Слияние веток на github

После того как вы внесли все необходимые изменения в свой удаленный репозиторий, можно отправить запрос на слияние с главным репозиторием проекта OsEngine. Просто нажмите кнопку New pull request

а затем

В данной статье мы рассмотрели основные команды git, их хватит для начала работы над проектом OsEngine, используя git и сервис github.

Удачных коммитов!

git-log — Показать журналы фиксации — страница руководства

— follow

Продолжить перечисление истории файла без переименования (работает только для одного файла).

—no-decorate, —decorate [= short | full | auto | no]

Распечатайте ссылочные имена всех отображаемых коммитов. Если указано short , префиксы имен ссылок refs / Heads / , refs / tags / и refs / remotes / не будут напечатаны. Если указано full , будет напечатано полное имя ссылки (включая префикс).Если указано auto , то, если вывод идет на терминал, имена ссылок отображаются, как если бы были заданы short , в противном случае имена ссылок не отображаются. Вариант по умолчанию — короткий .

—decorate-refs = , —decorate-refs-exclude =

Если не указано —decorate-refs , сделайте вид, что включены все ссылки. Для каждого кандидата не используйте его для украшения, если он соответствует каким-либо шаблонам, заданным для —decorate-refs-exclude , или если он не соответствует ни одному из шаблонов, заданных для —decorate-refs .Параметр конфигурации log.excludeDecoration позволяет исключить ссылки из декораций, но явный шаблон —decorate-refs переопределит совпадение в log.excludeDecoration .

—source

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

— [no-] mailmap, — [no-] use-mailmap

Используйте файл mailmap для сопоставления имен авторов и коммиттеров и адресов электронной почты с каноническими реальными именами и адресами электронной почты.См. Git-shortlog (1).

—full-diff

Без этого флага git log -p … показывает коммиты, которые касаются указанных путей, и различает примерно те же указанные пути. При этом отображается полная разница для коммитов, которые касаются указанных путей; это означает, что « …» ограничивает только коммиты и не ограничивает разницу для этих коммитов.

Обратите внимание, что это влияет на все типы вывода на основе различий, например производимые — стат и др.

—log-size

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

-L <начало>, <конец>: <файл>, -L: <имя функции>: <файл>

Проследить эволюцию диапазона строк, заданного «<начало>, <конец>» (или имя функции regex ) внутри .Вы не можете указывать никакие ограничители pathspec. В настоящее время это ограничено обходом, начиная с одной ревизии, т.е. вы можете указать только ноль или один положительный аргумент ревизии, а и (или ) должны существовать в начальной ревизии. Вы можете указать эту опцию более одного раза. Подразумевается — патч . Вывод патча может быть подавлен с помощью —no-patch , но других форматов различий (а именно —raw , —numstat , —shortstat , —dirstat , —summary , —name-only , —name-status , —check ) в настоящее время не реализованы./ regex / », поиск будет выполняться с начала файла. Если является регулярным выражением, поиск будет выполняться, начиная со строки, заданной .

  • + смещение или -смещение

    Это действительно только для и будет определять количество строк до или после строки, заданной .

    • Если вместо и указано «: », это регулярное выражение, обозначающее диапазон от первой строки funcname, которая соответствует , до следующей строки funcname .: »выполняет поиск с начала файла.

    <диапазон ревизий>

    Показать только коммиты в указанном диапазоне ревизий. Если <диапазон ревизий> не указан, по умолчанию используется значение HEAD (т.е. вся история, ведущая к текущему фиксации). origin..HEAD указывает все коммиты, доступные из текущего коммита (то есть HEAD ), но не из origin . Полный список способов написания <диапазон ревизии> см. В разделе Определение диапазонов gitrevisions (7).

    [-] <путь> …

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

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

    Ограничение фиксации

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

    Использование большего количества параметров обычно дополнительно ограничивает вывод (например, —since = ограничивает коммиты новее, чем , и использование его с —grep = дополнительные ограничения для коммитов, чьи сообщение журнала содержит строку, которая соответствует <шаблон> ), если не указано иное.

    Обратите внимание, что они применяются перед параметрами упорядочивания и форматирования фиксации, например —reverse .

    — <число>, -n <число>, —max-count = <число>

    Ограничить количество коммитов для вывода.

    —skip =

    Пропустить номер коммитов перед тем, как начать показывать результат фиксации.

    —since = , —after =

    Показать коммиты более поздние, чем указанная дата.

    —until = <дата>, —before = <дата>

    Показать коммиты старше указанной даты.

    —author = , —committer =

    Ограничить вывод коммитов теми, у которых строки заголовка автора / коммиттера соответствуют указанному шаблону (регулярному выражению).С более чем одним —author = выбираются коммиты, автор которых соответствует любому из заданных шаблонов (аналогично для нескольких —committer = ).

    —grep-reflog =

    Ограничить вывод коммитов теми, у которых записи reflog соответствуют указанному шаблону (регулярному выражению). С более чем одним —grep-reflog выбираются коммиты, сообщение reflog которых соответствует любому из заданных шаблонов. Использование этой опции будет ошибкой, если не используется —walk-reflogs .

    —grep =

    Ограничить вывод коммитов теми, в которых сообщение журнала соответствует указанному шаблону (регулярному выражению). С более чем одним —grep = выбираются коммиты, сообщение которых соответствует любому из заданных шаблонов (но см. —all-match ).

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

    —all-match

    Ограничить вывод коммитов теми, которые соответствуют всем заданным —grep , вместо тех, которые соответствуют хотя бы одному.

    —invert-grep

    Ограничить вывод коммитов теми, которые содержат сообщения журнала, которые не соответствуют шаблону, указанному в —grep = .

    -i, —regexp-ignore-case

    Сопоставление шаблонов ограничения регулярного выражения без учета регистра букв.

    —basic-regexp

    Считайте ограничивающие шаблоны базовыми регулярными выражениями; это значение по умолчанию.

    -E, —extended-regexp

    Считайте ограничивающие шаблоны расширенными регулярными выражениями вместо базовых регулярных выражений по умолчанию.

    -F, —fixed-strings

    Считайте ограничивающие шаблоны фиксированными строками (не интерпретируйте шаблон как регулярное выражение).

    Первые шаги с git: clone, add, commit, push | Наука о данных о Земле