Это хороший подход для создания новой ветви без слияния текущей с использованием git?

Question

пожалуйста, сообщите мне об этом, например, у меня есть master ветка. Руководитель моей команды поставил мне задачу по содержанию условий. Поэтому я вытащил из мастера, а затем создал ветку от feature/terms-and-conditions до git checkout -b, а затем подтвердил, нажал. Только на минуту подумайте, что лидерство моей команды не слилось с master.

Теперь feature/terms-and-conditions на 1 коммит вперед от master. Так что здесь я запутался, что если бы я снова создал одну новую ветку для другой функции, предположим, что feature/user-list, а когда я сделаю коммит и pu sh, то будет две ветви. Оба будут на 1 коммит вперед от master. В таком случае будет какой-либо конфликт?

Answer 1

Вы описали, что, вероятно, лучший подход. Предполагая, что эти две функции не связаны, у вас должно быть две отдельные ветви, отделенные от главной, и работайте над ними независимо. Разделять feature/user-list от feature/terms-and-conditions - плохая идея, поскольку вы будете смешивать несвязанный контент в одной ветке и усложнять жизнь рецензента. Хуже того, каждый раз, когда вы получаете комментарии к ветке feature/terms-and-conditions, вам придется перебазировать ветку feature/user-list, что является большой работой. Ожидание слияния feature/terms-and-conditions перед началом работы на feature/user-list не является технически неправильным, но это слишком медленно, и я сомневаюсь, что с этим у вашего менеджера все будет в порядке.

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

Answer 2

Чтобы добавить к отличному ответу, предоставленному @ Mureinik

В git ветвь - это просто указатель на коммит, поэтому нет проблем с тем, чтобы поддерживать столько веток, сколько вы хотите, они "cheap".

Теперь, пока ветвь не объединена, она остается только вашей, так что вы можете вставлять в нее sh столько раз, сколько захотите, поэтому, когда feature/terms-and-conditions объединяется с мастером ( и, предполагая, что вы еще не слили ветку feature/user-list, вы можете перебазировать свои изменения поверх мастер-класса. Я обычно делаю (возможно, есть более «точные» команды, но это делает работу за меня):

// while being on feature/user-list branch
>> git fetch --all // to fetch the changes about the origin/master update into your local git repo
>> git status // just to make sure that you don't have any work in progress
>> git rebase origin/master  

Теперь последняя команда поместит все ваши локальные коммиты «поверх» последнего мастер-коммита. В этот момент у вас могут возникнуть конфликты, если вы работаете с одними и теми же файлами, но в целом это не должно произойти (так как было уже объяснено в отношении проекта, вы, вероятно, не будете делать два изменения, которые изменяют одни и те же файлы одновременно. Даже если будет конфликт, вы можете разрешить его.

После этого, если вы есть Вы уже отправили в удаленную ветку origin/feature/user-list, возможно, вы захотите принудительно создать sh новые sha1-ы ваших коммитов (git push -f), если вы еще ничего не добавили, вы просто можете продолжать работать.