Как исправить и объединить это дерево git? - PullRequest
1 голос
/ 10 февраля 2012

Вот мой уловок (я думаю, что этот вопрос улучшился, спасибо @amber: Слияние коммитов из ветви в мастер -> странное дерево ):

Ветвь frontend - этоналево.Вы можете увидеть кончик master и remotes/origin/master в правом нижнем углу желтым цветом.

gitk --all git tree
Мне нужно сделать две вещи, которые я пережил около 36 часов неприятностей для:

  1. Как мне начать добавлять коммиты frontend к мастеру (сначала один за другим, добавляя задержку), чтобы я мог их толкнуть?Я не хочу объединять всю ветку, потому что в ней задействовано много кода, и в обеих ветках есть рабочие деревья, которые я не хотел бы беспокоить.
  2. Кажется, у меня два идентичных «Массовых обновления»записи вокруг frontend, верхний / левый без веток.Как можно избавиться от лишних веток bulk update наверху, чтобы было 2 чистых ветки?Мне бы хотелось, чтобы это выглядело так:

    |  # frontend
    |  # Bulk update.
    |  # ...commits...
    |  # move this frontend commit to master
    |  |  #master's changes
    |  |  #master, remotes/origin/master, remotes/staging/master
    

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

1 Ответ

0 голосов
/ 10 февраля 2012

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

  1. Оформить заказ и использовать git cherry-pick -e <sha>, где <sha> - ссылка на каждую регистрацию в frontend, которую вы хотите добавить к master. Таким образом, вы бы сначала использовали git cherry-pick -e <sha of 'adding delay'>. Вы можете выбрать вишню в любом порядке, в котором вы хотите, чтобы вы могли организовать нужные вам чекины от frontend в другом порядке до master. Смотри http://technosophos.com/content/git-cherry-picking-move-small-code-patches-across-branches.

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

    Сначала оформите frontend, а затем создайте новую ветку tmp (потому что вы не хотите фактически удалять интерфейс).

    Тогда сделайте git rebase -i --onto master master tmp. Это вызовет редактор для удаления и реорганизации проверок, которые будут отправлены после основной проверки, в любом порядке, который вы хотите видеть в своей ветке внешнего интерфейса.

    Когда вы закончите с этим, tmp будет там, где вы хотите, чтобы мастер, поэтому проверьте master и сделайте git reset --hard tmp и удалите ветвь tmp git branch -d tmp.

    Книга Pro Git содержит хорошую информацию о ребазе, но я применил эти концепции к вашему варианту использования. http://progit.org/book/ch3-6.html

  2. Сначала убедитесь, что перечисленные массовые изменения действительно являются дубликатами. Вы можете сделать git diff <sha of bulk1> <sha of bulk2>, чтобы увидеть различия. Если это то же самое или нет, ключом к удалению этого из списка является удаление вашего тайника, который вы в какой-то момент дали git. Если это не дубликат, убедитесь, что вы решили, что делать с различиями, прежде чем просто удалить тайник.

    Находясь в ветке, сделайте git stash pop, и если вы действительно не хотите, что вы сохранили в stash, сделайте git reset --hard HEAD. В этот момент, если вы перезапустите ваш gitk (обновление не будет показывать это), вы увидите, что эти записи в верхнем левом углу удалены. Ваш график gitk показывает, что тайник был проиндексирован с master, так что именно здесь я буду работать с stash, но вы лучше знаете, в какой ветке master или frontend, возможно, вы захотите работать с ним.

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

    @ У Джефроми есть более понятный подход к удалению тайника, если вам ничего от него не нужно, это не его точные слова, а то, что он предлагает:

    Используйте git stash clear, чтобы удалить все тайники. Вы можете использовать git stash drop stash@{n}, чтобы просто уронить его. Используйте git stash list, чтобы увидеть, каким должно быть n.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...