LINUX.ORG.RU

Как в git хранить локальные изменения и не коммитить их

 


0

1

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

gitignore не сработает потому что файлы должны трекатся, я хочу игнорировать только несколько строк внутри
git stash - в принципе рабочее решение, но не самое удобное
git assume-unchange - трюк для оптимизации гита, а не игнорирование файлов https://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged 

Что я хочу в идеале, пусть для упрощения есть один файл config.js в котором я меняю одну строку logger = null

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

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

★★★

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

своя ветка

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

своя репа

kindof
()

Я раньше для похожего кейса использовал команды:

git update-index --skip-worktree src/main/resources/application.properties
git update-index --no-skip-worktree src/main/resources/application.properties

Но я не уверен, что это актуальное решение и то решение, которое тебе нужно.

EXL ★★★★★
()
Ответ на: комментарий от kindof

своя ветка

Но мне часто (раз 5 в день) нужно чекаутится на новые ветки, и раз 10 в день пулить актуальные данные (master). Если нужные мне локальные изменения будут в моей ветке, как тогда будет проходить процесс?

git checkout task-99 (тут мне нужны мои локальные изменения)
git pull origin master
git add . 
git commit -m 'task 99 done'
git push // должно запушиться без моих изменений, только с одним коммитом
abs ★★★
() автор топика
Ответ на: комментарий от grem

Например, для дерева gentoo у меня примерно такой рабочий процесс внутри моего форка для внесения изменений из исходной репы (upstream - ссылка на исходную репу; myfeature - ранее созданная ветка, где я вношу изменения):

git checkout master
git fetch upstream
git merge upstream/master
git checkout myfeature
git rebase master

Источник upstream добавлен командой git remote add upstream url-to-upstream-repo.

grem ★★★★★
()

какая-то XY-проблема, на мой взгляд.

есть один файл config.js

сделай еще один файл config.local.js и в него положи то, что тебе нужно. и этот файл заигнорь.

соединить два конфига на старте ПО гораздо проще, чем эти приседания в гамаке с гитом, которые ты хочешь затеять.

aol ★★★★★
()
Ответ на: комментарий от abs

Но мне часто (раз 5 в день) нужно чекаутится на новые ветки

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

grem ★★★★★
()
Ответ на: комментарий от grem

Это нечасто.

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

Без локальной ветки это примерно так

git checkout task-99 (тут мне нужны мои локальные изменения)
git pull origin master
git add . 
git commit -m 'task 99 done'
git push // должно запушиться без моих изменений, только с одним коммитом
abs ★★★
() автор топика
Ответ на: комментарий от abs

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

Насколько помню, git не разрешит переключиться на другую ветку, если есть незакоммиченные изменения или не соранёнеые в stash. Но из stash изменения нужно будет обратно извлекать, да ещё и выбирать иногда что именно - в твоём случае это дополнительная операция.

Можешь даже перед переключением на нужную ветку просто делать коммит в своей тестовой - всегда позже можно в него же добавить новые изменения командами git add и git commit h-amend.

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

Проще, имхо, держать просто свой форк и просто качать в него изменения из основного проекта. Так тебе и внутри фотка ветки не нужны; для форка будет отдельный терминал; можно в нём запретить делать push в исходный проект - случайно не отправишь ничего.

grem ★★★★★
()

Может быть глобальный .gitignore поможет? По сути он как раз для решения подобных проблем и нужен.

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

evgeny_aa ★★☆
()
Последнее исправление: evgeny_aa (всего исправлений: 3)

По-хорошему, самое гибкое - вынести всю конфигурацию в переменные окружения.

Git такие проблемы не может решить. Паллиативное решение, чуть лучше, чем git stash, — поверх Git накатить локальный Mercurial и хранить историю своих правок в нём.

emorozov
()

Возможный вариант: если желаемые правки относительно фиксированы - хранить их вне дерева гит и применять при сборке/развёртывании(например через patch).

Elyas ★★★★★
()
Последнее исправление: Elyas (всего исправлений: 1)
Ответ на: комментарий от abs

В любом случае при деплое скорее всего в эти конфиги придётся вносить какие либо изменения. Вам девопсы ещё не настучали по голове из за того что нельзя добавить локальные конфиги программе?

eternal_sorrow ★★★★★
()

Если это какие-то файлы которых вообще не должно быть в продакшене то отдельная папка и gintignore, а внутри нее свой git.

Если это изменения в файлах которые есть в продакшене, но там они должны быть не рабочими, то все такие включения оборачиваются в if (APPLICATION_ENV == ‘dev’) или if (APPLICATION_ENV == ‘production’)

Suntechnic ★★★★★
()
Ответ на: комментарий от grem

Ещё и файлы конфигурации этих vcs друг от друга придётся прятать, незакоммиченныыми в основной vcs.

в gitignоre добавляется .svn .fossil и наоборот (они так и так должны быть добавлены, ради зеркал). Вторая VCS она для личных бекапов и откатов просто по мелочи и если что, то снести/переставить не проблема

MKuznetsov ★★★★★
()
Ответ на: комментарий от aol

сделай еще один файл config.local.js и в него положи то, что тебе нужно. и этот файл заигнорь.

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

dvetutnev
()
Последнее исправление: dvetutnev (всего исправлений: 1)

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

urxvt ★★★★★
()
Ответ на: комментарий от dvetutnev

Что вы все прицепились к конфигурации. Очень часто приходится вставлять в проект локальные костыли, чтобы разрабатывалось легче – это не обязательно конфиги, часто прямо грязные патчи кода. И допиливать эти костыли до состояния «ничего не ломает и пройдёт ревью» просто нет времени, сил и желания.

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

snizovtsev ★★★★★
()
Последнее исправление: snizovtsev (всего исправлений: 2)

Как уже писали выше, обычно в таких случаях добавляют поддержку нескольких уровней конфигурации: сперва читаем config.js, потом config.local.js (который не коммитится в Git) и переписываем его значениями всё, что было до него. Если речь не про фронт, то можно ещё читать environment variables или параметры из командной строки.

То, что ты хочешь, Git вроде не позволяет.

runtime ★★★★
()