Руководство Кевина по Git

Обновленную версию этого руководства можно найти в текстовой версии на Github. Мне проще отправлять обновления на: https://github.com/KevinVerre/kevins-guide-to-git.

Оглавление:

Тема 0. Введение в Git и это руководство.
Тема 1. Что такое Git.
Тема 2. Разница между Git и Github
Тема 3. Введение в ветки и коммиты
Тема 4. Создание коммитов
Тема 5. Типичный пример рабочего процесса
Тема 6. Разрешение конфликтов
Тема 7. Перебазирование и изменение
Тема 8. Другое программное обеспечение, построенное на базе Git< br /> Тема 9. Псевдонимы и автозаполнение

Тема A: Команды, которые вы должны знать.

Тема Б: Другие ресурсы

## Тема 0. Введение в Git и это руководство.

Git — это название программы «Контроля версий» (или «Контроля версий»), которую многие программисты используют для написания программного обеспечения. Программное обеспечение для контроля версий помогает программистам писать программное обеспечение, позволяя программам одновременно сохранять несколько версий своих проектов, а затем объединять эти версии позже. Это также помогает командам программистов работать вместе при написании части программного обеспечения.

Программисты, являющиеся экспертами по Git, могут использовать Git для более быстрого и легкого написания кода. К сожалению, научиться использовать Git очень сложно и пугающе. Цель этого руководства — помочь людям лучше использовать git. Будет полезно как новичкам, так и опытным пользователям. Поскольку git очень сложен в использовании, многим опытным пользователям git еще предстоит многому научиться.

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

Но как только вы прочитаете мое руководство и поймете основные концепции Git, вы будете готовы приступить к его освоению. На этом этапе вы получите гораздо больше от учебных пособий и ссылок, созданных другими.

Это руководство хранится в общедоступном репозитории Github. Вы можете прочитать это руководство онлайн там. Вы также можете увидеть, как он менялся с течением времени, используя историю совершенных изменений. https://github.com/KevinVerre/kevins-guide-to-git

Ближе к концу этого руководства находится раздел «Команды, которые вы должны знать». Не стесняйтесь переходить к этому разделу, если вы уже много знаете о git и просто хотите научиться новым приемам.

## Тема 1. Что такое Git.

Представьте, что вы создаете программный проект. Это может быть программное приложение, веб-сайт, мобильное приложение, скрипт или что-то еще. У вас есть папка, содержащая все файлы, относящиеся к этому проекту: файлы кода, файлы изображений, подпапки, возможно, некоторые файлы данных и т. д. Git — это инструмент, позволяющий сохранять разные версии этой папки. Затем вы можете вернуться к более старым версиям, если это необходимо. Вы также можете работать с несколькими разными версиями (называемыми ветвями) одновременно и объединять их позже. Изменения между двумя версиями хранятся в виде списка зафиксированных изменений, называемых «фиксацией».

Git — это часть программного обеспечения. Чтобы использовать git, он должен быть установлен на вашем компьютере. Компьютеры с установленным Git могут взаимодействовать и отправлять команды другим компьютерам с установленным Git. Конечно, другой компьютер, с которым вы взаимодействуете, должен знать, что он может вам доверять, поэтому обычно ему требуется пароль или секретный ключ. Однако вы также можете использовать git только на одном компьютере. Git — это программа только для командной строки, что означает, что вы используете ее, вводя команды в терминал или командную строку, а не используя графический интерфейс пользователя. Однако есть и другие программы, позволяющие использовать Git с графическим пользовательским интерфейсом. Существуют даже веб-сайты, позволяющие использовать git, например GitHub и BitBucket.

Git был создан Линусом Торвальдсом, известным программистом из Финляндии (но сейчас живущим в США). Торвальдс прославился написанием и управлением ядром Linux, открытым исходным кодом, на котором работают операционные системы Linux. Git был создан Торвальдсом для помощи в дальнейшей разработке ядра Linux. Название «мерзавец» происходит от британского английского языка, где оно используется как оскорбительное сленговое слово. Если вы называете кого-то придурком, вы называете его идиотом, надоедливым или неприятным. Официальная документация к программному обеспечению git в шутку и смирении называет git «git — тупым трекером контента». Программное обеспечение Git было написано на языке программирования C. Это открытый исходный код, и вы можете посмотреть код C, из которого сделан Git.

После установки git на ваш компьютер вы можете использовать его для создания проектов git, называемых репозиториями. Репозиторий в информатике — это место, где хранятся код и данные. Репозиторий git — это просто папка («каталог») на вашем компьютере. Мы будем называть это папкой проекта или папкой репозитория. Внутри этой папки находятся все файлы и подпапки вашего проекта.

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

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

Папка репозитория содержит подкаталог .git, но также будет содержать дерево других подпапок и файлов. Любая папка или файл внутри репозитория считается частью репозитория git. Однако специальная подпапка .git появляется только в одном месте: внутри папки репозитория верхнего уровня. Это означает, что другие подпапки в репозитории не содержат специальной подпапки .git.

У вас может быть несколько разных проектов/репозиториев git на вашем компьютере одновременно. Поэтому, когда вы выполняете команду git, программе git необходимо знать, для какого проекта git вы пытаетесь выполнить команду. Он будет использовать ваше текущее местоположение в структуре каталогов (ваш текущий рабочий каталог или «pwd»), чтобы узнать, над каким репозиторием git вы работаете. Когда вы запускаете команду из репозитория git, команда будет выполняться в репозитории git, в котором вы сейчас находитесь. Он определяет, в каком репозитории вы находитесь, ища специальную папку .git. Он находит папку .git, ища ее в вашем текущем каталоге, а если ее там нет, ищет ее в каждом из родительских каталогов вашего текущего каталога. Он использует информацию, хранящуюся в папке .git, при выполнении команд.

Если вы попытаетесь запустить команду git, не находясь где-то внутри репозитория git, вы увидите следующее сообщение об ошибке:
«фатальная ошибка: не репозиторий git (или какой-либо из родительских каталогов): .git»
Это означает, что в зависимости от папки, в которой вы запустили команду, ей не удалось найти папку .git в текущей папке или какой-либо из родительских папок, поэтому вы не находитесь в репозитории git.

Чтобы создать репозиторий git, вы используете команду «git init» вместе с именем, которое вы хотите дать своему проекту. Таким образом, «git init super_marlin_bros» скажет git создать новый подкаталог с именем «super_marlin_bros» внутри любого каталога, в котором вы сейчас находитесь. Этот новый каталог «super_marlin_bros» является вашей папкой репозитория. И как часть процесса инициализации программа git создаст папку .git внутри папки вашего репозитория. Вы также можете использовать «git init», чтобы инициализировать репозиторий git на основе существующей папки, а не создавать новую папку. В этом случае просто укажите имя или путь к папке, которую вы хотите превратить в папку репозитория git, и «git init» создаст внутри нее подпапку .git.

Другой способ создать папку репозитория git на вашем компьютере — «клонировать» репозиторий git, который уже существует где-то еще. Это очень распространенный способ создания проекта git. И мы поговорим об этом позже.

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

На практике редко когда репозитории двух членов команды взаимодействуют напрямую. Вместо этого обычно создается дополнительный репозиторий где-то, к которому могут получить доступ все члены команды. Обычно его называют «исходным» репозиторием. Он существует на компьютере, с которым у всех членов команды есть разрешение на взаимодействие. И обычно он размещается на серверном компьютере, который постоянно включен, чтобы в любой момент член команды мог отправить свою работу в исходный репозиторий. И в любое время другие члены команды могут перенести эти изменения из исходного репозитория в свой собственный репозиторий. Репозиторий, с которым вы работаете на своем компьютере, называется «локальным» репозиторием. Исходный репозиторий и папки репозитория, принадлежащие другим членам команды, с вашей точки зрения являются «удаленными» репозиториями, потому что они (почти всегда) не существуют на том же компьютере, что и ваш.

Программа git может использовать специальную папку .git для хранения информации не только о вашем локальном репозитории, но и о файлах и папках в удаленных репозиториях, на просмотр которых у вас есть разрешение. На практике обычно есть только один удаленный репозиторий, который вас интересует («происхождение»), но теоретически вы можете иметь информацию о любом количестве удаленных репозиториев, хранящихся в вашей подпапке .git. Процесс загрузки обновлений из удаленного репозитория и сохранения содержимого этих обновлений в вашей подпапке .git называется выборкой. Если вы извлекаете удаленный репозиторий, вы можете увидеть код, который был в этом удаленном репозитории в то время, когда вы его извлекали, даже если вы не подключены к Интернету или к этому удаленному репозиторию!

Git иногда называют «распределенной системой контроля версий». Git «децентрализован», потому что программное обеспечение git написано таким образом, что все репозитории git для конкретного проекта являются одноранговыми (равными). Например, предположим, что у нас есть три репозитория git для одного и того же проекта. Один на моем компьютере, один на вашем компьютере и один на сервере, на который мы оба можем отправлять изменения через Git. На всех трех этих компьютерах установлено одно и то же программное обеспечение git. Несмотря на то, что мы решили рассматривать один из этих репозиториев (тот, что на сервере) как особый, в том, как настроено его программное обеспечение git или вложенная папка .git, нет ничего, что отличалось бы от других репозиториев.

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

## Тема 2. Разница между Git и Github

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

Github — это веб-сайт (и компания, стоящая за веб-сайтом). Вы можете думать о Github как о программе, работающей поверх Git, которая добавляет дополнительные функции. Поскольку на серверах Github работает Git, вы можете обмениваться своим кодом между своим компьютером и серверами Github. Есть несколько причин, по которым вы можете захотеть это сделать. Во-первых, хранить ваш код на их серверах удобно. Их серверы всегда работают и безопасны, потому что ваши данные защищены вашими именами пользователей и паролями. Таким образом, любой член вашей команды всегда может получить доступ к репозиторию, хранящемуся на Github, через Интернет. Хотя Git не требует «центрального» репозитория, команды используют Github в качестве центрального репозитория для удобства. Когда они хотят поделиться новым кодом, который они написали, они отправляются на Github. И когда вы хотите увидеть новый код, написанный кем-то другим, вы загружаете его из Github, а не напрямую с компьютера вашего товарища по команде.

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

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

На веб-сайте Github есть множество инструментов, облегчающих использование Git. Вы можете использовать пользовательский интерфейс в своем браузере, а не командную строку.

## Тема 3. Введение в ветки и коммиты

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

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

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

Последняя фиксация в текущей ветке называется HEAD. Коммиты перед ним: HEAD~1, HEAD~2, HEAD~3 и т. д.

Коммит — это набор изменений в репозиторий. А ветка — это набор коммитов, который является результатом применения всех коммитов один за другим. Их называют ветвями, потому что они образуют древовидную структуру. Обычно вторичная ветвь коммитов ответвляется от другой, более первичной ветки. Затем, если вы позже захотите, чтобы эта вторичная ветвь снова была включена в основную ветвь, вы можете объединить ее с основной ветвью.

Что содержит коммит? Коммит содержит следующие поля: хэш фиксации (который используется в качестве строки идентификатора), строку сообщения фиксации, изменения (для всех соответствующих файлов и папок), строку имени автора, дату и время. Вы идентифицируете коммит по его хэшу коммита. Но вам не обязательно использовать все это: если вы получите первые несколько символов, Git попытается выяснить, на какой коммит вы ссылаетесь. Этот хеш получается из хеш-функции, которая принимает все данные, связанные с фиксацией (включая сообщение фиксации). Что вы не можете «отредактировать» коммит, а вместо этого должны заменить его новым коммитом с новым хэшем.

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

## Тема 4. Создание коммитов

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

Команда «git status» покажет вам статус всех изменений, внесенных в репозиторий с момента последней фиксации. Он покажет вам, были ли файлы добавлены, удалены или изменены. Команда «git diff» покажет вам, как изменились файлы. Команда «git diff — staged» покажет изменения в репозитории, которые находятся в стадии подготовки. По умолчанию «git diff» покажет вам различия для всего репозитория. Вы также можете показать изменения в конкретном файле, используя «git diff FILENAME». Репозиторий, над которым вы работаете, иногда называют «рабочим каталогом», а внесенные вами изменения — это изменения в «рабочем дереве». Другое название этапа – «индекс».

Следующим шагом является «постановка» изменений путем добавления их на «стадию». Если вы добавили новый файл или внесли изменения в файл, вы можете указать эту разницу с помощью команды «git add FILENAME». Если вы удалили файл, вы можете перенести эту разницу в репозиторий с помощью команды «git rm FILENAME». Конечно, подготовка каждого файла по отдельности может стать утомительной, поэтому вам не нужно делать это таким образом. Вы можете внести все изменения в папку (включая изменения папок внутри этой папки), используя «git add DIRECTORY». И, конечно же, точка означает текущий каталог, в котором вы находитесь, поэтому обычно делается «git add .». Иногда вы можете захотеть дать этой команде аргумент. По умолчанию «git add DIRECTORY/FILENAME» будет размещать новые файлы и изменения в файлах, но не будет указывать, что файл был удален. Таким образом, аргумент -A указывает ему выполнять все изменения, включая удаление файлов. Итак, если вы находитесь в корневом каталоге, команда «git add -A» добавит все изменения, внесенные вами в ваше рабочее дерево, на сцену.

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

Иногда вы можете обнаружить, что есть некоторые изменения в файле, который вы хотите разместить, и другие изменения в файле, которые вы не хотите размещать, потому что не хотите сохранять эти изменения. Использование «git add -p» позволит вам просмотреть различия в этом файле и выбрать, какие небольшие изменения (так называемые «фрагменты») вы хотите добавить, а какие нет.

Иногда вам может понадобиться удалить изменение со сцены. Как подскажет вам «git status», вы можете использовать «git reset HEAD ‹filename›», чтобы удалить изменения этого файла из промежуточной среды, но сохранить изменения в рабочем дереве. Я не уверен, почему команда «git reset HEAD», потому что она не отменяет ваши изменения, которые вы сделали в HEAD, а просто удаляет их.

Вы также можете отменить изменение, если решите, что оно вам не нужно.

Концепция: Gitignore
Иногда вам нужно, чтобы файлы находились в папке репозитория без «отслеживания» этих файлов как части репозитория. Поэтому вам нужен способ сообщить git, какие файлы в папке вашего репозитория не следует отслеживать. Вы делаете это, создавая файлы .gitignore внутри своего репозитория.
Файлы, которые игнорируются, не будут отображаться как неотслеживаемые в статусе git. И они не будут добавлены в тестовую область при использовании git add.

## Тема 5. Типичный пример рабочего процесса

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

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

Поскольку вы хотите хранить свою работу в облаке, вы найдете экземпляр Git-сервера, работающего в Интернете. Большинство людей используют Github или Bitbucket или что-то в этом роде, бесплатную или платную версию. Но вы также можете запустить свой собственный сервер Git, если хотите. Если у вас настроены учетные данные, вы можете отправить копию своего репозитория Git в облако. Это будет вашим исходным репозиторием. Вы можете настроить свой локальный мастер так, чтобы он указывал на основную ветку источника как на восходящую ветку. Это позволяет вам отслеживать, сколько коммитов вы опережаете или отстаете от этой ветки.

Ваша коллега Бетти может клонировать репозиторий из облака на свой локальный компьютер. Если она хочет, она может отправить новые коммиты или новые ветки в источник. Чтобы доказать, что она та, за кого себя выдает, ей, возможно, придется создать ssh-ключ из пароля.

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

Прежде чем вы это сделаете, вам нужно убедиться, что ваша ветка master обновлена. Таким образом, вы проверяете master и перетаскиваете любые коммиты из origin/master в local/master. Из master вы создаете новую ветку и называете ее «new-video-player». (Или то, что описывает функцию, над которой вы работаете.) Вы создаете несколько коммитов в этой ветке, пока она не будет работать так, как вам нужно.

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

Когда вы будете готовы поделиться тем, что вы создали, со своим коллегой, вы отправляете свою новую ветку в источник как удаленную копию этой новой ветки. Теперь ваша коллега Бетти может скопировать ветку функций из origin/new-video-player в свой локальный репозиторий и проверить ее. Она тестирует созданную вами новую функцию и просматривает ваш код.

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

## Тема 6. Разрешение конфликтов

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

В одной ветке последовательных коммитов не может возникнуть конфликт. Одна фиксация может изменить строку. Тогда следующая фиксация может изменить ту же строку. Но он всегда будет знать порядок. Оба варианта «до» и «после» этой строки были бы уместны.

Но когда коммиты из одной ветки объединяются в другую ветку, возможно, изменения в коммитах конфликтуют. Представьте, что строка кода является исходной версией A. В одной ветви B эта строка кода изменена с версии A на версию B. Но в другой ветви C эта строка изменена с версии A на версию C. Если вы просто попробуете применить изменение C после изменения B, это приведет к конфликту, поскольку изменение C предполагает версию A в качестве отправной точки, а не версию B.

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

## Тема 7. Перебазирование и изменение

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

Rebase позволяет вам взять один или несколько коммитов и повторно применить их (с новыми изменениями) к текущей ветке. Например, вы можете использовать rebase для изменения порядка коммитов в ветке. Или вы можете разделить один коммит на два коммита. Или объединить два коммита в один коммит. Или вы можете удалить коммит из ветки. Или вы можете редактировать сообщения фиксации.

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

Я использую интерактивный режим (git rebase -i) при перемещении. Это вызывает небольшой текстовый файл, который вы редактируете в Vim. Этот файл действует как инструкция для перебазирования. Когда вы сохраняете и выходите, перебазирование выполняется с использованием этих инструкций.

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

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

Вы можете прочитать больше о rebase в документации Git «git rebase — help».

«git commit — amend» — удобная команда, которую нужно знать. По сути, это очень маленькая, быстрая и простая перебазировка. Он изменяет только самую последнюю фиксацию в текущей ветке (HEAD). Это позволяет вам изменить сообщение коммита для этого коммита. Кроме того, любые изменения, которые в настоящее время находятся в стадии подготовки при выполнении этой команды, будут включены как часть этой фиксации. Конечно, за кулисами это фактически удаляет коммит и создает новый, чтобы заменить его, с новым хэш-идентификатором и всем остальным. Это позволяет вам быстро и легко добавить что-то, что вы забыли написать или добавить в только что созданный коммит.

## Тема 8. Другое программное обеспечение, созданное поверх Git.

Наиболее распространенное программное обеспечение, созданное поверх Git, — это программы, которые позволяют использовать Git с графическим интерфейсом вместо командной строки.

Некоторые текстовые редакторы и IDE поставляются со встроенными функциями Git. Например, Xcode от Apple.

«Gitless» — это интерфейс командной строки, построенный поверх git, который разработан так, чтобы его было проще освоить, чем Git.

Другие программы построены поверх Git и творчески используют возможности git для синхронизации разных версий файлов. Например, менеджер пакетов Ruby on Rail «RubyGems» использует репозитории Git для хранения кода и обмена им.

## Тема 9. Псевдонимы и табуляция

Как только вы освоите Git, вы захотите научиться использовать его быстрее. Есть два отличных способа сделать это: псевдонимы и автозаполнение.

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

Первый находится в глобальном конфигурационном файле git для вашего имени пользователя. Отредактируйте файл .gitconfig вашего пользователя, чтобы управлять конфигурацией git. По умолчанию это файл, хранящийся в ~/.gitconfig. Вы назначаете раздел псевдонимов файла конфигурации с помощью [псевдоним]. Вот некоторые из тех, что есть у меня:

[alias]
co = checkout
ci = commit
amend = commit — amend
s = status
st = status
sh = show
b = ветвь
br = ветвь
p = pull
d = diff
l = log
a = add

Вы также можете создать псевдонимы для своего терминала, такие как ваш ~/.bashprofile. Пример: псевдоним gs='git status'

В Git также есть инструмент автозаполнения вкладок. После того, как инструмент автозаполнения вкладок установлен, вам просто нужно начать вводить название ветки (или другой идентификатор), нажать вкладку, и он попытается ввести полное имя. Однако он не встроен в Git. Вы должны скачать код и установить его. Я бы назвал его полуофициальным, поскольку он доступен в том же репозитории, что и официальный исходный код git. Но это не часть их основного проекта. Вы можете скачать версию для bash отсюда, а затем добавить ее в свой bash_profile:

https://github.com/git/git/tree/master/contrib/completion

## Тема A. Команды, которые следует знать.

git «команда» — help
Git покажет вам страницу справки для команды, если вы добавите — help
git diff
Покажет вам изменения в файлах в репозитории, которые не были добавлены в тестовую область.
git diff — staged, git diff — cached
— staged и — cached делают одно и то же. Оба показывают, какие изменения в вашем репозитории были добавлены в тестовую область. Это означает, что эти изменения были выбраны для следующего коммита.

git checkout -
Аргумент dash извлекает предыдущую ветку, в которой вы находились до текущей ветки. (Подобно тому, как `cd -` изменяет ваш каталог на предыдущий, в котором вы были.)

git init «имя_папки»
создать новый каталог с именем «имя_папки». Затем создайте новый репозиторий git в этом каталоге.
git init ./
инициализируйте новый репозиторий git в текущем каталоге
git status
Показывает текущий статус. Включает в себя ветку, в которой вы находитесь. Какие изменения были внесены в файлы, и являются ли эти непроиндексированные изменения или изменения, которые уже проиндексированы. Также показывает, находится ли ваша текущая ветка позади своей восходящей ветки.
ветка git
ветка git -r
ветка git -v
Показывает более подробную информацию о ветках, например, какая последняя фиксация в каждой ветке
git - vv
Показывает ЕЩЕ БОЛЬШЕ подробной информации о ветках, включая восходящую ветку для каждой ветки, у которой есть одна
git show
То же, что и «git show HEAD»
git show HEAD< br /> Показывает содержимое коммита HEAD (последний коммит в текущей ветке)
git show «commit-hash»
Показывает содержимое конкретного коммита.
git log — график
Распечатывает график, чтобы вы могли увидеть, как были объединены ветки
git log -n 3
Используйте -nx, чтобы показать только информацию о X последних коммитах
git log — oneline< br /> Используйте аргумент — oneline, чтобы распечатать только одну строку для каждого коммита git
git log — reverse
Этот флаг показывает, что коммиты начинаются от самого старого к самому новому, а не от самого нового к более старому.
git fetch
Ваш локальный репозиторий хранит информацию о том, что ему известно насчет удаленного репозитория. Вызов git fetch указывает git связаться с удаленным репозиторием и обновить то, что знает о нем ваш локальный репозиторий.

git fetch -p
По умолчанию git fetch будет обновлять то, что ваш локальный репозиторий знает об удаленном репозитории. Он будет загружать новые коммиты и ветки. Но если в удаленном репозитории будет удалена ветка, ваше локальное хранилище не удалит соответствующую локально-удаленную ветку. Однако, если вы используете -p для обрезки, он удалит все локально-удаленные ветки, у которых больше нет соответствующей ветки в удаленном репозитории.

git merge “other_branch”
Это объединит “other_branch” с вашей текущей веткой. Если слияние не является быстрым слиянием, это создаст «фиксацию слияния».

git pull
Это делает две вещи. Во-первых, он выполняет git fetch. Это означает, что в вашем локальном репозитории все обновления из удаленного репозитория будут храниться в виде удаленных веток. Кроме того, если вы находитесь в ветке с вышестоящей удаленной веткой, она объединит эту вышестоящую удаленную ветку (которая теперь является локально-удаленной веткой из-за Fetch) с вашей текущей веткой.

git add -p ИМЯ ФАЙЛА
Вы когда-нибудь хотели инсценировать некоторые изменения в файле, но не все изменения в этом файле? Вы можете сделать это с помощью аргумента — patch, или для краткости -p. Git проверит все изменения в файле. Чтобы сделать это быстро, он делает это в виде «кусков» строк, а не отдельных строк. Кусок — это группа строк, расположенных рядом друг с другом. Для каждого фрагмента вы можете указать Git, хотите ли вы его подготовить или перейти к следующему фрагменту. Вы даже можете сказать, что хотите разбить фрагмент на отдельные строки, если хотите получить действительно конкретную информацию о том, что вы добавляете в область подготовки.

Когда это будет сделано, попробуйте запустить команду `git status`. Вы увидите имя файла как в списке файлов с поэтапными изменениями, так и в списке файлов с неустановленными изменениями.

git commit — amend
Это вносит изменения в последний коммит в вашей текущей ветке (HEAD). Это позволяет вам делать две вещи. Во-первых, он позволяет вам изменить сообщение фиксации вашего последнего коммита (HEAD). Он также будет сочетать ваши поэтапные изменения с HEAD. Я использую это, если создаю фиксацию, но затем понимаю, что есть еще одно изменение, которое я хочу внести в файлы и добавить к этой фиксации. Так что это очень удобный способ изменить содержимое вашего последнего коммита.

Обратите внимание, что это фактически удаляет вашу фиксацию HEAD и создает новую фиксацию (с новым хэшем фиксации), чтобы заменить ее. Это своего рода «перебазирование».

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

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

git clean
Используется для очистки (удаления) неотслеживаемых файлов в вашем репозитории. Поскольку эта команда удаляет файлы с вашего компьютера, ей требуется дополнительный аргумент (-f), чтобы заставить ее что-либо сделать
git clean — dry-run
Аргумент — dry-run выводит, какие файлы будут удалены. удаляется без фактического удаления каких-либо файлов
git clean -f
Аргумент -f (или — force) говорит git, что вы серьезно относитесь к удалению этих файлов
git clean -d
Удаляет неотслеживаемые каталоги, а также файлы

git обвинять «имя файла»
Показать, какой коммит (и какой автор коммита) отвечает за каждую строку файла.

git reset
Я использую это, чтобы избавиться от коммитов

git checkout ‹commit› ‹file›
Я использую это, чтобы вернуться к определенной версии файла. Он перенесет различия для этого файла с ‹HEAD› на ‹commit›. Так что, если вы совершили коммит, у вас была бы старая версия файла.

git bisect
Это инструмент (поставляется с git), который вы можете использовать, чтобы определить, когда в вашем коде появилась ошибка. Что он делает, так это помогает вам проверять старые версии коммитов вашего кода. Для каждого коммита вы вручную проверяете ошибку, а затем сообщаете командной строке, была ли ошибка. Если у вас есть сценарий или команда, которую вы можете запустить для проверки наличия ошибки, вы можете настроить инструмент bisect для запуска этой команды при каждом делении пополам.

Не всем понадобится `git bisect`, но приятно знать, что он есть, если он вам когда-нибудь понадобится для гигантского проекта.

git rebase -i ‹commit/branch›
git rebase -i HEAD~3
Запускает процедуру перебазирования в интерактивном режиме. Интерактивный режим позволяет вам видеть, какие коммиты будут повторно применены, и вносить любые изменения, прежде чем они будут повторно применены. В примере HEAD~3 я перебазирую последние три коммита моей текущей ветки. Предпоследний коммит (3 коммита перед HEAD) действует как конец ветки, и я перемещаю все коммиты, которые идут после HEAD~3, поверх HEAD~3.

git remote prune origin
Когда вы получаете список удаленных ветвей из удаленного репозитория (обычно из источника), он записывает список этих удаленных ветвей. Он сохраняет ветки в этом списке ссылок ДАЖЕ ПОСЛЕ того, как ветка была удалена в удаленном репо. Если вы используете `git branch -r` для отображения удаленных ветвей, эти удаленные ветки все равно будут отображаться в списке имен ветвей. Чтобы удалить их из этого списка, используйте `git remote prune ‹origin или другое имя удаленного репо›`

## Тема B. Другие ресурсы.

Вы можете найти сборники советов и рекомендаций по Git в Интернете, например, этот список в репозитории Github: https://github.com/git-tips/tips.

У компании Atlassian, которая производит инструменты для разработчиков программного обеспечения, есть отличные образовательные веб-страницы о Git. Вы можете читать эти веб-страницы бесплатно. Atlassian теперь является материнской компанией BitBucket, продукта, конкурирующего с GitHub.

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

На официальном сайте Git есть бесплатная книга, в которой описаны все возможности Git. Он называется Pro Git: https://git-scm.com/book.