Свежие комментарии

Title	Comment
Я смотрел, что это за ветки,	Я смотрел, что это за ветки, я не пойму - где они? локально или в центральном repo? сколько в центральном repo всего веток, какое их предназначение..
В mastere будут merge	В mastere будут merge commity. Ну посмотри на картинку. при чем тут бранчи я не понял.
для git это также	для git это также справедливо. про git-svn сказал, чтобы подчеркнуть. Если вы будете пушить только master, ваши локальные ветки будут только у вас, как бы rtfm
Аааа, речь все еще об	Аааа, речь все еще об git-svn? Я думал мы уже просто про гит говорим :)
Это, как справедливо написано	Это, как справедливо написано в мануале, bad idea в тому случае если ребэйз делается с коммитами которые уже лежат на сервере. Для локальных коммитов таких проблем нет. Уже два года ребейзим всем маемо, и никаких проблем. Я пожалуй не смогу толково рассказать про ту проблему потому как мы сразу запрещаем использовать merge и толком словить проблемы с конфликтами не удалось, но предположительно это случается в том случае когда первый чувак делает ветку скажем сегодня, работает 3 дня и мержит с конфликтами которые решает, второй чувак делает ветка завтра, и мержит через неделю. Так вот есть мысль, что ему прийдется иметь дело с конфликтами которые решил первый чувак. Но это предположение. На практике это выглядит так что ты ребейзишь свою ветку (например что бы работать с последними комитами с мастера) а тут вылезают конфликты файлов которые ты не трогал. А и еще, если откатываешь мерж, то в некоторых случаях можно поиметь кучу проблем, с обычными коммитами такого не будет. Впрочем напрячься нужно будет всегда Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent. Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.
мы видимо о разном говорим. У	мы видимо о разном говорим. У меня вообще, в удалённом repo, только одна ветка - trunk, это вообще svn. Там всё линейно, хотя и merge'у у себя ветки. Пушить локальные ветки никто не заставляет. Нужна линейная история в локальном repo, смотрите только на стволовые ветки. Если напрягают feature ветки в локальном repo, сделайте ещё один локальный. один из них будет чистовой, только со стволовыми ветками, другой со скелетами в шкафу, тут это уже обсуждалось.
Ну граф истории будет	Ну граф истории будет напоминать вот такой http://www.viget.com/uploads/image/merge_commits.jpg если работаешь один или вдвоем. Если людей поболе то конечно и проблем с этим будет поболе :)
Пример про тарелки имхо	Пример про тарелки имхо как-то не очевиден. Можно воспринимать это так: после pull'а, последний коммит в ветке, у вас в локальном репозитории и в удаёлнном, один и тот же. И у вас и у сервера, после этого коммита, может быть бурная разработка, из-за чего ваши пути расходятся, то есть origin/master это отдельная ветка, и master это тоже отдельная ветка. то есть это уже разные ветки, с общим предком. После pull'а, в общем случае вы ответвляетесь от удалённой ветки. То есть rule of thumb - сделали pull, начали работу - значит вы уже отбранчевались от удалённого repo. Когда вы хотите поделится с удалённым репозиторием своими изменениями, основными вариантами являются: 1. смерджить вашу ветку и удалённую. то есть merge 2. взять вашу ветку за то место, в котором произошло разветвление, отрезать в этом месте и прилипить к голове удалённой ветки. то есть rebase
К тому же там получается	К тому же там получается засада с теми мержами в которых были конфликты и которые твои коллеги успешно решили но посколько использовали merge то в некоторых случаях при rebase тебе прейдется делать то что делали они. я вот этой ситуации не понял. но если это про rebase в общем репозитории, то это как бы bad idea. про это даже в http://kernel.org/pub/software/scm/git/docs/git-rebase.html написано: "Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. "
разобрался, сконвертил	разобрался, сконвертил (проблемка крылась в запретах винды) Имеется теперь карта jnx , только QLandkarteGT.1.2.2 не видит мой орегон 550-й, ставил и нмея и посл.порт...прога не показывает модель моего навигатора. А просто тоталом скопировал карту в память прибора, в папку Castom Maps -прибор не видит ее. Навигатор пропатчил, почему не видим навигатор - не пойму (( может какой другой прогой загрузить в прибор:
ээ, я какбы говорил о том,	ээ, я какбы говорил о том, что в master, от всей моей бурной работы в ветке feature, отразится только один merge-commit
Когда 20 обезъян тащут в	Когда 20 обезъян тащут в главную ветку миллион своих коммитов, получается свалка. И есть очень даже большой смысл это все чистить. Полезность информации о нескольких патчах сомнительна. К тому же там получается засада с теми мержами в которых были конфликты и которые твои коллеги успешно решили но посколько использовали merge то в некоторых случаях при rebase тебе прейдется делать то что делали они. Вообщем геморрой один.
Я вот когда начал git	Я вот когда начал git изучать, сначала искал QuickRefernce, типа основные команды посмотреть - ничего доступного для бысторого вьезжания сходу не нашёл. Потом начал смотреть краткие статьи с описанием - то что я видел, всё написано сумбурно и полно горячей мочи от восторгов. Особенно умиляют советы типа, для лучшего понимания нужно изучить структуру данных git'а - вот это вообще пипец. Далее нашёл какое-то руководство(может даже с kernel.org, но могу ошибаться - читал с телефона) - там те же саки. В итоге набрёл на вменяемое руководство-книгу Pro Git, которая есть и на русском, на английском, и на других языках. Вот собственно - http://progit.org/book/ru/ , первых трёх глав должно хватить для начала. Конкретно про rebase - http://progit.org/book/ru/ch3-6.html . Есть описание ещё тут http://kernel.org/pub/software/scm/git/docs/git-rebase.html , особенно иллюстративен пример где есть master, next, topic: изначально: `o---o---o---o---o master \ o--o--o--o--o next \ o---o---o topic` делаем git rebase --onto master next topic, получаем: `o---o---o---o---o master \| \ \| o'--o'--o' topic \ o--o--o--o--o next` ----- Для сплющивания нескольких коммитов, в один, я rebase не использую, так как считаю идеологически неверным - зачем терять инфу? merge сделает тоже самое сплющивание, да ещё и сама цепочка коммитов останется. rebase я использую в следующем контексте: - есть проект - перед непосредственно работой, нужно выполнить некоторые настройки системы автосборки - для этого я завёл отдельную ветку - BuildConf (можно вынести все файлы настройки в не версифицируемую область, то есть как советует svn иметь conf.template, и каждый разрабочик копирует в сonf, и правит уже его. но зато так, я получу историю своей настройки сборки проекта) - feature-ветки я ответвляю от BuildConf - когда feature ветка готова, и должна смёржится в master, я её снимаю с головы BuildConf и сажаю на master (то есть rebase), а потом мёржу в master (с опцией -no-ff, чтобы всегда merge'ем был один коммит). Это для того, чтобы настройки BuildConf не попали в master. - после merge'а feature, master ушёл вперёд от разветвления с BuildConf, если для работы над следующей feature в рабочем дереве должны быть изменения от предыдущей feature, то просто пересаживаю BuildConf на голову master (то есть опять rebase). - если во время работы над очередной фишкой, нужно поменять конфигурацию сборки, то есть сделать в неё коммит с изменениями, то feature пересаживается на новую голову BuildConf (опять rebase)
Представь, что у тебя в руках	Представь, что у тебя в руках стопка тарелок, и на сервере (origin) стопка тарелок. git rebase origin/master - значит что стопка на сервера берется за основание и пытается привести к тому виду которое у тебя на руках. То есть после этой операции ты имеешь origin/master + delta, где дельта твои коммиты (если предположим, что коммитил ты один). После этой операции можно спокойно пушать. rebase также убирает ненужные коммиты типа merge commit. Я например обхожусь без мержа. git checkout -b featureBv2 git commit git push origin featureBv2:master если кто то до меня пушнул нужно сделать так: git fetch origin git rebase origin/master - это приведет к тому что мой коммит "всплывет" в истории наверх даже если был сделать до последних изменений в мастере git push origin featureBv2:master
> Ну и нафига 20 коммитов	> Ну и нафига 20 коммитов тащить в общий репозиторий, если их можно rebase -i в один Извиняюсь, что встреваю. Но может хоть здесь пошлют в правильном направлении. Везде пишут про rebase. Вот сколько не пытался понять rebase столько у меня и не получалось. Все время он меня пугает и устает. Где бы для солдат и матросов про него прочитать? Манил, гоглил. Понял, что тупой. В результате пришел к другому, чуть более для меня понятному: git checkout -b featureBv2 origin/master git merge --no-commit --squash featureB поправили конфликты, еше чего то сделали git commit А далее уже push или чего еще. Интересно это просто еще один способ достигнуть желаемого результата или чтото в нем есть глубоко порочное?
Мой опыт состоит в том, что в	Мой опыт состоит в том, что в архив приходится ходить черезвычайно редко. Ближе к никогда. Я тоже думаю что хрен когда полезу в архив, но пока терять такую возможность не хочется - тем более это не трудно (точнее даже легче для меня - переносить всё в архив, это ведь дополнительные телодвижения). Может лет через пять и не буду всё хранить, но как обычно бывает - как только перестану, обязательно понадобится что-то архивное.
Выше - ветка комментариев,	Выше - ветка комментариев, где мы обсуждали с таким же страдальцем: http://blog.lexa.ru/2011/05/12/o_rastre_v_gps_howto.html#comment-18187 Повторять ее еще раз мне бы не хотелось.....
Да, и про удаление	Да, и про удаление (объединение) коммитов и про удаление нахрен неудачных форм эволюции. Если эти формы в чем-то могут быть интересны - в архив их. И забыть навсегда: возвраты к экспериментальному коду годовалой давности если и бывают, то единичные. Мой опыт состоит в том, что в архив приходится ходить черезвычайно редко. Ближе к никогда.
Прошу простить, но все же не	Прошу простить, но все же не поюму. Установил FWTools в папку bin закинул map2jnx (читал где то что так можно сконвертить) На компе просматривать не буду, сразу в прибор загружу а там и гляну. Только как сконвертить я так и не понял ((
- пространство бранчей должно	- пространство бранчей должно быть обозримым. Т.е. это максимум - экран (24 строки), а оптимум вообще меньше десятка (5-8). Я не говорю, что не нужно удалять смерженные бранчи. Их можно спокойно удалять (git branch -d (именно маленькая d - для смёрженных бранчей)) - "мелкие" коммиты из бранчи останутся, а сама бранч нет (как я понял, чтобы всё-таки увидеть её, надо лезть в reflog). Или вы говорите про удаление так же самих коммитов ветки? - то же самое с тегами. На счёт тэгов - это да. По-идеи в моём подходе, надо тэг-ать некоторые коммиты feature-веток. Можно конечно придумать таким тэгам разные префиксы и фильтровать их при выводе - но понятно, кому как нравиться.. кому-то фильтровать тэги, кому-то держать их в отдельном репозитории.
Не, я вот лично считаю, что	Не, я вот лично считаю, что на моем рабочем месте - пространство бранчей должно быть обозримым. Т.е. это максимум - экран (24 строки), а оптимум вообще меньше десятка (5-8). - то же самое с тегами. А если мне понадобится тестовый код, написанный в прошлом году (допускаю, что может, хотя я скорее всего про него забуду раньше) - я согласен потратить несколько минут на его поиски, настолько редко это нужно на самом деле. А вот в регулярном списке тегов мне этого не надо.
О рентабельности имеет смысл	О рентабельности имеет смысл говорить, если показана не только расходная часть, но и доходная.
вы не учитываете: - стоимость	вы не учитываете: - стоимость проявки (+3~8$) - стоимость камеры – пленка: 1-2К$ в 5-8 лет, цифра: 2.5-5К$ в 2-3 года. и я не говорю о таких вещях как off-line архив на жестких дисках стоимостью 120$ за терабайт (с учетом 2х избыточности и резервные винты) в итоге получается что процесс в его оптимальном варианте, с учетом инфляции не сильно изменился в цене, а ваш вариант с флешками (пока) не рентабелен ;)
Я согласен, что рабочее место	Я согласен, что рабочее место должно быть прибрано - хоть и пришёл к этому опытным путём. Когда реально видишь результаты этой аккуратности, начинаешь особенно её ценить. Но заводить отдельный репоизторий для мелких коммитов не считаю необходимым. Мелкие feature/topic-branch'и мерджатся одним коммитом в стволовые ветки - и после не мешаются. Если же речь идёт о том, что в перспективе локальный репозиторий может использоваться ещё кем-то (всмысле с него будут fetch'ить), то да, скелетов можно спрятать в шкаф. Только я бы работал в шкафу (опять же, я не думаю что мелкие topic-ветки будут хоть как-то мешать), и из него пушил бы в чистовой локальный, а из него в удалённый. кстати, вот эти чуваки кричат что наоборот, не надо прятать скелетов - http://www.youtube.com/watch?v=0SARbwvhupQ .
Ну то есть вы считаете, что	Ну то есть вы считаете, что надо все хранить, на всякий случай, а я предпочитаю только чистовые варианты. Ну так заведите репозиторий "всякая хрень" и push-те туда все свои бранчи, проблем то. А в рабочем (и, особенно, общекомпанейском т.е. "центральном") держите только чистовые варианты. На мой личный взгляд, на рабочем месте должно быть относительно прибрано, а какие скелеты живут в шкафу - неважно.
Во, git log -g то чего мне не	Во, git log -g то чего мне не хватало - значит парой минусов меньше
Не, это понятно. Я вот только	Не, это понятно. Я вот только вместо rebase, merge'у в ветку, которая потом пушится в удалённую. Главное --no-ff написать, тогда в 'общей' ветке будет один merge-commit, а не перемотка(когда возможно). Потому как тому, кто будет с этими коммитами потом разбираться вдруг, ему тоже один большой коммит удобнее десятка мелких. Я предпочитаю иметь и то, и то. Пусть даже серию мелких коммитов только локально. Вот накодил что-то - закомитил, показалось дико убогим - удалил, сделал коммит, переписал - закомитил, смёржил с "общей" веткой. Через год внезапно то, что казалось убогим, захотелось снова поковырять - ихмо это один из тех пунктов, для которых vcs и предназначенно..
Ну вот я в мастере говорю git	Ну вот я в мастере говорю git merge vendor-branch и импортируются только те изменения, которые были с прошлого merge. Ну правильно, вы ведь ветку vendor-branch не удаляете - а кладёте следующую версию dcraw.c в ту же vendor-branch. Когда вы вливаете одну ветку в другую, даже с удалением вливаемой(это не касается вашего примера) - коммиты ведь остаются из обоих веток. А вот история о том, что вот этот коммит когда-то принадлежал ветке feature - нет. И вообще, после того как master пойдет дальше слияния, различить какая из веток коммитов была master - нельзя. И после этого ветка feature нафиг не нужна. я знаю что-такое topic/feature-branch, сам недавно начал их использовать. Я не говорю, чтобы после удаления ветки, она была видна в git branch. Пусть будет видна в через специальную архивную команду. Вот мне через год будет интересно, как именно я игрался с ветками - это же VCS. Вот сделал копию одного репозитория, грохнул master (предварительно создав ветку, на самом первом коммите) - размер не изменился.. игрался с git gc - размер не изменился.. погуглил - нашёл http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html То есть вроде инфа всё-таки хранится, что уже хорошо. Вот только перепробовал уже кучу команд - а грохнуть размер не получается :)
Да, и то же самое касается	Да, и то же самое касается линейной разработки в локальном репозитории. Допустим, я feature фигачу прямо у себя, локально. Но коммичу часто, сначала недоделанное, потом баги правлю, потом опечатки в документации, потом выясняется что тесты не проходят - и еще правлю. Ну и нафига 20 коммитов тащить в общий репозиторий, если их можно rebase -i в один ("добавлена, протестирована и документирована фича 8") и уже в виде одного коммита push-ить. Потому как тому, кто будет с этими коммитами потом разбираться вдруг, ему тоже один большой коммит удобнее десятка мелких.
Про последовательные merge на	Про последовательные merge на примере libraw: - есть ветка master где разработка на основе dcraw.c (откуда используется много кода, но сильно попатченного) - есть ветка vendor-branch, куда кладется оригинальный dcraw.c (раз в несколько месяцев выходит новая версия). Ну вот я в мастере говорю git merge vendor-branch и импортируются только те изменения, которые были с прошлого merge. Касаемо хранения всей истории: git предполагает, что ветки создаются легко, дешево и на каждый чих (merge отличный, почему бы нет). Если бы их нельзя было бы удалять, у меня их были бы уже десятки, если не сотни. Ну а нахрена они мне, если стандартный паттерн предполагается такой: git branch feature git checkout feature подевелопили, потестировали - работает git commit && git checkout master && git merge feature И после этого ветка feature нафиг не нужна. А отбранчевание (дешевое) нужно, чтобы на момент разработки feature, когда все разобрано и поломано - ветка master оставалась бы рабочей.

Свежие комментарии

Pages