Git - Как часто я должен получать последние изменения

Question

Как новичок в git, я понимаю основы, но мне неприятно, если мое изменение займет несколько дней.

Я бы начал с создания новой ветви branch-A и работал бы над ней, ноЯ слышал, что я должен получать последние изменения кода от удаленного ежедневно, по крайней мере, один раз в день, чтобы уменьшить вероятность конфликтов.

1. Как часто я должен получать изменения от удаленного в мой branch-A в то время какЯ на самом деле в той локальной ветке все еще занимаюсь кодированием?
2. И если я сам на своем локальном branch-A занимаюсь кодированием в течение нескольких дней, я должен делать ежедневные выборки / слияния с brach-A или с моим локальным master?

ОБНОВЛЕНИЕ

Полагаю, мне неясно, что мне нужно уточнить.

Предположим, я использую ветвь функций

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

Сказав это, я делаю это, поскольку это то, что я знаю (не уверен, что такое rebase, как я уже сказал, я новичок, но буду читать, хорошо):

Получить последние изменения и объединиться с разработкой

git fetch origin
git merge origin/develop

Создать новую ветку из только что обновленной ветви разработки

git checkout -b branch-A

Работайте и делайте постановку и совершение сегодня

git add.
git commit -m "my message"

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

Как мне это сделать?Должен ли я сделать это так

git fetch origin
git merge origin/branch-A

или вот так

git fetch origin
git merge origin/develop

Answer 1

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

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

IМожно сказать, что я делаю ребаз из основной ветки разработки почти раз в день, иногда чаще, но это опять-таки зависит от того, что я объяснил выше.

Технически, если ветка создается из 'master'(это основная ветка разработки), например:

git checkout -b my_branch

И тогда вы делаете коммиты:

git commit -am "some commit"
git commit -am "another commit"

Тогда ничего не стоит делать следующее:

git fetch --all
git rebase origin/master

В этом случае ваши коммиты будут «последними» в истории (хотя их sha1 изменится, что не является проблемой, поскольку это только ваша ветвь), и ваша ветвь также будет содержать последнюю чанges from master.

Относительно 2

Если вы один / работаете в очень маленькой команде - тогда, вероятно, вы всегда можете зафиксировать непосредственно в master и не использоватьветвления вообще, хотя это не рекомендуемый способ использования git.

Я могу сказать для себя, что я использую ветвь функций для одной функции, обычно она "живет" в течение 1-3 дней.И затем я объединяю его с мастером через механизм pull-request - я открываю запрос pull, члены моей команды проверяют и утверждают мои изменения, а затем я объединяюсь обратно.

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

Answer 2

Ответ

Предполагая, что вы в настоящее время на branch-A:

Легко понять

git commit -am "Make sure you save your pending changes" git checkout develop git pull # Or fetch merge like usual into develop git checkout branch-A # git merge origin/branch-A here if other people might also be working on branch-A. # It'll let you know that it's "Out of date" if other people changed branch-A git merge develop

Это самый очевидный способобновите вашу ветку.

Легко набрать

Это работает только в том случае, если вы не изменили свою локальную разработку, а объединение для извлечения - это просто быстрая перемотка вперед.Он сообщит вам, если вы не сможете выполнить ускоренную перемотку вперед.

git commit -am "Make sure you save your pending changes" git fetch origin develop:develop # Updates your local develop # git fetch origin branch-A:branch-A # If others will be working on your branch. git merge develop

Обратите внимание, что если вы забудете git fetch origin branch-A:branch-A здесь, он не даст вам знать, что выустарели, поскольку git fetch origin develop будет только извлекать разработку.

Даны предложения

Предложение 1

git fetch origin git merge origin/branch-A

Это, не 'на самом деле ничего не делать.origin / branch-A, вероятно, идентичен вашей локальной ветке-A.Если другие люди также работают над веткой-A, вы принимаете их обновления, что круто.Но вы никогда не касались разработки.

Предложение 2

git fetch origin # Make sure to git merge origin/branch-A here if other people are touching branch-A git merge origin/develop

Это прекрасно обновит вашу ветку-A, используя origin / development.Происхождение / разработка, вероятно, изменится в ваше отсутствие, поэтому это обновит вашу ветку.

Однако!Это сбивает с толку, потому что ваше местное развитие все еще устарело!Вы можете просто оставить это, и тогда в следующий раз, когда вы оформите разработку, она сообщит вам «устарела», и в этот момент вы можете также использовать git merge origin / development в development.

Однако выможет проверить другую ветку, а затем git merge develop, думая "Да, я только что обновил".Но вы не сделали, местное развитие было не синхронизировано.Вот почему это плохая практика.

Answer 3

Этот вопрос полностью зависит от того, сколько людей одновременно работают над одним и тем же фрагментом кода.Если вы работаете с новой функцией (т. Е. С новыми файлами), то работайте с ней в течение месяца и объединяйтесь, не сливаясь - вы все равно не будете конфликтовать.Если у вас есть три кодировщика, которые пытаются исправить две дюжины различных ошибок в одном файле, объединяйтесь каждые 30 минут.

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

Я определенно предлагаю ежедневное мастер-тягуОн дает вам хорошее представление обо всех внесенных изменениях, и если вы видите серию +/- в файлах, над которыми вы работаете, то вам лучше объединиться, так как это, вероятно, рефакторинг.Если в ваших файлах есть небольшие изменения, просто оставьте это в покое.