ну вобщем да, выше сказано
если не понятно, то вот пример:
1. забираем текущее дерево
2. создаём ветку experimental и что-то там правим
3. в это время в апстрим что-то закоммитили
4. чтобы всё гладко смерджилось, обновляем свой мастер, через rebase «освежаем» проделанную работу и тогда уже мерджим свои наработки в master.
Хаха, когда я был на первом курсе, смски были еще бесплатными (по крайней мере, у Билайна).
И я отлично помню, как мы собирали единомышленников и рассылали на случайные номера призывы не пользоваться смсками в день переключения этой услуги на платную основу.
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 были реальными паролем и хостом ^_^
Да, перед пушем на апстримный сервер надо сделать ребэйз, тем самым вы притворитесь, будто спушили всё, что можно, и свой коммит сделали с пылу с жару, основываясь на самом последнем коммите из апстрима.
Я держу пароли (точнее, конфиги с настоящими паролями) и прочие специализированные штуки в отдельном бранче. При добавлении в мастере каких-либо важных фич просто мерджу этот бранч с мастером.
Т.е. Вы делаете коммит origin_head+1, и хотите выложить его, даже если кто-то запушил своё вариант origin_head+1?
Вам поможет git rebase origin/master — после этого можете пушить свои изменения.
Я бы держал свои изменения в отдельном бранче, а в мастер держал бы синхронизированным с репо на сервере, но сути это не меняет.
Способствуют, не спорю. Никто не рождается сразу с багажом знаний. Но и читать каждый раз про «первым делом укажите своё имя и почту», хотя пришел искать приёмы черной магии, утомительно, согласитесь.
17К + винты (как минимум, 4х3К) — жаба уже не душит, а просто-таки устраивает поножовщину…
если не понятно, то вот пример:
1. забираем текущее дерево
2. создаём ветку experimental и что-то там правим
3. в это время в апстрим что-то закоммитили
4. чтобы всё гладко смерджилось, обновляем свой мастер, через rebase «освежаем» проделанную работу и тогда уже мерджим свои наработки в master.
Никак не могу заставить себя делать по-настоящему атомарные коммиты
Всегда интересовало — в каких случаях интерактивно, скажем, выборочно добавлять файл?
это --track!))
И я отлично помню, как мы собирали единомышленников и рассылали на случайные номера призывы не пользоваться смсками в день переключения этой услуги на платную основу.
Но, честно сказать, меня больше порадовало недавно примененная
$ 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 rebase origin/master — после этого можете пушить свои изменения.
Я бы держал свои изменения в отдельном бранче, а в мастер держал бы синхронизированным с репо на сервере, но сути это не меняет.
Так что только бдительность, бдительность и еще раз бдительность!
Тогда я тоже выпадаю так или иначе — уже есть cowon iaudio7, который менять не собираюсь)
А то под маркетологов подстраиваться идея плохая.
harvester.assembla.com/spaces/image_annotation/image_gallery/clVUzwZHOr3RCOeJe5afGb