Git не отслеживать файл

Обновлено: 02.07.2024

Файлы в рабочем каталоге Git можно отслеживать или нет.

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

В этой статье объясняется, как удалить неотслеживаемые файлы в Git.

Удаление неотслеживаемых файлов

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

Перед запуском фактической команды и удалением неотслеживаемых файлов и каталогов используйте параметр -n , который выполнит «пробный запуск» и покажет вам, какие файлы и каталоги будут удалены:

Результат будет выглядеть примерно так:

Если некоторые из файлов, перечисленных выше, важны, вам следует либо начать отслеживать эти файлы с помощью git add <file> либо добавить их в свой .gitignore .

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

Команда распечатает все успешно удаленные файлы и каталоги:

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

Параметр -f означает силу. Если не используется и для переменной конфигурации Git clean.requireForce установлено значение true, Git не удалит файлы.

Чтобы в интерактивном режиме удалить неотслеживаемые файлы, используйте параметр -i :

Вывод покажет файлы и каталоги, которые нужно удалить, и спросит вас, что делать с этими файлами:

Выберите один из вариантов и нажмите Enter .

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

Удаление игнорируемых файлов

Команда git clean также позволяет удалять игнорируемые файлы и каталоги.

Чтобы удалить все игнорируемые и неотслеживаемые файлы, используйте параметр -x :

Если вы хотите удалить только игнорируемые файлы и каталоги, используйте параметр -X :

Приведенная выше команда удалит все файлы и каталоги, перечисленные в вашем .gitignore и сохранит неотслеживаемые файлы.

Выводы

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

Я клонировал проект, который включает в себя несколько .csproj файлов. Мне не нужно / не нравится, чтобы мои локальные csproj файлы отслеживались Git (или появлялись при создании патча), но они явно нужны в проекте.

Я добавил *.csproj к своему МЕСТНОМУ .gitignore , но файлы уже находятся в репо.

Когда я набираю git status, он показывает мои изменения, csproj которые я не заинтересован в отслеживании или отправке патчей.

Как убрать «отслеживание» этих файлов из моего личного репозитория (но сохранить их в источнике, чтобы я мог их использовать), чтобы не видеть изменения при создании статуса (или создании патча)?

@Cupcake, вопрос, на который ты ссылался, был написан через 15 дней после этого? Возможно, вы имеете в виду другое? Канонические вопросы @marflar не обязательно должны быть самыми старыми , только самые лучшие . На тот, на который я

Просто вызовите git rm --cached каждый из файлов, которые вы хотите удалить из контроля версий. Пока ваши локальные шаблоны игнорирования верны, вы не увидите эти файлы, включенные в вывод состояния git.

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

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

Что вы, вероятно, хотите сделать: (снизу @ Райан Тейлор ответ )

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

«git rm --cached <file>» удалит <file> из управления версиями, сохранив его в рабочем хранилище. Будь то, что вы хотите . Но когда другие будут извлекать хранилище, будет ли удален их собственный файл * .csproj? Потому что, если мы хотим, чтобы файл не отслеживался, но не удалялся. Если вы пытаетесь удалить ВСЕ файлы в каталоге, объедините его с git ls-files: git ls-files | xargs git rm --cached - это удалит все из индекса git в данном каталоге, не удаляя фактические файлы. git rm --cached -r <dir> работает рекурсивно над папкой и всеми файлами в ней. Это остановит отслеживание файла, сохранит его локально, но приведет к тому, что он будет удален для всех, кто тянет

Если вы это сделаете git update-index --assume-unchanged file.csproj , git не будет проверять file.csproj на наличие изменений автоматически: это остановит их появление в состоянии git, когда вы их измените. Таким образом, вы можете пометить все ваши файлы .csproj таким образом, хотя вам придется вручную отмечать любые новые файлы, которые отправляет вам репозиторий верхнего уровня. (Если они есть в вашем .gitignore или .git/info/exclude , то созданные вами будут игнорироваться)

Я не совсем уверен, что такое файлы .csproj . если они что-то похожи на конфигурации IDE (аналогично файлам Eclipse .eclipse и .classpath), то я бы предложил, чтобы они никогда не контролировались исходным кодом в все. С другой стороны, если они являются частью системы сборки (например, Makefiles), то, очевидно, они должны - и был бы полезен способ получения необязательных локальных изменений (например, из local.csproj a la config.mk). разделите сборку на глобальные части и локальные переопределения.

Это единственный правильный ответ здесь! Я использую ответ @araqnids в течение многих лет, и он работает именно так, как было предложено для решения этой проблемы. Что означает префикс «file» в аргументе команды? Почему это не просто .csproj ? Есть ли способ, которым вы можете обнаружить, что это было сделано для файла, или для каких файлов это было сделано в репо? Я немного нервничаю из-за того, что забыл, что сделал это, а потом удивляюсь, почему, черт возьми, этот файл не обновляется позже! @GreenAsJade: git ls-files -v покажет файлы, которые предполагается неизменными, с помощью строчного индикатора (например, h вместо обычного H для кэшированных файлов).

1. Это сохранит локальный файл для вас, но удалит его для всех остальных, когда они потянут.

git rm --cached <file-name> или git rm -r --cached <folder-name>

2. Это для оптимизации, как папка с большим количеством файлов, например, SDK, которые, вероятно, никогда не изменятся. Он говорит git прекратить проверять эту огромную папку каждый раз на наличие изменений, локально, поскольку она не будет иметь никаких изменений. assume-unchanged Индекс будет обнулен и файл (ы) перезаписаны , если есть вверх по течению изменения в файле / папке (при вытягивании).

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

Важно знать, что git update-index не будет распространяться с помощью git, и каждому пользователю придется запускать его независимо.

Этот ответ является наиболее полным - он предлагает различные решения с разветвлениями каждого. В конкретном случае, с которым я работаю, пароль встроен в файл конфигурации. Я хочу распространить файл шаблона, а затем добавить пароль к моей копии. Копия с паролем должна игнорироваться и не перезаписываться. Как я могу проверить, в моем локальном компьютере, какие файлы применяются для «предположить, без изменений» или «skip-worktree»? Очень хороший ответ Но git выдает ошибку, когда я пытаюсь переключиться на другую ветку: error: «Ваши локальные изменения в следующих файлах будут перезаписаны извлечением . », и решение состоит в том, чтобы спрятать изменения перед переключением и отстегнуть, когда ты возвращаешься в ветку. @RyanTaylor: Я пытался сначала предположить, что без изменений (не работает), и пропустить команду рабочего дерева (не работает), когда я проверяю с помощью состояния git, файлы не отображаются, значит команда работает. Но когда я снова it gives me error that your local changes would be overwritten извлекаю код из репозитория git origin в этих 2 файлах, это означает, что он не отслеживается, верно?

Это двухэтапный процесс:

Удалить отслеживание файла / папки - но сохранить их на диске - используя

Теперь они не отображаются как «измененные», но все равно отображаются как

Добавьте их в .gitignore

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

Принятый ответ все еще не работал для меня

git rm -r - кэшировано.

мерзавец добавить.

git commit -m "исправление .gitignore"

Эта ссылка очень полезна, особенно для рекурсивного удаления всех файлов в .gitignore Я возвращался сюда 3 раза, надеюсь, я смогу сохранить память до следующего раза! @ Комментарий Эдварда Ньюэлла, как и в приведенном выше ответе, также применим и здесь: «это удалит файл из отслеживания, сохранит его локально, но приведет к тому, что он будет удален для всех, кто извлекает »

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

убедитесь, что вы находитесь в корне проекта.

Тогда вы можете сделать обычное

Добавить

совершить

От себя

Вывод

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

Удаляет весь кеш
Смотрит на ваш .gitignore
Добавляет файлы, которые вы хотите отслеживать
Подталкивает к вашему репо

Когда вы говорите об удалении или добавлении, вы забываете сказать, когда и где. Удаление из списка треков? Из хранилища? Из локального проектного пространства? Удаление на тягу? На коммит? На толчок? Увы, у всех авторов здесь одна и та же проблема. @Gangnus Я не думаю, что кто-то "прояснил" мысль, которую вы пытаетесь сделать, потому что совершенно очевидно, что файл на самом деле не удаляется с диска или из хранилища. Этот ответ указывает хронологический порядок команд. Это не таинственно или плохо объяснено, поскольку Ваш комментарий предположил бы. @ Комментарий Эдварда Ньюэлла, как и в приведенном выше ответе, применим также и к этому: «это удалит файл из отслеживания, сохранит его локально, но приведет к тому, что он будет удален для всех, кто тянет ».

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

Ответ на другой вопрос предполагает , что это может быть пропуск worktree , которые потребуются.

Нет, не совсем: --skip-worktree используется для сохранения файла в хранилище, но для остановки отслеживания его изменений . Как говорится в вашем ответе: --skip-worktree полезен, когда вы указываете git не трогать определенный файл, потому что разработчики должны его изменить @ErdalG. Точно. В соответствии с вопросом, они хотят игнорировать любые изменения в файле, но сохраняют файл в Согласитесь с @the_new_mr --assume-unchanged и --skip-worktree получите аналогичный эффект, но их цели совершенно другие. Первый предназначен для ускорения производительности git путем обмана git не проверять определенные файлы , а второй - для игнорирования будущих изменений в определенных файлах , которые подходят для времени выполнения, но важных файлов.

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

git rm --cached app/**/*.xml

git rm --cached -r app/widgets/yourfolder/

Это очень хорошее решение, потому что в любом случае вы хотите починить gitignore шаг за шагом

Чтобы предотвратить мониторинг файла с помощью git

И чтобы вернуть его обратно используйте

Многие люди советуют вам использовать git update-index --assume-unchanged . Действительно, это может быть хорошим решением, но только в краткосрочной перспективе.

Что вы, вероятно, хотите сделать, это: git update-index --skip-worktree .

(Третий вариант, который вам, вероятно, не нужен: git rm --cached он сохранит ваш локальный файл, но будет помечен как удаленный из удаленного хранилища.)

Разница между первыми двумя вариантами?

assume-unchanged Это временно позволяет скрыть изменения из файла. Если вы хотите скрыть изменения, внесенные в файл, изменить файл, а затем оформить заказ в другой ветке, вам придется использовать, no-assume-unchanged вероятно, сохраненные изменения.
skip-worktree будет следовать за вами независимо от того, какую ветку вы заказываете, с вашими модификациями!

Случай использования assume-unchanged

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

Мне нравится использовать его, когда я хочу только на некоторое время остановить отслеживание изменений + зафиксировать кучу файлов ( git commit -a ), связанных с той же модификацией.

Случай использования skip-worktree

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

1. Создайте первую версию этого класса, заполните поля, которые вы можете заполнить, и оставьте другие поля пустыми / пустыми.
2: зафиксируйте и отправьте его на удаленный сервер.
3: git update-index --skip-worktree MySetupClass.java
4: Обновите свой класс конфигурации с вашими собственными параметрами.
5: вернитесь к работе над другой функциональностью.

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

PS: делайте одно или другое, но не оба, так как у вас будут нежелательные побочные эффекты. Если вы хотите попробовать другой флаг, вы должны сначала отключить его.

есть файл, который отслеживается git , но теперь файл находится на .gitignore список.

однако этот файл продолжает отображаться в git status после редактирования. Как вы заставляете git чтобы совсем забыть об этом?

.gitignore позволит предотвратить неотслеживаемые файлы могут быть добавлены (без add -f ) к набору файлов, отслеживаемых git, однако git будет продолжать отслеживать любые файлы, которые уже отслеживаются.

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

удаление файла из Главной редакции произойдет при следующем коммите.

серия команд ниже удалит все элементы из индекса Git (не из рабочего каталога или локального РЕПО), а затем обновит индекс Git, соблюдая при этом git игнорирует. PS. Index = Cache

первый:

затем:

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

Я всегда использую эту команду, чтобы удалить эти неотслеживаемые файлы. Однострочный, Unix-стиль, чистый вывод:

он перечисляет все ваши игнорируемые файлы, заменяет каждую выходную строку на строку в кавычках вместо того, чтобы обрабатывать пути с пробелами внутри, и передает все в git rm -r --cached чтобы удалить пути / файлы / dirs из индекса.

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

переместить его, зафиксировать, а затем переместить его обратно. Это работало для меня в прошлом. Вероятно, есть более "хитрый" способ добиться этого.

что не сработало для меня

поэтому я предлагаю

использует до ls-files и

Я сделал это с помощью git filter-branch. Точная команда, которую я использовал, была взята из man-страницы:

предупреждение: это приведет к удалению файла из всей вашей истории

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

допустим, вы уже добавили/зафиксировали некоторые файлы в свой репозиторий git, а затем добавили их в свой .гитюдного; эти файлы будут по-прежнему присутствовать в ваш индекс репозитория. В этой статье мы увидим, как от них избавиться.

Шаг 1: зафиксируйте все ваши изменения

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

Шаг 2: Удалите все из репозитория

чтобы очистить РЕПО, используйте:

rm это команда удалить
- r позволит рекурсивный удаление
- cached будут удалены только файлы из индекса. Ваши файлы все еще будут там.

The rm команда может быть неумолимой. Если вы хотите попробовать то, что он делает заранее, добавить -n или --dry-run флаг, чтобы проверить вещи.

Шаг 3: Re добавить все

Шаг 4: Commit

ваш репозиторий чистые :)

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

обновить .gitignore file-например, добавьте папку, которую вы не хотите отслеживать в .gitignore .
git rm -r --cached . - удалить все отслеживаемые файлы, в том числе разыскиваемые и нежелательные. Ваш код будет в безопасности, пока вы сохранили локально.
git add . – все файлы будут добавлены обратно, за исключением .gitignore .

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

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

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

эти 2 статьи были полезны для меня:

git предположим-без изменений против skip-worktree и как игнорировать изменения в отслеживаемых файлах с Git

исходя из этого я делаю следующее, если файл уже отслеживается:

от в этот момент все локальные изменения в этом файле будут проигнорированы и не перейдут на удаленный. Если файл изменяется на удаленном, конфликт произойдет, когда git pull . Тайник не сработает. Чтобы решить ее, скопируйте содержимое файла в безопасное место и выполните следующие действия:

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

если все, кто работает с проектом, будет выполнять git update-index --skip-worktree <file> , проблемы с pull должен отсутствовать. Это решение подходит для файлов конфигураций, когда каждый разработчик имеет свою собственную конфигурацию проекта.

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

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

ответ от Мэтта страха был самым эффективным ИМХО. Ниже приведен только сценарий PowerShell для тех, кто в windows, чтобы удалить только файлы из своего репозитория git, который соответствует их списку исключений.

Если вы не хотите использовать CLI и работаете в Windows, очень простое решение-использовать TortoiseGit, Он имеет действие "удалить (сохранить локальный)" в меню, которое отлично работает.

В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды 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. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.

Читайте также: