Введение в git: от установки до основных команд

10 шагов для работы с проектом

Создаем локальную копию вашего проекта

Для github project_url можно найти нажав зеленую кнопку «Clone or download» на странице проекта.
Обновляем локальную копию — подгружаем изменения, которые внесли другие участники в эту ветку

Узнаем название вашей текущей ветки, смотрим какие файлы были изменены локально, смотрим какие комиты (commits) вы не отправили на общий сервер

Выкидываем все ваши локальные изменения

Применять осторожно, можно выстрелить в ногу.

Примечание: современные IDE хранят историю изменения файлов локально, так что ничего страшного. Стреляйте.
Создаем ветку, обычно по имени задачи в JIRA

Примечание: ветка создается от той ветки в которой вы в настоящий момент находитесь (см. предыдущий пункт), поэтому как правило надо сначала переключиться в ветку master. Если есть измененный файлы, то ничего страшного — они никуда не пропадут.
Переключаемся в ветку master:

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

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

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

После внесения локальных изменений их надо так сказать «закомитить». Надо отметить, что git вносит изменения (создает новый commit) в вашу локальную версию, на сервер ничего не отправляет. Для отправки на сервер есть другая команда. Лично я комичу из IDE. Но можно и руками.
Сообщаем git какие файлы мы хотим закомитить:
Или сразу все файлы
Коммитим:

Отправляем файлы в репозиторий на сервере

Примечание — git ругается, что не знает куда отправлять — смотри примечание к пункту 2.
Отправляем изменения на просмотр (review) другим участникам. Это UI штука, к git отношения не имеет. В github, например, надо просто в UI перейти в свою ветку и создать Pull request (PR)
Сливаем ваши изменения в основную ветку. Тут есть несколько вариантов. По умолчанию git просто встроит все ваши комиты в общую ветку. То есть все увидят ваши нелепые попытки исправить несобирающийся билд, падающие тесты и просто вечерние комиты, которые вы сделали, чтобы не потерять результаты кропотливого дневного труда. Это хорошо, если вы эксбиционист, но как правило жедательно все комиты собрать в один и встроить в общую ветку именно одним комитом (т.н. squash commit) — так другим будет легче разобраться что же вы сделали перед тем, как что-то пошло не так и откатить ваши изменения. Поэтому желательно делать squash:
В интерфейсе github есть зеленая кнопочка «squash & commit». Через UI переходим в свою ветку, создаем Pull request (PR), а потом в интерфейсе PR выбираем и жмете «squash & commit».

Переходим в основную ветку (master)

, обновляемся

, делаем squash commit. Все изменения, из нашей ветки появятся как локальные, но уже в основной ветке. Смотрим что мы наваяли. Посмотреть изменения — пункт 3. Комитим — пункт 8, отправляем на сервер — пункт 9. Можно делать squash commit не в основную ветку, а завести новую, сделать в нее squash commit и из нее сделать merge в основную (смотри следующий пункт).

Ваши комиты в этом случае не склеятся в один. Переходим в основную ветку (master)

, обновляемся

, делаем обычный commit

, отправляем на сервер — пункт 9.

Можно сделать rebase ветки и, например, склеить все ваши комиты в один.

Метрики CI/CD в GitLab

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

Хорошей новостью является то что GitLab имеет функционал сбора этой статистики. Давайте с этим функционалом познакомимся.

! Кликните на Analytics. По умолчанию откроется раздел Value stream. В Lean вообще и в DevOps в частности считается что задачи несут в конечном итоге некоторую пользу для конечного заказчика. И движение таких полезных задач, от стадии формулирования через все этапы работы до того момента когда результаты становятся доступны заказчику называется value stream.

Основные средние величины по этапам:

• Issue — время которое уходит на то чтобы задачу «взять в работу» т.е. присвоить метку или добавить в Milestone.
• Plan — время от последнего действия в предыдущем этапе до появления первого коммита в ветке, хоты бы один из коммитов которой связан с той же задачей. То есть «время, которое уходит чтобы начать коммитить».
• Code — время существования ветки, связанной с той или иной задачей, которое уходит до появления merge request’a.
• Test — время от начала до конца всех конвейеров данного проекта.
• Review — время от создания merge request’а до его слияния или закрытия.
• Staging — время от принятия merge request до развёртывания в продуктивную среду.

Если вы сложите длительность Issue, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).

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

Analytics -> Repository показывает разные графики связанные с языками коммитов, показателями code coverage (если настроено), распределением коммитов во времени (месяц, дни недели, часы).

Analytics -> CI/CD показывает сводные данные по выполенным pipelines, в том числе график показывающий динамику изменения «успешности» выполнения pipelines.

Добавляем и изменяем файлы

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Теперь мы готовы сделать свой первый коммит (commit). По факту это фраза означает внесения изменения в текущую ветку в локальном репозитории. Чтобы это сделать, нужно написать краткое сообщение, отражающее суть изменений, чтобы потом было проще в них ориентироваться. В данном случае мы добавили новый текстовый файл (сообщение может быть на любом языке, необязательно на английском). Github сам нам подсказал название коммита. Так же мы можем добавить описание изменений, чтобы другим пользователям было проще.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов — это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
3. Просим клиента внести изменённые файлы в репозиторий. Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
4. После коммита версия вашего локального репозитория изменилась.
5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

Ветки — это своеобразные папки со всеми файлами проекта. Ветка Master — это самая главная папка вашего проекта, она всегда существует. Дополнительные ветки создаются под всякие дополнительные нужды.

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

Скрывайте лишнее через git exclude

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

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

(Не забудьте подставить Ваш любимый редактор.)

использует тот же синтаксис, что и .
Добавленные туда паттерны будут скрывать файлы только в вашем репозитории.
Обратите внимание, что их действие, как и у распространяется только на неотслеживаемые (untracked) файлы. Уже отслеживаемые изменённые файлы будут «подсвечиваться» как и раньше

Если Вы добавили файл случайно и теперь хотите его скрыть (такое иногда бывает с локальными конфигами IDE, например, ), используйте — команда удалит файл из отслеживаемых, но оставит его локальную копию нетронутой, и вот теперь её можно будет скрыть через exclude.
Если хотите скрыть ряд файлов из всех-всех репозиториев, Вам поможет:

Скрывайте локальные изменения, когда не хотите их «вливать»

А теперь про то, когда Вы не хотите чтобы отслеживались изменённые файлы. Яркий пример: очень многие, особенно долгоживущие репозитории, хранят в себе ряд конфигов. Часто они служат для обеспечения единообразия настроек (к примеру, ) или тасков сборки/линтинга (). И иногда так случается, что хочется их как-то изменить, но возможность разделения конфигов на «общие» и «пользовательские» отсутствует.

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

С этих пор он «пропадает с радаров» даже если Вы продолжите его изменять. Если во время -а приходят новые изменения в этом же файле — в этом случае он будет продолжать считаться неизменённым, но легко смержиться Вам не даст. Чтобы вернуть всё как было, надо снять флаг, добавив :

Интерактивный rebase

rebase

• pick (выбрать) — Поведение по умолчанию, используемое для каждого коммита в ветке, если вы не используете интерактивный режим. Оно означает, что данный коммит должен быть применен к своему (теперь уже переписанному) родительскому коммиту. При возникновении конфликтов rebase предложит вам их разрешить.
• squash (сплющить)— Содержимое коммита будет «вложено» в содержимое предыдущего коммита. Это может быть сделано любое количество раз. Если взять вышеиспользованную для примера ветку и сплющить все ее коммиты (конечно же, кроме первого, который должен быть просто выбран), то новая ветка Z будет иметь единственный коммит поверх D. Это может быть полезным, если ваши изменения размазаны по множественным коммитам, но вы хотите, чтобы в истории они показывались как единый коммит.
• edit (редактировать) — если вы пометите коммит таким образом, то процесс rebase остановится, а вы попадете в оболочку, где сможете совершить дополнительные необходимые изменения, после чего команда rebase —continue продолжит исполнение так, будто внесенные изменения были там изначально.
• drop (выбросить) — если вы удалите коммит из интерактивного rebase, то он просто пропадет — так, будто никогда и не был сделан. Заметьте, что в этом случае возможны конфликты слияния, в случае если более поздние коммиты зависели от данных изменений.

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

rebaserebase

(тут переводчик снова тяжело вздыхает)

Что такое Git и зачем он нужен?

Git — это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок — полезно для дизайнеров.

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.

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

Каждая точка сохранения вашего проекта носит название коммит (commit). У каждого commit-a есть hash (уникальный id) и комментарий. Из таких commit-ов собирается ветка. Ветка — это история изменений. У каждой ветки есть свое название. Репозиторий может содержать в себе несколько веток, которые создаются из других веток или вливаются в них.

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

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

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

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

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла

Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Новый репозиторий

Создание нового репозитория

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

• Для начала перейдите в ваш репозиторий.
• Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
• В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
• Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
• Нажмите кнопку Commit changes.

Изменение файла на GitHub

Подготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request

Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

Install Git on Mac

Most versions of MacOS will already have installed, and you can activate it through the terminal with . However, if you don’t have Git installed for whatever reason, you can install the latest version of Git using one of several popular methods as listed below:

Install Git From an Installer

1. Navigate to the latest macOS Git Installer and download the latest version.
2. Once the installer has started, follow the instructions as provided until the installation is complete.
3. Open the command prompt «terminal» and type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git on a Mac. The advantage of downloading Git from is that your download automatically starts with the latest version of Git. The download source is the same macOS Git Installer as referenced in the steps above.

Install Git from Homebrew

Homebrew is a popular package manager for macOS. If you already have Homwbrew installed, you can follow the below steps to install Git:

1. Open up a terminal window and install Git using the following command: .
2. Once the command output has completed, you can verify the installation by typing: .

Создание репозитория

Создать репозиторий можно двумя способами:

• на сайте;
• через GitHub Desktop.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

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

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

• GNU GPL;
• MIT;
• Unlicense;
• WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Далее нажимаем на зеленую кнопку Create repository. Вы увидите список файлов в своем репозитории (пока это только автоматически сгенерированный файл README с описанием проекта) и содержание README, если он есть, а также файлы .gitignore и LICENSE, если они создавались. Ссылка на репозиторий будет выглядеть так: https://github.com/username/your_repo_name.git .

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

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

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .

Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.

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

Добавляем файлы в проект

Вот, чем мы займемся:

git statusgit addgit commit -m “ “git push

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

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

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать . После внесения изменений создается снимок состояния репозитория, для чего используется команда. А через добавляется сообщение об этом снимке.

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

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

git push

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

Актуальность версии можно проверить в любое время через команду .

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

• Как писать Bash-однострочники для клонирования и управления GitHub/GitLab репозиториями
• Top 100 наиболее популярных репозиториев на GitHub
• Основы Git за 5 минут

Основы git

2.1 Создание репозитория

• git init — Создаёт git репозитории и директорию .git в текущей директории (или в директории указанной после —separate-git-dir <каталог-git>, в этом случае директория .git будет находится в другом месте);
• git clone <репозиторий> — Клонирует репозитории с названием origin (или с тем которое вы укажите -o <имя>), находясь на той ветке, на которую указывает HEAD (или на той которую вы укажите -b <ветка>). Также вы можете клонировать только необходимую ветку HEAD (или ту которую укажите в -b <ветка>) указав —single-branch. По умолчанию клонируются все метки, но указав —no-tags вы можете не клонировать их. После выполнения команды создаётся директория .git в текущей директории (или в директории указанной после —separate-git-dir <каталог-git>, в этом случае директория .git будет находится в другом месте);

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

• -F, —file — Записать сообщение коммита из указанного файла
• —author — Подменить автора коммита
• —date — Подменить дату коммита
• -m, —mesage — Сообщение коммита
• -a, —all — Закоммитеть все изменения в файлах
• -i, —include — Добавить в индекс указанные файлы для следующего коммита
• -o, —only — Закоммитеть только указанные файлы
• —amend — Перезаписать предыдущий коммит

• pick <коммит> = использовать коммит
• reword <коммит> = использовать коммит, но изменить сообщение коммита
• edit <коммит> = использовать коммит, но остановиться для исправления
• squash <коммит> = использовать коммит, но объединить с предыдущим коммитом
• fixup <коммит> = как «squash», но пропустить сообщение коммита
• exec <команда> = выполнить команду (остаток строки) с помощью командной оболочки
• break = остановиться здесь (продолжить с помощью «git rebase —continue»)
• drop <коммит> = удалить коммит
• label <метка> = дать имя текущему HEAD
• reset <метка> = сбросить HEAD к указанной метке

Для изменения сообщения определённого коммита.Для удаления коммитаДля объединения коммитов

2.5 Просмотр истории

• -p — Показывает разницу для каждого коммита.
• —stat — Показывает статистику измененных файлов для каждого коммита.
• —graph — Отображает ASCII граф с ветвлениями и историей слияний.

• -(n) Показывает только последние n коммитов.
• —since, —after — Показывает коммиты, сделанные после указанной даты.
• —until, —before — Показывает коммиты, сделанные до указанной даты.
• —author — Показывает только те коммиты, в которых запись author совпадает с указанной строкой.
• —committer — Показывает только те коммиты, в которых запись committer совпадает с указанной строкой.
• —grep — Показывает только коммиты, сообщение которых содержит указанную строку.
• -S — Показывает только коммиты, в которых изменение в коде повлекло за собой добавление или удаление указанной строки.

• %H — Хеш коммита
• %h — Сокращенный хеш коммита
• %T — Хеш дерева
• %t — Сокращенный хеш дерева
• %P — Хеш родителей
• %p — Сокращенный хеш родителей
• %an — Имя автора — %ae — Электронная почта автора
• %ad — Дата автора (формат даты можно задать опцией —date=option)
• %ar — Относительная дата автора
• %cn — Имя коммитера
• %ce — Электронная почта коммитера
• %cd — Дата коммитера
• %cr — Относительная дата коммитера
• %s — Содержание

Step 5: Create a new branch

Now that you’ve made a new commit, let’s try something a little more advanced.

Say you want to make a new feature but are worried about making changes to the main project while developing the feature. This is where git branches come in. 

Branches allow you to move back and forth between ‘states’ of a project. Official git docs describe branches this way: ‘A branch in Git is simply a lightweight movable pointer to one of these commits.’ For instance, if you want to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you’re done with the page, you can merge your changes from your branch into the primary branch. When you create a new branch, Git keeps track of which commit your branch ‘branched’ off of, so it knows the history behind all the files. 

Let’s say you are on the primary branch and want to create a new branch to develop your web page. Here’s what you’ll do: Run git checkout -b <my branch name>. This command will automatically create a new branch and then ‘check you out’ on it, meaning git will move you to that branch, off of the primary branch.

After running the above command, you can use the git branch command to confirm that your branch was created:

The branch name with the asterisk next to it indicates which branch you’re on at that given time. 

Performance

The raw performance characteristics of Git are very strong when compared to many alternatives. Committing new changes, branching, merging and comparing past versions are all optimized for performance. The algorithms implemented inside Git take advantage of deep knowledge about common attributes of real source code file trees, how they are usually modified over time and what the access patterns are.

Unlike some version control software, Git is not fooled by the names of the files when determining what the storage and version history of the file tree should be, instead, Git focuses on the file content itself. After all, source code files are frequently renamed, split, and rearranged. The object format of Git’s repository files uses a combination of delta encoding (storing content differences), compression and explicitly stores directory contents and version metadata objects.

Being distributed enables significant performance benefits as well.

For example, say a developer, Alice, makes changes to source code, adding a feature for the upcoming 2.0 release, then commits those changes with descriptive messages. She then works on a second feature and commits those changes too. Naturally these are stored as separate pieces of work in the version history. Alice then switches to the version 1.3 branch of the same software to fix a bug that affects only that older version. The purpose of this is to enable Alice’s team to ship a bug fix release, version 1.3.1, before version 2.0 is ready. Alice can then return to the 2.0 branch to continue working on new features for 2.0 and all of this can occur without any network access and is therefore fast and reliable. She could even do it on an airplane. When she is ready to send all of the individually committed changes to the remote repository, Alice can «push» them in one command.

Step 4. Open a Pull Request

Nice edits! Now that you have changes in a branch off of , you can open a pull request.

Pull Requests are the heart of collaboration on GitHub. When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

As soon as you make a commit, you can open a pull request and start a discussion, even before the code is finished.

By using GitHub’s in your pull request message, you can ask for feedback from specific people or teams, whether they’re down the hall or 10 time zones away.

You can even open pull requests in your own repository and merge them yourself. It’s a great way to learn the GitHub flow before working on larger projects.

Open a Pull Request for changes to the README

Click on the image for a larger version

Step	Screenshot
Click the Pull Request tab, then from the Pull Request page, click the green New pull request button.
In the Example Comparisons box, select the branch you made, , to compare with (the original).
Look over your changes in the diffs on the Compare page, make sure they’re what you want to submit.
When you’re satisfied that these are the changes you want to submit, click the big green Create Pull Request button.
Give your pull request a title and write a brief description of your changes.

When you’re done with your message, click Create pull request!

Step 4: Create a commit

It’s time to create your first commit!

Run the command

The message at the end of the commit should be something related to what the commit contains — maybe it’s a new feature, maybe it’s a bug fix, maybe it’s just fixing a typo. Don’t put a message like «asdfadsf» or «foobar». That makes the other people who see your commit sad. Very, very, sad. Commits live forever in a repository (technically you can delete them if you really, really need to but it’s messy), so if you leave a clear explanation of your changes it can be extremely helpful for future programmers (perhaps future you!) who are trying to figure out why some change was made years later.

Step 0: Install git and create a GitHub account

The first two things you’ll want to do are install git and create a free GitHub account.

Follow the instructions here to install git (if it’s not already installed). Note that for this tutorial we will be using git on the command line only. While there are some great git GUIs (graphical user interfaces), I think it’s easier to learn git using git-specific commands first and then to try out a git GUI once you’re more comfortable with the command. A note: 95% of other online git resources and discussions will also be for the command-line interface. 

Once you’ve done that, create a GitHub account here.