Вопросы Теги

Git рабочий процесс и ребаз против вопросов слияния

Проблема заключается в том, что ’ декодирует символ Unicode U + 0092, UTF-8 C2 92, известный как ЧАСТНОЕ ИСПОЛЬЗОВАНИЕ ДВА: 

$ php test.php | xxd
0000000: 5374 616e c292 73                        Stan..s

Т.е., это не декодируется обычный апостроф.

html_entity_decode($string) работает, потому что он фактически не декодирует объект, поскольку целевая кодировка по умолчанию - латинская-1, которая не может представлять этот символ. Если вы указываете UTF-8 как целевую кодировку, объект фактически декодируется.

Целью этого объекта является кодировка Windows-1252: 

echo iconv('cp1252', 'UTF-8', html_entity_decode('Stan’s', ENT_QUOTES, 'cp1252'));

Stan’s

Цитирование Wikipedia :

Числовые ссылки всегда относятся к кодовым точкам Unicode, независимо от кодировки страницы. Запрещается использование числовых ссылок, которые ссылаются на постоянно неопределенные символы и управляющие символы, за исключением символов перевода строки, табуляции и возврата каретки. То есть символы в шестнадцатеричных диапазонах 00-08, 0B-0C, 0E-1F, 7F и 80-9F не могут использоваться в документе HTML, даже не по ссылке, поэтому ™, например, не допускается , Однако для обратной совместимости с ранними авторами HTML и браузерами, которые игнорировали это ограничение, необработанные символы и числовые ссылки на символы в диапазоне 80-9F интерпретируются некоторыми браузерами как представляющие символы, сопоставленные байтам 80-9F в кодировке Windows-1252.

blockquote>

Итак, вы имеете дело с устаревшими объектами HTML здесь, что, по-видимому, PHP не работает так же, как это делают «некоторые» браузеры. Вы можете проверить, находятся ли декодированные объекты в указанном выше диапазоне, что вы перекодируете / сокращаете их в Windows-1252, а затем конвертируете в UTF-8. Или попросите своих пользователей передать действительный HTML.

Эта функция должна обрабатывать как устаревшие, так и обычные объекты HTML: 

function legacy_html_entity_decode($str, $quotes = ENT_QUOTES, $charset = 'UTF-8') {
    return preg_replace_callback('/&#(\d+);/', function ($m) use ($quotes, $charset) {
        if (0x80 <= $m[1] && $m[1] <= 0x9F) {
            return iconv('cp1252', $charset, html_entity_decode($m[0], $quotes, 'cp1252'));
        }
        return html_entity_decode($m[0], $quotes, $charset);
    }, $str);
}

934
задан Micah 3 October 2018 в 16:10
поделиться

8 ответов

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

причина, почему переоснова тогда лучше, чем слияние, состоит в том что:

  • Вы переписываете свою локальную историю фиксации с той ведущего устройства (и затем повторно применяете Вашу работу, разрешая любой конфликт тогда)
  • , заключительное слияние, конечно, будет "ускоренной перемоткой вперед" один, потому что это будет иметь всю историю фиксации ведущего устройства только плюс Ваши изменения для повторного применения.

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

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

<час>

По той теме (переоснова тогда объединяют рабочий процесс), упоминания barraponto в комментариях два интересных сообщения, оба от randyfay.com :

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

(подобная техника существует для базара )

361
ответ дан Community 3 October 2018 в 16:10
поделиться
  • 1
    @GnrlBzik: Хорошая выгода! Это должно иметь var перед ним. – svinto 21 May 2013 в 18:05

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

  • , Ваши изменения очень легко рассмотреть
  • , можно продолжить вести себя любезно, маленькие фиксации, и все же можно обнародовать наборы тех фиксаций (путем слияния в ведущее устройство) внезапно
  • при рассмотрении общедоступного основного ответвления, Вы будете видеть различную серию фиксаций для различных функций различными разработчиками, но они не будут все смешаны

, можно все еще продолжить продвигать частное ответвление разработки в удаленный репозиторий ради резервного копирования, но другие не должны рассматривать это как "общедоступное" ответвление, так как Вы будете повторно базироваться. BTW, легкая команда для того, чтобы сделать это git push --mirror origin.

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

13
ответ дан Pat Notz 3 October 2018 в 16:10
поделиться

Так или иначе, я следовал за своим рабочим процессом на недавнем ответвлении, и когда я пытался объединить его назад с ведущим устройством, все это пошло к черту. Были тонны конфликтов с вещами, которые не должны были иметь значения. Конфликты просто не имели никакого смысла мне. Это взяло меня день для улаживания всего, и в конечном счете достигло высшей точки в принудительном нажатии удаленному ведущему устройству, так как у моего локального ведущего устройства есть все разрешенные конфликты, но удаленный все еще не был счастлив.

ни В Вашем партнере, ни в Ваши предложенные рабочие процессы должен Вы сталкиваться с конфликтами, которые не имели смысла. Даже если бы Вы имели, если Вы следуете за предложенными рабочими процессами тогда после разрешения, то 'принудительное' нажатие не должно требоваться. Это предполагает, что Вы на самом деле не объединили ответвление, к которому Вы продвигали, но должны были продвинуть ответвление, которое не было потомком удаленной подсказки.

я думаю, что необходимо посмотреть тщательно на то, что произошло. Кто-то еще мог иметь (сознательно, или не) перемотал удаленное основное ответвление между Вашим созданием локального ответвления и точкой, в которой Вы попытались объединить его назад в локальное ответвление?

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

12
ответ дан Peter Mortensen 3 October 2018 в 16:10
поделиться

С Мерзавцем нет никакого “correct” рабочего процесса. Используйте любые плавания Ваша лодка. Однако, если Вы постоянно получаете конфликты при слиянии ответвлений, возможно, необходимо ли скоординировать усилия лучше с поддерживающим разработчиком (разработчиками)? Кажется, что два из Вас продолжают редактировать те же файлы. Кроме того, не упустите пробел и ключевые слова подрывной деятельности (т.е. “$Id$” и другие).

2
ответ дан Bombe 3 October 2018 в 16:10
поделиться

DO NOT use git push origin --mirror UNDER ALMOST ANY CIRCUMSTANCE.

It does not ask if you're sure you want to do this, and you'd better be sure, because it will erase all of your remote branches that are not on your local box.

http://twitter.com/dysinger/status/1273652486

21
ответ дан 19 December 2019 в 20:21
поделиться

Я только использую переосновной рабочий процесс, потому что это визуально более ясно (не только в GitKraken, но также и в Intellij и в gitk, но я рекомендую первый больше всего): у Вас есть ответвление, оно происходит от ведущего устройства, и оно возвращается к ведущему устройству. Когда схема будет чистой и красивой, Вы будете знать, что ничто не идет к черту, никогда .

enter image description here

Мой рабочий процесс является почти тем же от Вашего, но только с одной небольшой разницей: Я squash фиксации в одну в моем локальном ответвлении прежде rebase мое ответвление на последние изменения на master, потому что:

rebase работы на основе [1 122] каждая фиксация

, который означает, если у Вас есть 15 фиксаций, изменяющих ту же строку как master, делает, необходимо ли проверить 15 раз, если Вы не давите, но что имеет значение, конечный результат, правильно?

Так, целый рабочий процесс:

  1. Контроль к master и получение по запросу, чтобы гарантировать, чтобы у Вас было последняя версия

  2. Оттуда, создайте новое ответвление

  3. , Делают Вашу работу там, можно свободно несколько раз фиксировать и продвинуть к удаленному, никаким заботам, потому что это Ваш ответвление.

  4. , Если кто-то говорит Вам, "эй, мой PR/MR утвержден, теперь он объединяется с ведущим устройством", можно выбрать их/получение по запросу их. Можно сделать это в любое время, или на шаге 6.

  5. После выполнения всей работы, фиксировать их, и , если Вы имеете несколько фиксаций, давите их (они - вся Ваша работа, и сколько раз Вы изменяете, строка кода не имеет значения; единственной важной вещью является окончательная версия). Продвиньте его или нет, это не имеет значения.

  6. Контроль к master, pull снова для обеспечения у Вас есть последнее master в локальном. Ваша схема должна быть подобна этому:

enter image description here

, Как Вы видите, Вы находитесь на своем локальном ответвлении, которое происходит из устаревшего состояния на [1 110], в то время как master (и локальный и удаленный) продвинулся с изменениями Вашего коллеги.

  1. Контроль назад к Вашему ответвлению и переоснове ведущему устройству. У Вас теперь будет одна фиксация только, таким образом, Вы решите конфликты только однажды . (И в GitKraken, только необходимо перетащить ответвление по [1 112] и выбрать "Rebase"; другая причина, почему мне нравится он.) После этого Вы будете похожи:

enter image description here

  1. Поэтому теперь, у Вас есть все изменения на последнем master, объединенный с изменениями на Вашем ответвлении. Можно теперь продвинуть к удаленному, и, если Вы продвинули прежде, необходимо будет вызвать нажатие; Мерзавец скажет Вам, что Вы не можете просто ускоренная перемотка вперед. Это нормально из-за переосновы, Вы изменили стартовую точку своего ответвления. Но Вы не должны бояться: используют силу, мудро . В конце удаленное также Ваше ответвление , таким образом, Вы не влияете master, даже если Вы делаете что-то не так.

  2. Создают PR/MR и ожидают, пока он не утвержден, таким образом master будет иметь Ваш вклад. Поздравляю! Таким образом, Вы можете теперь контроль к [1 116], вытягивать Ваши изменения и удалять Ваше локальное ответвление для чистки схемы. Удаленное ответвление должно быть удалено также, если это не сделано при слиянии его в ведущее устройство.

заключительная схема является чистой и четкой снова:

enter image description here

0
ответ дан 19 December 2019 в 20:21
поделиться

In my workflow, I rebase as much as possible (and I try to do it often. Not letting the discrepancies accumulate drastically reduces the amount and the severity of collisions between branches).

However, even in a mostly rebase-based workflow, there is a place for merges.

Recall that merge actually creates a node that has two parents. Now consider the following situation: I have two independent feature brances A and B, and now want to develop stuff on feature branch C which depends on both A and B, while A and B are getting reviewed.

What I do then, is the following:

  1. Create (and checkout) branch C on top of A.
  2. Merge it with B

Now branch C includes changes from both A and B, and I can continue developing on it. If I do any change to A, then I reconstruct the graph of branches in the following way:

  1. create branch T on the new top of A
  2. merge T with B
  3. rebase C onto T
  4. delete branch T

This way I can actually maintain arbitrary graphs of branches, but doing something more complex than the situation described above is already too complex, given that there is no automatic tool to do the rebasing when the parent changes.

31
ответ дан 19 December 2019 в 20:21
поделиться

После прочтения вашего объяснения у меня возник один вопрос: может быть, вы никогда не выполняли 

git checkout master
git pull origin
git checkout my_new_feature

перед тем, как выполнить «git rebase / merge master» в своей ветке функций?

Потому что ваша главная ветка не будет обновляться автоматически из репозитория вашего друга. Это необходимо сделать с помощью git pull origin . Т.е., может быть, вы всегда будете выполнять переустановку из неизменяемой локальной главной ветки? И затем наступает время отправки, вы отправляете в репозиторий, в котором есть (локальные) коммиты, которые вы никогда не видели, и, таким образом, отправка не выполняется.

14
ответ дан 19 December 2019 в 20:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: