От ртутного до git - слияния?

Question

Я использовал mercurial в течение довольно долгого времени, и теперь я переключился на git, потому что моя новая команда использует его как средство контроля версий по умолчанию.

Позвольте мне объяснить - В Mercurial я клонировал проект от bitbucket, я внес некоторые изменения в проект. Затем я снова вытаскиваю битбакет и объединяю свои изменения со всем, что изменилось на битбакете. Тогда я все нажимаю.

Работает ли это с git? Я клонировал проект, внес некоторые изменения, сделал некоторые коммиты для них, теперь я вытащил проект, и я хочу объединиться. Эти предыдущие шаги работают нормально, но слияние немного отличается или, по крайней мере, оно выглядит по-другому. Как объединить мои коммиты с новыми коммитами, которые я только что вытащил из сервера?

PS: Как мои изменения, так и изменения на сервере были выполнены на главной ветке, я не собираюсь объединять 2 ветки.

Answer 1

Мое понимание этого, исходящее как человек Mercurial, заключается в том, что в Git все головы должны иметь уникальные имена. Следовательно, он не создаст нового руководителя, если вы не дадите ему новое имя. Так что в Mercurial вы могли бы сделать это:

hg pull /git pull 
hg commit/git commit 
hg commit/git commit 

----B----C1----C2 

Где B является базовой ревизией, первоначально тянула, и C1 и C2 ваши изменения. Затем вы извлекаете обновления с сервера.

hg pull 

----B----C1----C2 
    \ 
     ----o----o----o 

Git не будет делать этого, поскольку ему пришлось бы создать другую голову. Следовательно, вам необходимо перестроить или перенести свои изменения поверх серверов.

git pull --rebase 

----B----o----o----o----C1----C2 

---

Альтернатива когда вы начинаете свою работу в Git вы создаете имя для вашей головы. Git называет это ветвью, Hg называет ее закладкой.

hg pull /git pull 
hg bookmark/git branch 
hg commit /git commit 
hg commit /git commit 

----B----C1----C2 
       ^New-Feature 

Теперь голова имеет название («Новая функция» в данном случае). Теперь Гит с радостью потянет, как и Hg.

hg pull/git pull 

----B----C1----C2 
    \  ^New-Feature 
     ----o----o----o 

Вы также можете объединить то же самое.

Answer 2

git pull --rebase origin master 

Вставляет изменения и складывает локальные изменения сверху.

Однако создание ветвей практически для каждой новой функции - это необходимый рабочий процесс для Git, так что вы можете вообще узнать о них. Быстрое ветвление и слияние - это функция убийцы Гита.

Answer 3

Вы можете утверждать, что вы не собираетесь объединять две ветви, но в принципе вы находитесь.

Рассмотрите исходное состояние: У нас есть две головки, master и origin/master, которые оба указывают на фиксацию A. Затем кто-то добавляет коммиты B и C и нажимает на пульт origin, который вы fetch.Однако, прежде чем вы скачали, вы добавили совершает D, E и F к вашей master ветви, так что после fetch расположение DAG выглядит следующим образом:

A -> B -> C [origin/master] 
| 
\--> D -> E -> F [master] 

И вы хотите, чтобы подтолкнуть изменения в origin хранилище. Но ваши изменения явно конфликтуют с веткой origin/master, для этого вам придется объединить origin/master и master.

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

Таким образом, у вас есть два варианта:

• Объединить origin/master в master: git merge origin/master && git push origin master
• Rebase master на origin/master: git rebase origin/master && git push origin master

Оба из них могут быть объединены с git-fetch для создания git-pull, который автоматически будет использовать метод слияния, если вы не предоставите опцию --rebase, в в этом случае он выполняет вместо этого rebase.

Не забудьте быть осторожным при использовании --rebase из-за характера команды rebase.

Конечное состояние после того, как с помощью слияния:

A -> B -> C -----> G 
|     | 
\--> D -> E -> F ---- 

Окончательная состояние после того, как с помощью перебазирования:

A -> B -> C -> D -> E -> F 

Answer 4

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

hg pull просто получает новые изменения в местное репо и не влияет на вашу рабочую копию.

git pull получает новые фиксации и пытается автоматически объединить только что вытащенный HEAD с вашей местной HEAD. Если у вас были непредвиденные изменения, это может вызвать некоторые проблемы.

Решение: на данный момент, по крайней мере, всегда используйте git fetch. Это не влияет на вашу рабочую копию и позволяет делать слияния в свое время, например, с Mercurial. Другими словами, git fetch = hg pull.