Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Сохранение изменений
В Git и других системах управления версиями концепция сохранения проработана более детально, чем в текстовых процессорах или других традиционных приложениях для редактирования файлов. Традиционный термин «сохранение» в программировании синонимичен понятию коммита в Git. Коммит в Git является эквивалентом сохранения. Традиционное сохранение — это операция файловой системы, которая используется для перезаписи существующего файла или записи нового. В отличие от нее, коммит Git выполняется над набором файлов и каталогов.
git add
Порядок действий
Команды git add и git commit составляют основу рабочего процесса Git. Эти две команды должен изучить и понимать каждый пользователь Git, независимо от модели совместной работы, принятой в его команде. Эти команды используются для записи версий проекта в историю репозитория.
Раздел проиндексированных файлов
Вместо того чтобы подтверждать все изменения, внесенные после последнего коммита, вы можете сгруппировать связанные изменения в определенные снимки состояний в разделе проиндексированных файлов, прежде чем выполнять их коммит в историю проекта. Это означает, что вы можете внести различные изменения в несвязанные файлы, а затем вернуться назад и разбить их на логические коммиты (добавляя в раздел проиндексированных файлов связанные изменения и поэтапно выполняя коммиты для отдельных групп изменений). В Git, как и в любой системе контроля версий, важно создавать мелкие коммиты, чтобы можно было легко отслеживать ошибки и отменять изменения с минимальным влиянием на остальной проект.
Распространенные опции
Проиндексировать все изменения в файле file> для следующего коммита.
Проиндексировать все изменения в каталоге directory> для следующего коммита.
Примеры
После того как начнется работа над проектом, можно будет добавить новые файлы, указав путь в команде git add :
Приведенную выше команду можно также использовать для регистрации изменений в существующих файлах. Вспомним, что Git не различает индексацию изменений в новых файлах и в файлах, которые уже добавлены в репозиторий.
Резюме
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Основные команды
Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.
git add
Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. Ниже перечислены наиболее интересные варианты использования этой команды.
Знакомство с этой командой происходит в разделе Отслеживание новых файлов главы 2.
О том как использовать git add для разрешения конфликтов слияния написано в разделе Основные конфликты слияния главы 3.
В разделе Интерактивное индексирование главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.
В разделе Деревья показано как эта команда работает на низком уровне, чтобы вы понимали, что происходит за кулисами.
git status
Команда git status показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
Мы познакомили вас с этой командой в разделе Определение состояния файлов главы 2, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.
git diff
Мы познакомили вас с основами этой команды в разделе Просмотр индексированных и неиндексированных изменений главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.
Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…B в разделе Определение применяемых изменений главы 5.
git difftool
Мы лишь вкратце упомянули о ней в разделе Просмотр индексированных и неиндексированных изменений главы 2.
git commit
В разделе О ветвлении в двух словах главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.
И наконец мы заглянули внутрь команды git commit в разделе Объекты коммитов главы 10 и узнали что она делает за кулисами.
git reset
В разделе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.
git rm
Команда git rm используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
git mv
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
Мы лишь вкратце упомянули эту команду в разделе Перемещение файлов главы 2.
git clean
Команда git clean используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Мы рассмотрели множество опций и сценариев использования этой команды в разделе Очистка рабочего каталога главы 7.
Шпаргалка по Git, в которой представлены основные команды
Шпаргалка по основным командам
git add
Команда git add добавляет содержимое рабочей директории в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
git status
Команда git status показывает состояния файлов в рабочей директории и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
git diff
git difftool
git commit
git reset
git rm
Команда git rm используется в Git для удаления файлов из индекса и рабочей директории. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
git mv
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
git clean
Команда git clean используется для удаления мусора из рабочей директории. Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Шпаргалка по ветвлению и слиянию
git branch
Команда git branch — это своего рода “менеджер веток”. Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
git checkout
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочую директорию.
git merge
Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.
git mergetool
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
git log
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта. По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток. Также её можно использовать для просмотра различий между ветками на уровне коммитов.
git stash
Команда git stash используется для временного сохранения всех незакоммиченных изменений для очистки рабочей директории без необходимости коммитить незавершённую работу в новую ветку.
git tag
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.
Шпаргалка по совместной работе и обновлению проектов
Не так уж много команд в Git требуют сетевого подключения для своей работы, практически все команды оперируют с локальной копией проекта. Когда вы готовы поделиться своими наработками, всего несколько команд помогут вам работать с удалёнными репозиториями.
git fetch
Команда git fetch связывается с удалённым репозиторием и забирает из него все изменения, которых у вас пока нет и сохраняет их локально.
git pull
git push
Команда git push используется для установления связи с удалённым репозиторием, вычисления локальных изменений отсутствующих в нём, и собственно их передачи в вышеупомянутый репозиторий. Этой команде нужно право на запись в репозиторий, поэтому она использует аутентификацию.
git remote
Команда git remote служит для управления списком удалённых репозиториев. Она позволяет сохранять длинные URL репозиториев в виде понятных коротких строк, например «origin», так что вам не придётся забивать голову всякой ерундой и набирать её каждый раз для связи с сервером. Вы можете использовать несколько удалённых репозиториев для работы и git remote поможет добавлять, изменять и удалять их.
git archive
Команда git archive используется для упаковки в архив указанных коммитов или всего репозитория.
git submodule
Шпаргалка по осмотру и сравнению
git show
Команда git show отображает объект в простом и человекопонятном виде. Обычно она используется для просмотра информации о метке или коммите.
git shortlog
git describe
Команда git describe принимает на вход что угодно, что можно трактовать как коммит (ветку, тег) и выводит более-менее человекочитаемую строку, которая не изменится в будущем для данного коммита. Это может быть использовано как более удобная, но по-прежнему уникальная, замена SHA-1.
Шпаргалка по отладке
В Git есть несколько команд, используемых для нахождения проблем в коде. Это команды для поиска места в истории, где проблема впервые проявилась и собственно виновника этой проблемы.
git bisect
Команда git bisect — это чрезвычайно полезная утилита для поиска коммита в котором впервые проявился баг или проблема с помощью автоматического бинарного поиска.
git blame
Команда git blame выводит перед каждой строкой файла SHA-1 коммита, последний раз менявшего эту строку и автора этого коммита. Это помогает в поисках человека, которому нужно задавать вопросы о проблемном куске кода.
git grep
Команда git grep используется для поиска любой строки или регулярного выражения в любом из файлов вашего проекта, даже в более ранних его версиях.
Если вы только начинаете работать с Git, или переходите на Git с другой СКВ, то такая шпаргалка может вам очень пригодиться.
Работаем с Git, основные команды для начинающих
Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:
После инициализации каталога будет выведено соответствующее сообщение:
$ git add
Для этого понадобится выполнить команду:
$ git status
Чтобы зарегистрировать добавление вышеприведенных файлов необходимо выполнить следующую команду:
–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.
Подтверждение с описанием выполненных действий.
Мы сделали «снимок кода». Теперь мы можем редактировать файлы и регистрировать наши изменения.
$ git stash
$ git stash list
Чтобы просмотреть все сохраненные, но не зарегистрированные изменения понадобится следующая команда:
На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.
$ git stash pop
Восстановить же изменения поможет следующая команда:
$ git merge
Ветвление
Ветка позволяет отделить работу, например, над каким-то компонентом от основного кода сайта.
$ git checkout –b
Чтобы создать новую ветку выполните команду:
git init (инициализируем git реп-й)
Чтобы проинициализировать Git репозиторий введите команду:
git status (Проверяем статус)
Комнада, выводяюща статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (добавляем файл)
Чтобы сообщить Git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью:
Сейчас git отслеживает наш файл test.txt. Давайте выполним
снова, чтобы понять, что изменилось!
git commit (фиксируем изменения)
Чтобы сохранить изменения на данном этапе мы выполним команду создания коммита и передадим ей в качестве аргумента сообщение, описывающие изменения, сделанные в этом коммите.
Используем маску
К счастью, у нас есть возможность добавить все файлы, используя шаблон. Не забывайте про кавычки!
git commit –a –m ”new comment here”
Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).
Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,
—amend
Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,
Второй коммит заменит результат первого и в итоге останется 1 коммит
Работаем с GitHub
Зарегистрируйтесь на GitHub. Создайте репозиторий.
Чтобы разместить наш локальный репозиторий на GitHub, мы должны добавить удаленный репозиторий.
Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git
Выполняем команду с указанными аргументами:
git remote add origin https://github.com/try-git/try_git.git
Плюсы и минусы bitbucket.org и GitHub
На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.
Процесс разработки:
Эта команда показывает имя удаленного репо, если такой имеется в наличии.
Ключ –v показывает путь к удаленному репо.
Подробно о любой команде можно узнать:
Коммитим и пушим на GitHub (global настройки matching и simple)
Если мы выполнима для настройки глобального конфига следующую команду:
То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.
В данном случае протолкнется лишь текущая ветка.
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп.)
Добавление удаленных репозиториев под короким именем:
git remote add [сокращенное имя] [url]
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master
Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku
git remote show (получаем инфо. об уд. реп.)
Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.
git fetch (извлечение данных из уд. реп.)
Извлечение данных из уд. реп. выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта
git push (проталкиваем изменения)
где origin – это куда отправляем (удаленный репозитарий), а
master это то, что отправляем (в нашем случае master ).
git pull (стягиваем изменения)
Давайте представим, что прошло какое-то время. Мы пригласили других людей в наш проект, они забрали наши изменения в свои локальные репозитории и внесли свои изменения, запушили их. Мы можем проверить изменения на GitHub и спуллить их с помощью команды:
git pull origin master
Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.
git diff, git diff HEAD
Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.
Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды
git reset (Откатываем изменения/удаляем файлы из промежуточной области)
git reset octofamily/octodog.txt
git log (информация о последних коммитах)
Иногда просто хочется вернуться назад и забыть все изменения до определенного момента, потому что все они были неправильными. В таком случае Для просмотра изменений (истории коммитов) используется команда
покажет список последних коммитов и их хеши SHA1.
На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:
Например, мы можем выводить историю в более удобном формате:
Ограничиваем коммиты по времени:
—stat используется для получения краткой статистики по каждому коммиту.
—graph добавляет графику с историей ветвлений и слияний
git checkout (Отмена изменений)
Файла был удален из промежуточной области. Но сам файл все еще находится в проекте! Файлы могут быть возвращены в состояние последнего коммита с помощью команды:
Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.
git checkout (получаем уд. ветку)
Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :
(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.
git branch (создаем ветку)
Когда разработчики работают над новой фичей или багом, они обычно создают копию (или ветку) кода проекта, в которую они могут коммитить независимо. Когда разработка завершена, изменения из этой копии (ветки) нужно влить (вмержить) обратно в основную ветку проекта.
Давайте создадим новую ветку и назовем ее clean_up :
git branch clean_up
Данная команда не обращается к серверу, а а берет локальные данные из кэша.
Для получений актуальной информации как на удаленном так и на локальном серверах можно использовать команду:
git rm (удаляем файлы)
merge (смержим в текущую ветку другую)
git merge clean_up
git clone
$ mkdir epicgame & cd epicgame
$ git init
$ git remote add
$ git clone
rejected
Конфликты
Сообщение о конфликте:
В статусе ( git st ) появляется блок:
То есть в самом файле:
Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).
Разные полезные команды:
Добавляем пользователя:
(задаем email глобально)
(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )
Игнорирование файлов:
В самом файле указываем игнорирование, например:
$ git rm
СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ
Без ключа –m откроется редактор vim ( 😡 – означает сохранить и выйти).
Поменяем редактрор по умолчанию (vim), он будет открываться в том случае, если мы не прописываем комментарий в командной строке.
Изменения можно проверить в C:\Users\name_user\.gitconfig
ВЕТКИ ($ git checkout –b new_branch)
Создаем ветку new_f и тут же переходим в нее.
С использованием –v показывает ветки с последними коммитами.
merge
Указываем какой утилитой будем разрешать конфликты
Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):
