Ваша модель ветвления, по-видимому, требует указывать --no-ff при каждом слиянии, принудительно вводя учетные записи даже для пустых слияний - например, на вашем графике вы должны выполнить слияние от исправлений до 0.2, что делает эту фиксацию в основной ветке, а не на самом деле сделать любое слияние, с git merge --no-ff hotfixes. В проектах с административными требованиями, не поддерживающими git, это хороший способ сделать это. VonC ответил в случае, когда вы где-то пропустили требование --no-ff этой модели.
Для случая, когда вы следовали своей модели и просто не ожидали, что push будет вести себя так: если вы извлекаете мастер с версии 1.0 в репозитории с историей вашей графики и отправляете в главную ветку удаленного устройства, когда нажатие завершает удаленное будет иметь коммиты M2, M4, M5, Y1-6, G1-4, R1 и C1-3 (маркируя свои коммиты в соответствии с их цветом и вертикальной последовательностью), и удаленная ветка master будет ссылаться на все это.
Нужно понимать, что истории коммитов важны, а имена ссылок - нет, по крайней мере, не важны "заглавные буквы". git push
Обновляет удаленные ссылки, используя локальные ссылки, при этом отправляя объекты, необходимые для завершения заданных ссылок.
Обычно, если ваш репозиторий является частью основной разработки проекта, вы отслеживаете имена ссылок некоторых «центральных» репозиториев. Клон Git по умолчанию устанавливает для них локальные ветки remotes/origin/*; но другие настройки совсем не необычны, если у вас есть репо, в котором вы работаете над v2.1 какого-то проекта, вы можете рассматривать ветку выпуска v2.1 какого-либо другого репо как «главную» ветку вашего репо.
Если вы хотите отправить только результаты фиксации, не отправляя ее историю, вы должны сделать новую фиксацию, которая имеет результаты, но не имеет этой истории. Другие ДВС были построены людьми, которые относятся к построению истории таким образом с разной степенью отвращения; git считает такой выбор не своим делом: он предоставляет (именно так) инструменты, которые реализуют любую модель, которую вы хотите себе представить. git cherry-pick сделает новую фиксацию, сравнив именованную фиксацию с ее первым родителем, а затем применив эту разницу к текущей голове с сообщением выбранной фиксации. Vanilla git rebase выбирает целую последовательность таких коммитов. Поведение, которое, я думаю, вы ожидали, это то, что делает git merge --squash; git commit: применить различия в истории фиксации и забыть, откуда они взялись. Если вы сделаете это, в истории вашей ветки никогда не появится ни один коммит из другого места. Это определенно не та модель, которую пытается передать ваша графика.
person
jthill
schedule
24.03.2013
