Git не отслеживать права на файлы
Обновлено: 06.07.2024
В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:
Если существует более одного накопления, найти нужное можно с помощью команды:
git stash list затем можно применить его, воспользовавшись его индексом:
Необходимо учитывать, что отсчёт индексов ведётся от нуля.
Восстановление удалённого тега
В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:
После того, как нужный тег найден, его следует восстановить:
Восстановление удалённого файла
Если вы случайно удалили файл, его можно быстро восстановить:
Если требуется восстановить файл из конкретной временной точки истории коммитов, следует узнать хеш нужного коммита и запустить команду:
Восстановление удалённой ветки
С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:
После этого восстановить удалённую ветку можно будет вот такой командой:
Предупреждение: подобная насильная перезапись может привести к потери коммитов из внешней ветки, если с ней давно не было синхронизации, соблюдайте осторожность.
Использование алиасов команд в командной строке
Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.
— теперь нужно писать только git st
Можно пойти дальше и присвоить алиасы более сложным командам:
Теперь алиас git logme будет выводить все наши коммиты.
Коммит в неправильную ветку
Нужно переключиться на новую ветку, которую вы забыли предварительно создать:
А затем переключиться к оригинальной ветке:
. и «откатиться» до последнего коммита, который нужно сохранить.
Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.
Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!
Обновление конкретного подмодуля
Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:
Откат к конкретному коммиту в истории
Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:
Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.
Отмена коммита до публикации изменений
Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.
Будьте осторожны используя второй вариант, поскольку изменения ваших локальных файлов будут потеряны.
Отмена коммита после отправки его в master-репозиторий
Рассмотрим процедуру возврата одного или нескольких коммитов, которые нужно стереть из удалённой ветки. Обозначить конкретный коммит можно с помощью его хеша:
Отмена только коммита, который является вторым после последнего:
Простая отмена последнего коммита:
Отмена локальных изменений файлов
Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:
Кроме того, можно восстановить конкретный путь к файлу:
Отображение всех коммитов одного файла
Если вы хотите просмотреть все коммиты с изменениями конкретного файла, воспользуйтесь командой git log --follow -p -- myfile
Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.
Отображения числа коммитов от каждого участника
Хотите узнать, сколько коммитов сделал каждый участник команды?
Эта команда выведет список, отсортированный в порядке убывания количества коммитов: git shortlog -s -n
Отобразить коммиты, содержащие удалённые файлы
Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:
Она покажет список коммитов, в которых удалялись файлы.
Отсортировать коммиты по автору
Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:
Очистка всех скрытых состояний
Очистить все скрытые состояния можно следующей командой:
Переименование локальной и удалённой ветки
Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:
А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25
А теперь заново публикуем её с новым именем: git push origin hotfix-users
Переименование тега
Чтобы переименовать существующий тег:
Перестать отслеживать существующие файлы
Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:
Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:
Подготовка удалённых файлов
Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:
Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой
Пометить конфликтующий файл, как разрешённый
Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:
Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.
Просмотр всех неотправленных коммитов
Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:
Кроме того, можно использовать:
Просмотр старой ревизии файла
Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:
Публикация локальной ветки для удалённого редактирования
Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:
Теперь они тоже смогут вносить изменения в эту ветку.
Сброс локальной ветки до состояния удалённой
В том случае, если отсутствуют изменения, которые необходимо сохранить, сбросить локальную ветку до состояния удалённой можно с помощью двух простых команд.
Прежде всего нужно получить свежие обновления из удалённой ветки:
А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:
При наличии коммита, который нужно сохранить, перед сбросом нужно создать новую ветку и произвести коммит: git commit -m «Обновление»
Синхронизировать ветку с master-репозиторием
Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:
А затем осуществляете «перебазирование»:
После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.
Слияние локальных изменений с другой веткой
Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.
Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:
Совмещение двух и более коммитов
Здесь нам понадобится произвести интерактивное перебазирование. Если перебазирование происходит относительно master-ветки, то начать следует с команды git rebase -i master. Однако, если перебазирование происходит не относительно ветки, то нужно будет перебазироваться относительно HEAD.
Если есть необходимость в совмещении двух последних коммитов, можно использовать команду
После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь
Совмещение коммитов по конкретной функции для добавления в ветку релиза
Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.
Ниже представлен пример того, как достичь подобного эффекта:
В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.
Создание новой ветки с изменениями текущей
Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».
Убрать файл из буфера
Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:
Удаление внешней ветки
Если вы хотите удалить ветку, введите команду:
Удаление неотслеживаемых файлов и папок
Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:
Чтобы в принципе удалить их:
Подсказка: чтобы увидеть, какие файлы являются лишними, перед их непосредственным удалением, наберите:
Удаление старых веток, стёртых из внешнего репозитория
Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды
Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.
Удаление файла из git с сохранением его локальной копии
Для того, чтобы удалить файл из git, но сохранить его локально нужно использовать следующую команду:
Без Гита и жизнь не та
Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.
Если вы хотите получше узнать те части Git, про которые раньше боялись спросить, то этот список для вас. Тут собраны наиболее типичные ситуации и способы их решения как из личного опыта автора, так и собранные по всему Интернету.
Ошибка в комментарии к коммиту
git commit --amend
Как отменить последний коммит?
Можно использовать git reset , вот так:
git reset --hard HEAD
1 означает один коммит до HEAD, т.е. до текущего положения. Стоит заметить, что это «ядерный» способ, который отменит все изменения. Если вам нужно сохранить всё, что вы сделали, но еще не успели закоммитить, используйте:
git reset --soft HEAD
Удалить ветку на сервере
git push origin --delete имя_ветки
В чём разница между «git pull» и «git fetch»?
git pull — это, по сути, git fetch , после которого сразу же следует git merge . git fetch получает изменения с сервера и сохраняет их в refs/remotes/ . Это никак не влияет на локальные ветки и текущие изменения. А git pull вливает все эти изменения в локальную копию.
Как отменить «git add» до коммита?
Вы выполнили git add имя_файла случайно и хотите отменить добавление файла. Если коммит ещё не был сделан, то поможет:
git reset имя_файла
Как разрешать конфликты слияния?
Используйте программу git mergetool , которая предоставляет удобный интерфейс для разрешения конфликтов.
Удалить все локальные файлы и директории, которые не отслеживает Git, из вашей текущей копии
Осторожно! Лучше сделайте перед этим бэкап.
Клонировать все ветки с сервера
Скорее всего, вы это уже сделали, а ветки просто скрыты. Вот команда, чтобы показать их:
Можно использовать git checkout origin/имя_ветки , чтобы посмотреть на нужную ветку. Или git checkout -b имя_ветки origin/имя_ветки , чтобы создать локальную ветку, соответствующую удалённой.
Переименовать локальную ветку
git branch -m oldname newname
Вернуться к любому коммиту
Можно использовать git reset , как показано ранее. Это будет означать, что вы хотите навсегда вернуться к тому состоянию, в котором вы были, а не просто посмотреть на него (для этого надо сделать checkout). Идентификатор коммита должен быть такой, какой прописан в выводе команды git log .
git reset --hard идентификатор_коммита
Ещё раз повторим: команда отменит все текущие изменения, так что убедитесь, что вам это действительно нужно. Или используйте --soft вместо --hard.
Удалить подмодуль (submodule)
Создание подмодулей используется довольно редко, но иногда они всё-таки встречаются. Вот, что вам нужно:
git submodule deinit submodulename
git rm submodulename
git rm --cached submodulename
rm -rf .git/modules/submodulename
Перезаписать локальные файлы во время git pull
Вам снова поможет git reset :
git fetch --all
git reset --hard origin/master
Как добавить пустую директорию в репозиторий?
Никак! Такая возможность просто не поддерживается, т.к. считается, что вам это не нужно. Но есть один трюк. Можно создать файл .gitignore в нужной директории со следующим содержимым:
Экспортирование исходников аналогично «svn export»
Используйте git archive , например, так:
git archive --format zip --output /путь/к/файлу/файл.zip master
Я хочу контролировать версию моего веб-сервера, как описано в контроля версий для моего веб-сервера, создав git-РЕПО из моего /var/www directory . Я надеялся, что тогда я смогу перенести веб-контент с нашего dev-сервера на github, вытащить его на наш производственный сервер и провести остаток дня в пуле.
по-видимому, излом в моем плане заключается в том, что Git не будет уважать права доступа к файлам (я не пробовал, только читал об этом сейчас.) Я думаю, это имеет смысл в что разные коробки могут иметь разные настройки пользователя/группы. Но если бы я хотел заставить разрешения распространяться, зная, что мои серверы настроены одинаково, есть ли у меня какие-либо варианты? Или есть более простой способ, что я пытаюсь сделать?
идея в том, чтобы хранить в .git_cache_meta file разрешения файлов и каталогов.
Это отдельный файл, не версионный непосредственно в репозитории Git.
вот почему использование это:
- bundle ваше РЕПО и сохраните соответствующие права доступа к файлам.
- скопируйте эти два файла на удаленный сервер
- восстановить РЕПО там, и применить разрешение
Git-это система управления версиями, созданная для разработки программного обеспечения, поэтому из всего набора режимов и разрешений она хранит только исполняемый бит (для обычных файлов) и бит символической ссылки. Если вы хотите сохранить полные разрешения, вам нужен сторонний инструмент, например git-cache-meta (упоминается VonC), или Метахранилища (используется etckeeper). Или вы можете использовать IsiSetup, который IIRC использует git в качестве бэкэнда.
Это довольно поздно, но может помочь некоторым другим. Я делаю то, что вы хотите сделать, добавив два крючка git в мой репозиторий.
.git / hooks / предварительная фиксация:
.git / hooks / post-checkout:
первый крючок вызывается, когда вы" фиксируете " и будете читать права собственности и разрешения для всех файлов в репозитории и хранить их в файле в корне вызываемого репозитория .разрешения, а затем добавить .файл разрешений для фиксации.
второй крюк вызывается, когда вы "checkout" и будет проходить через список файлов в .файл разрешений и восстановить права собственности и разрешения этих файлов.
- вам может потребоваться выполнить фиксацию и проверку с помощью sudo.
- убедитесь, что сценарии pre-commit и post-checkout имеют разрешение на выполнение.
в случае, если вы входите в это прямо сейчас, я только что прошел через это сегодня и могу подвести итог, где это стоит. Если вы еще не пробовали это, некоторые детали здесь могут помочь.
Я думаю, что подход @Omid Ariyan-лучший способ. Добавьте сценарии pre-commit и post-checkout. Не забудьте назвать их точно так же, как это делает Omid, и не забудьте сделать их исполняемыми. Если вы забудете любой из них, они не имеют никакого эффекта, и вы запускаете "git commit" снова и снова, задаваясь вопросом, почему ничего не происходит:) кроме того, если вы вырезаете и вставляете из веб-браузера, будьте осторожны, чтобы кавычки и галочки не были изменены.
если вы запустите сценарий предварительной фиксации один раз (запустив git commit), то файл .будут созданы разрешения. Вы можете добавить его в репозиторий, и я думаю, что нет необходимости добавлять его снова и снова в конце сценария предварительной фиксации. Но это не больно, я думаю (надеюсь).
есть несколько небольших проблем с именем каталога и наличие пробелов в именах файлов в сценариях Omid. Пробелы были проблемой здесь, и у меня были некоторые проблемы с исправлением IFS. Для записи этот сценарий предварительной фиксации работал правильно для меня:
теперь, что мы получим от этого?
The .файл разрешений находится на верхнем уровне репозитория git. Он имеет одну строку на файл, вот верхняя часть моего примера:
как вы можете видеть, у нас есть
поэтому я оставляю только первый, это все, что мне нужно. Мое имя пользователя на веб-сервере действительно отличается, но что более важно, вы не можете запустить chown, если вы не корень. Может запустить "chgrp", однако. Достаточно ясно, как это использовать.
в первом ответ в этом посте, тот, который наиболее широко принят, предложение так использовать git-cache-meta, скрипт, который выполняет ту же работу, что и скрипты крючка pre / post здесь (разбор вывода из git ls-files ). Эти скрипты мне легче понять, код git-cache-meta более сложный. Можно сохранить git-cache-meta в пути и написать сценарии предварительной фиксации и после проверки, которые будут его использовать.
пробелы в именах файлов-это проблема с обоими Скрипты этого Omid. В сценарии post-checkout вы будете знать, что у вас есть пробелы в именах файлов, если вы видите такие ошибки
Я проверяю решения для этого. Вот то, что, кажется, работает, но я тестировал только в одном случае
поскольку информация о разрешениях является одной строкой за раз, я устанавливаю IFS в$, Поэтому только разрывы строк рассматриваются как новые вещи.
Я читал, что очень важно установить переменную среды IFS обратно так, как она был! Вы можете понять, почему сеанс оболочки может пойти плохо, если вы оставите $ единственным разделителем.
в pre-commit / post-checkout опция будет использовать утилиту" mtree "(FreeBSD) или" Fmtree "(Ubuntu), которая " сравнивает файловую иерархию со спецификацией, создает спецификацию для файловой иерархии или изменяет спецификацию."
по умолчанию установлены флаги, gid, link, mode, nlink, size, time, type и uid. Это можно приспосабливать к специфической цели с переключателем-k.
Я работаю на FreeBSD 11.1, концепция виртуализации тюрьмы freebsd делает операционную систему оптимальной. Текущая версия Git, которую я использую, - 2.15.1, я также предпочитаю запускать все на сценариях оболочки. Имея это в виду, я изменил приведенные выше предложения следующим образом:
git push: .git/hooks / pre-commit
git pull: .git/hooks / post-merge
Если по какой-то причине вам нужно, чтобы воссоздать сценарий .разрешения вывод файла должен иметь следующий формат:
для a .файл gitignore с 644 разрешениями, предоставленными root: wheel
обратите внимание, что мне пришлось внести несколько изменений в параметры stat.
одно дополнение к ответу @Omid Ariyan-это разрешения на каталоги. Добавьте это после for петли done в своем pre-commit сценарий.
git config --global user.name "[name]" — установить имя, которое будет прикрепляться к коммиту.
git config --global user.email "[email address]" — установить email, который будет прикрепляться к коммиту.
git config --global color.ui auto — включить полезную подсветку командной строки.
git config --global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).
git config --global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.
Создание репозиториев
git init [project-name] — создать новый локальный репозиторий с заданным именем.
git clone [url] — загрузить проект и его полную историю изменений.
Работа с изменениями
git status — полный список изменений файлов, ожидающих коммита.
git status -s — краткий вид изменений.
git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).
git add [file] — сделать указанный файл готовым для коммита.
git add . — сделать все измененные файлы готовыми для коммита.
git add '*.txt' — добавить только файлы, соответствующие указанному выражению.
git add --patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.
git diff --staged — показать что было добавленно в индекс с помощью git add , но еще не было закоммиченно.
git diff HEAD — показать что изменилось с последнего коммита.
git diff HEAD^ — показать что изменилось с предпоследнего коммита.
git diff [branch] — сравнить текущую ветку с заданной.
git difftool -d — то же самое, что и diff , но показывает изменения в заданной difftool.
git difftool -d master.. — показать изменения, сделанные в текущей ветке.
git diff --stat — показать статистику какие файлы были изменены и как.
git reset [file] — убрать файлы из индекса коммита (изменения не теряются).
git commit --amend — добавить изменения к последнему коммиту.
Работа с ветками
git branch — список всех локальных веток в текущей директории.
git branch [branch-name] — создать новую ветку.
git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.
git checkout -b <name> <remote>/<branch> — переключиться на удаленную ветку.
git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.
git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.
git merge --no-ff [branch] — соединить ветки без режима “fast forwarding”.
git branch -a — посмотреть полный список локальных и удаленных веток.
git branch -d [branch] — удалить заданную ветку.
git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.
git branch -m <oldname> <newname> — переименовать ветку.
Работа с файлами
git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.
git rm --cached [file] — удалить файл из репозитория, но сохранить его локально.
git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.
Отслеживание файлов
.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:
git ls-files --other --ignored --exclude-standard — список всех игнорируемых файлов.
Сохранение фрагментов
git stash — положить во временное хранилище все отслеживаемые файлы.
git stash pop — восстановить последние файлы, положенные во временное хранилище.
git stash list — список всех сохраненных изменений во временном хранилище.
git stash drop — удалить последние файлы, положенные во временное хранилище.
Просмотр истории
git log — список изменения текущей ветки.
git log --follow [file] — список изменения текущего файла, включая переименования.
git log --pretty=format:"%h %s" --graph — изменение вида отображения истории изменений.
git log --author='Name' --after= --pretty=oneline --abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.
git log --no-merges master.. — посмотреть историю изменений только для текущей ветки.
git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.
git show [commit] — показать метадату и изменения в заданном коммите.
git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.
Отмена коммитов
git reset — убрать изменения из индекса коммита, сами изменения останутся.
git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.
git reset --hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.
Синхронизация изменений
git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.
git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.
git push — запушить текущую ветку в удаленную ветку.
git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.
git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.
git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.
git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.
git pull [remote][branch] — указать конкретную удаленную ветку для слияния.
git remote — посмотреть список доступных удаленных репозиториев.
git remote -v — посмотреть детальный список доступных удаленных репозиториев.
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
Это означает, что у вас чистый рабочий каталог, другими словами — в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. Наконец, команда сообщает вам на какой ветке вы находитесь и сообщает вам, что она не расходится с веткой на сервере. Пока что это всегда ветка master , ветка по умолчанию; в этой главе это не важно. В главе Ветвление в Git будут рассмотрены ветки и ссылки более детально.
Предположим, вы добавили в свой проект новый файл, простой файл README . Если этого файла раньше не было, и вы выполните git status , вы увидите свой неотслеживаемый файл вот так:
Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status . Статус Untracked означает, что Git видит файл, которого не было в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить README, так давайте сделаем это.
Отслеживание новых файлов
Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add . Чтобы начать отслеживание файла README , вы можете выполнить следующее:
Если вы снова выполните команду status , то увидите, что файл README теперь отслеживаемый и добавлен в индекс:
Вы можете видеть, что файл проиндексирован, так как он находится в секции «Changes to be committed». Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init , затем вы выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет все файлы из указанного каталога в индекс.
Индексация изменённых файлов
Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл CONTRIBUTING.md и после этого снова выполните команду git status , то результат будет примерно следующим:
Файл CONTRIBUTING.md находится в секции «Changes not staged for commit» — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add . Это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния. Вам может быть понятнее, если вы будете думать об этом как «добавить этот контент в следующий коммит», а не как «добавить этот файл в проект». Выполним git add , чтобы проиндексировать CONTRIBUTING.md , а затем снова выполним git status :
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Что за чёрт? Теперь CONTRIBUTING.md отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add . Если вы выполните коммит сейчас, то файл CONTRIBUTING.md попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:
Сокращенный вывод статуса
Вывод команды git status довольно всеобъемлющий и многословный. Git также имеет флаг вывода сокращенного статуса, так что вы можете увидеть изменения в более компактном виде. Если вы выполните git status -s или git status --short вы получите гораздо более упрощенный вывод:
Новые неотслеживаемые файлы помечены ?? слева от них, файлы добавленные в отслеживаемые помечены A , отредактированные файлы помечены M и так далее. В выводе содержится два столбца — в левом указывается статус файла, а в правом модифицирован ли он после этого. К примеру в нашем выводе, файл README модифицирован в рабочем каталоге, но не проиндексирован, а файл lib/simplegit.rb модифицирован и проиндексирован. Файл Rakefile модифицирован, проиндексирован и ещё раз модифицирован, таким образом на данный момент у него есть те изменения, которые попадут в коммит, и те, которые не попадут.
Игнорирование файлов
Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы (различные логи, результаты сборки программ и т. п.). В таком случае, вы можете создать файл .gitignore . с перечислением шаблонов соответствующих таким файлам. Вот пример файла .gitignore :
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т. д. и т. п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.
К шаблонам в файле .gitignore применяются следующие правила:
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ ( * ) соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса ( ? ) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом ( 7 ), соответствуют любому символу из интервала (в данном случае от 0 до 9). Вы также можете использовать две звёздочки, чтобы указать на вложенные каталоги: a/**/z соответствует a/z , a/b/z , a/b/c/z , и так далее.
Вот ещё один пример файла .gitignore :
В простейшем случае репозиторий будет иметь один файл .gitignore в корневом каталоге, правила из которого будут рекурсивно применяться ко всем подкаталогам. Так же возможно использовать .gitignore файлы в подкаталогах. Правила из этих файлов будут применяться только к каталогам, в которых они находятся. Например, репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore .
Детальное рассмотрение использования нескольких .gitignore файлов выходит за пределы этой книги; детали доступны в справке man gitignore .
Просмотр индексированных и неиндексированных изменений
Допустим, вы снова изменили и проиндексировали файл README , а затем изменили файл CONTRIBUTING.md без индексирования. Если вы выполните команду git status , вы опять увидите что-то вроде:
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff --staged . Эта команда сравнивает ваши проиндексированные изменения с последним коммитом:
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
а так же git diff --cached для просмотра проиндексированных изменений ( --staged и --cached синонимы):
Мы будем продолжать использовать команду git diff различными способами на протяжении всей книги. Существует еще один способ просматривать эти изменения, если вы предпочитаете графический просмотр или внешнюю программу просмотра различий, вместо консоли. Выполнив команду git difftool вместо git diff , вы сможете просмотреть изменения в файле с помощью таких программ как emerge, vimdiff и других (включая коммерческие продукты). Выполните git difftool --tool-help чтобы увидеть какие из них уже установлены в вашей системе.
Коммит изменений
Теперь, когда ваш индекс находится в таком состоянии, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status , вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit :
Эта команда откроет выбранный вами текстовый редактор.
Редактор устанавливается переменной окружения EDITOR — обычно это vim или emacs, хотя вы можете установить любой другой с помощью команды git config --global core.editor , как было показано в главе Введение).
В редакторе будет отображён следующий текст (это пример окна Vim):
Для ещё более подробного напоминания, что же именно вы поменяли, можете передать аргумент -v в команду git commit . Это приведёт к тому, что в комментарий будет также помещена дельта/diff изменений, таким образом вы сможете точно увидеть все изменения которые вы совершили.
Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit указав его после параметра -m , как в следующем примере:
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add :
Обратите внимание, что в данном случае перед коммитом вам не нужно выполнять git add для файла CONTRIBUTING.md , потому что флаг -a включает все файлы. Это удобно, но будьте осторожны: флаг -a может включить в коммит нежелательные изменения.
Удаление файлов
Для того чтобы удалить файл из Git, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm , которая также удаляет файл из вашего рабочего каталога, так что в следующий раз вы не увидите его как «неотслеживаемый».
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
Затем, если вы выполните команду git rm , удаление файла попадёт в индекс:
После следующего коммита файл исчезнет и больше не будет отслеживаться. Если вы изменили файл и уже проиндексировали его, вы должны использовать принудительное удаление с помощью параметра -f . Это сделано для повышения безопасности, чтобы предотвратить ошибочное удаление данных, которые ещё не были записаны в снимок состояния и которые нельзя восстановить из Git.
Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске, но перестать отслеживать изменения в нём. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами, или кучу промежуточных файлов компиляции. Чтобы сделать это, используйте опцию --cached :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Обратите внимание на обратный слеш ( \ ) перед * . Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы, имеющие расширение .log и находящиеся в каталоге log/ . Или же вы можете сделать вот так:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv . Единственное отличие состоит лишь в том, что mv — одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ для переименования файла, а затем воспользоваться командами add/rm перед коммитом.
Читайте также: