Git тянуть ветку в том же локальном хранилище

Question

Как вытащить изменения из одной ветви в другую в том же локальном репозитории?

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

Answer 1

Я мог бы предпочесть обработать это полностью локально. Вы можете попробовать:

# from feature-child
git rebase feature-mother
git checkout feature-mother
git merge feature-child
git push origin feature-mother

Эта стратегия использует перебазирование для переноса ветки feature-child, где вы случайно выполнили всю работу, с последними изменениями feature-mother, по крайней мере, локально. Затем мы выполняем ускоренное слияние feature-child с feature-mother, чтобы перенести вашу работу в последнюю ветвь. Наконец, мы можем нажать feature-mother в хранилище, если это необходимо.

Answer 2

1. git pull = git fetch с последующим git merge (или другой командой Git).
2. git fetch означает получение коммитов из другого Git .
3. git merge означает объединить коммиты, которые у меня уже есть в моем хранилище .

Если у вас еще нет коммитов, вам нужен шаг 2. В вашем случае, у вас do есть коммиты, поэтому все, что вам нужно, это git merge (или другая команда, которую вы собираетесь запустить git pull в качестве второй из двух команд).

Давайте добавим к этому git push:

git push означает отправить коммиты другому Git . Это так же близко, как и к противоположности git fetch. Его противоположность: , а не git pull: git pull - это комбинация комбинация ;git push и git fetch являются двумя основными командами передачи-фиксации-из-одного-хранилища в другое.

Обратите внимание, что когда вы используете git fetch, вы получаете коммиты из их Git- другой Git, который обычно называется origin - и помещает их в свой репозиторий, но затем также label эти коммиты с именами, такими как origin/master и origin/feature. Эти метки, которые мы можем назвать имена для удаленного слежения , помнят, что их Git - тот, что на origin - использовал имя master или имя feature дляпомните эти конкретные коммиты.

Если git push отличается, то немного отличается тем, что после отправки новых коммитов в их хранилище, ваш Git просит их Git установить их ветка имен. То есть, если вы запускаете git push origin master, ваш Git отправляет своему Git любые новые коммиты, которые у вас есть, которые им не нужны (и что им нужно), а затем ваш Git говорит: теперь, когда у вас есть коммит a123456... - или независимо от того, какой у него хэш-идентификатор - теперь, когда у вас есть фиксация, установите ваш master, чтобы идентифицировать эту фиксацию. Имя удаленного отслеживания не задействовано:ваш Git говорит своему Git установить ответвления имён.

Всегда безопасно запускать git fetch. Он либо получает некоторые новые коммиты (и не затрагивает ни одну из ваших веток), либо не принимает ничего нового (и при этом не затрагивает ни одну из ваших ветвей).

Это другой Git решит, нравится ли ему ваш git push: вы отправляете его коммиты, если это необходимо, затем попросите его задать имена веток, что он и сделает, если они считают, что это безопасно,Вы можете отправить им команду - установить имена веток! - используя --force, чтобы переопределить ее, если они считают, что это небезопасно, и вы думаете, что знаете лучше, но разумно убедиться, что вы действительно знаете лучше, сначала.

Когда и насколько безопасно запускать git merge - это то, что вы должны решить самостоятельно. К сожалению, если вы используете git pull, вы решили, что это безопасно, независимо от того, что происходит на шаге git fetch. Иногда это все равно безопасно, особенно если вы также контролируете другой репозиторий Git, но я предпочитаю избегать git pull в целом. Я предпочитаю разбивать его на две составные части. Это дает мне возможность взглянуть на то, что на самом деле git fetch было извлечено, используя git log, прежде чем я решу полностью слить, перебазировать или что-то еще (возможно, даже принудительный толчок, хотя это было бы крайне редко).

Answer 3

Я поместил свои локальные изменения в ветку функции, которая содержит зависимый код для другой функции, для краткости я буду называть первую feature-mother, а последнюю - feature-child, то есть: git checkout feature-mother; git push. Затем я побежал:

git pull origin feature-mother:feature-child.

Это сработало для меня. Был ли необходим первый абзац, или есть способ получить изменения из локальной ветки, мне неизвестно.