Comments 32
UFO just landed and posted this here
>но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Зря, по-моему — общеизвестные или самые простые советы способствуют переходу из «начинающих» в «продвинутые» или даже из «интересующихся» в «продвинутые». Но все равно спасибо, добавил в закладки, к тому времени как стану начинающим :)
Зря, по-моему — общеизвестные или самые простые советы способствуют переходу из «начинающих» в «продвинутые» или даже из «интересующихся» в «продвинутые». Но все равно спасибо, добавил в закладки, к тому времени как стану начинающим :)
Способствуют, не спорю. Никто не рождается сразу с багажом знаний. Но и читать каждый раз про «первым делом укажите своё имя и почту», хотя пришел искать приёмы черной магии, утомительно, согласитесь.
translated.by/you/git-community-book/into-ru/trans/
Как раз вот тут мы переводим (уже больше половины перевели) Git Community Book, которая чрезвычайна полезна и начинающим.
Помогите нам сделать свободную, качественную и красивую книжку о Git!
Это было что-то типа рекламы. :)
Как раз вот тут мы переводим (уже больше половины перевели) Git Community Book, которая чрезвычайна полезна и начинающим.
Помогите нам сделать свободную, качественную и красивую книжку о Git!
Это было что-то типа рекламы. :)
Вопрос про push в удаленный бранч.
Можно ли его делать в не-bare репозиторий с имеющимися там изменениями?
Я хочу таким образом выкладывать код из репы на сервер, но чтобы при этом сделанные там изменения (те же самые конфиги) не затирались, а мерджились.
Видел какие-то вариант, но все чрезмерно замороченные. Может есть нормальный удобный способ?
Можно ли его делать в не-bare репозиторий с имеющимися там изменениями?
Я хочу таким образом выкладывать код из репы на сервер, но чтобы при этом сделанные там изменения (те же самые конфиги) не затирались, а мерджились.
Видел какие-то вариант, но все чрезмерно замороченные. Может есть нормальный удобный способ?
Т.е. Вы делаете коммит origin_head+1, и хотите выложить его, даже если кто-то запушил своё вариант origin_head+1?
Вам поможет git rebase origin/master — после этого можете пушить свои изменения.
Я бы держал свои изменения в отдельном бранче, а в мастер держал бы синхронизированным с репо на сервере, но сути это не меняет.
Вам поможет git rebase origin/master — после этого можете пушить свои изменения.
Я бы держал свои изменения в отдельном бранче, а в мастер держал бы синхронизированным с репо на сервере, но сути это не меняет.
То есть перед пушем туда мне надо сделать там rebase?
Да, пуш в мастер на удаленную машину предполагается из мастера. Но они все равно будут рассинхронизированы в части настроек (скажем логин и пароль для БД другие). При этом хотелось бы обновить удаленный репо и не затереть его настройки. Исключать конфиг из контроля версий неправильно. Перезаписывать файл поверх после пуша тоже плохо — т.к. в настройки может добавиться что-то, что не хотелось бы руками переносить.
Да, пуш в мастер на удаленную машину предполагается из мастера. Но они все равно будут рассинхронизированы в части настроек (скажем логин и пароль для БД другие). При этом хотелось бы обновить удаленный репо и не затереть его настройки. Исключать конфиг из контроля версий неправильно. Перезаписывать файл поверх после пуша тоже плохо — т.к. в настройки может добавиться что-то, что не хотелось бы руками переносить.
Да, перед пушем на апстримный сервер надо сделать ребэйз, тем самым вы притворитесь, будто спушили всё, что можно, и свой коммит сделали с пылу с жару, основываясь на самом последнем коммите из апстрима.
Я держу пароли (точнее, конфиги с настоящими паролями) и прочие специализированные штуки в отдельном бранче. При добавлении в мастере каких-либо важных фич просто мерджу этот бранч с мастером.
Или я не понял исходную задачу.
Я держу пароли (точнее, конфиги с настоящими паролями) и прочие специализированные штуки в отдельном бранче. При добавлении в мастере каких-либо важных фич просто мерджу этот бранч с мастером.
Или я не понял исходную задачу.
Просто я хочу, чтобы бранч с конфигами лежал на удаленном серваке, и автоматически примерживался, после пуша.
У меня была мысль, что если его смержить один раз когда-то давно, с тем смыслом, чтобы гит «знал» про этот мердж, и учитывал его. Будет ли это иметь работать? Или такие изменения затрутся в истории гита? Возможно я спрашиваю ерунду — я еще не разобрался для себя как работает гит.
У меня была мысль, что если его смержить один раз когда-то давно, с тем смыслом, чтобы гит «знал» про этот мердж, и учитывал его. Будет ли это иметь работать? Или такие изменения затрутся в истории гита? Возможно я спрашиваю ерунду — я еще не разобрался для себя как работает гит.
# я бы посоветовал еще одну комманду:
git pull. refs/remotes/origin/master-branch
# смержить удаленный бранч к себе
# ну и обратить внимание на такую последовательность:
git push origin origin/source-branch:refs/heads/new-branch
# создает на удаленном сервере бранч new-branch c кодом из source-branch
git checkout -b new-branch --track origin/new-branch
# создаль локальный new-branch и настроить его на треканье удаленного =)
git pull. refs/remotes/origin/master-branch
# смержить удаленный бранч к себе
# ну и обратить внимание на такую последовательность:
git push origin origin/source-branch:refs/heads/new-branch
# создает на удаленном сервере бранч new-branch c кодом из source-branch
git checkout -b new-branch --track origin/new-branch
# создаль локальный new-branch и настроить его на треканье удаленного =)
# и да, забыл
git push origin :heads/new-branch
# удалить созданный бранч в удаленном репозитории
git push origin :heads/new-branch
# удалить созданный бранч в удаленном репозитории
Git, c версии 1.6.2, кажется, пытается делать track`уемым бранч, если он был создан через -b.
Я укажи эти команды во второй части статьи, спасибо
Я укажи эти команды во второй части статьи, спасибо
там только точку не отделил в первой комманде
«git pull . refs/remotes/origin/master-branch»
а вообще гит — мощная штука, и наличие например «git commit --amend» очень порадовало.
«git pull . refs/remotes/origin/master-branch»
а вообще гит — мощная штука, и наличие например «git commit --amend» очень порадовало.
git commit -a --amend -C HEAD более чем удобно, да!
Но, честно сказать, меня больше порадовало недавно примененная
$ git filter-branch --tree-filter «sed -e 's#my_secret_pass#dbpassword#' -e 's#my_db_hostdbhost.tld#' -i settings.py» HEAD
где my_secret_pass и my_db_host были реальными паролем и хостом ^_^
Но, честно сказать, меня больше порадовало недавно примененная
$ git filter-branch --tree-filter «sed -e 's#my_secret_pass#dbpassword#' -e 's#my_db_hostdbhost.tld#' -i settings.py» HEAD
где my_secret_pass и my_db_host были реальными паролем и хостом ^_^
еще один полезный алиас из ~/.gitconfig
here = "!echo $(git symbolic-ref HEAD | sed 's/refs\\/heads\\///g')"
позволяет выполнять комманды типа
git push origin `git here` # пушнуть изменения в ветку удаленного репозитория
и подготавливает к написанию действительно страшных алиасов, типа killbranch, который будет прибивать и локальный бранч, и бранч в удаленном репозитории.
в общем алиасов хороших можно привести много — главное не боятся их писать — тем более что в гите их делать проще простого.
here = "!echo $(git symbolic-ref HEAD | sed 's/refs\\/heads\\///g')"
позволяет выполнять комманды типа
git push origin `git here` # пушнуть изменения в ветку удаленного репозитория
и подготавливает к написанию действительно страшных алиасов, типа killbranch, который будет прибивать и локальный бранч, и бранч в удаленном репозитории.
в общем алиасов хороших можно привести много — главное не боятся их писать — тем более что в гите их делать проще простого.
Из недавно освоенных полезных трюков:
git add -i # Интерактивное добавление файла в индекс
git add -p # Интерактивное добавление файла в индекс с выбором отдельных ханков (частный случай -i)
git rebase -i # Трансплантация ветки с редактированием состава коммитов (можно пропускать, редактировать, объединять)
git add -i # Интерактивное добавление файла в индекс
git add -p # Интерактивное добавление файла в индекс с выбором отдельных ханков (частный случай -i)
git rebase -i # Трансплантация ветки с редактированием состава коммитов (можно пропускать, редактировать, объединять)
Про rebase -i я еще расскажу!
Всегда интересовало — в каких случаях интерактивно, скажем, выборочно добавлять файл?
Всегда интересовало — в каких случаях интерактивно, скажем, выборочно добавлять файл?
* в каких случаях нужно
чем атомарнее коммит — там легче мёрж. так как коммит происходит на локальной машине без оверхеда работы по сети — то коммиты можно делать хоть раз в 5 минут
но иногда закапываешься в какую-то проблему, попутно исправляешь какие-то баги — в итоге в файле накапливаются изменения не связаные друг — с другом.
в таком случае лучше закоммитить по ханкам — всё что относится к одной фиче — в один коммит, что к другой — в другой коммит.
кроме того, очень полезная комманда: git cherry-pick. использовать можно так — есть бранч, в котором новая фича и его нельзя пока мержить в мастер. Но там попутно исправлено пару багов, а вас просят влить эти исправления в мастер. Делается в бранче сделаном от мастера
git cherry-pick BUGFIX_COMMIT_SHA1
и не надо заново вносить изменения или как-то менять историю (в этом случае вы подумаете, что «как хорошо, что я дулал коммиты атомарными и этот багфикс не тянет за собой кучу изменений связаных с новой фичей»)
но иногда закапываешься в какую-то проблему, попутно исправляешь какие-то баги — в итоге в файле накапливаются изменения не связаные друг — с другом.
в таком случае лучше закоммитить по ханкам — всё что относится к одной фиче — в один коммит, что к другой — в другой коммит.
кроме того, очень полезная комманда: git cherry-pick. использовать можно так — есть бранч, в котором новая фича и его нельзя пока мержить в мастер. Но там попутно исправлено пару багов, а вас просят влить эти исправления в мастер. Делается в бранче сделаном от мастера
git cherry-pick BUGFIX_COMMIT_SHA1
и не надо заново вносить изменения или как-то менять историю (в этом случае вы подумаете, что «как хорошо, что я дулал коммиты атомарными и этот багфикс не тянет за собой кучу изменений связаных с новой фичей»)
Я так делаю, к примеру, когда исправляю ошибку: вношу сами изменения с комментариями «для себя» или часто исправляю несколько ошибок или, к примеру, добавляю команды вывода в логи. И вот что бы сделать патчсеты с корректными названиями я и делаю git add -p. «Косметику», вроде логгирования и отладочных сообщений обычно не хочется отсылать в проекты из-за несоответствия стилей кодирования, поэтому я её потом при необходимости снова потестироваться трансплантирую наверх апстримовской ветки.
Неистово плюсую!
Столько новой инфы по гиту — это же просто праздник какой-то! :-)
Столько новой инфы по гиту — это же просто праздник какой-то! :-)
Ну в придачу ещё две полезные комманды:
git rerere — позволяет записывать решение конфликтов и при повторном мерже использовать их. Помогает в случае если бранч живет долго и часто возникает необходимость мержится с другими бранчами. Включается просто: git config --global rerere.enabled 1
И git rebase --onto. Позволяет перенести ветку с одним основанием на другое. Когда полезно: Есть мастер в котором происходит активная разработка. В определенный момент был начат бранч с новой независимой фичей, но от текущего мастера. Фича сделана и в принципе может быть внесена в стабильную ветку, но из-за того что она была начата на от стабильной ветки, при обычном мерже потянет за собой коммиты, которые не должны попасть в стабильную версию. На выручку приходит git rebase --onto, который позволяет создать ветку которая будет начинаться от стабильной версии и содержать все коммиты, которые были сделаны в ветке от мастера.
git rerere — позволяет записывать решение конфликтов и при повторном мерже использовать их. Помогает в случае если бранч живет долго и часто возникает необходимость мержится с другими бранчами. Включается просто: git config --global rerere.enabled 1
И git rebase --onto. Позволяет перенести ветку с одним основанием на другое. Когда полезно: Есть мастер в котором происходит активная разработка. В определенный момент был начат бранч с новой независимой фичей, но от текущего мастера. Фича сделана и в принципе может быть внесена в стабильную ветку, но из-за того что она была начата на от стабильной ветки, при обычном мерже потянет за собой коммиты, которые не должны попасть в стабильную версию. На выручку приходит git rebase --onto, который позволяет создать ветку которая будет начинаться от стабильной версии и содержать все коммиты, которые были сделаны в ветке от мастера.
Sign up to leave a comment.
ХХ полезных советов для пользователей Git среднего уровня. Часть 1