Что мы делаем не так с git?

Question

3 из нас работают над проектом Django, используя git.

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

Мы все работаем с Windows, и мы не работаем с дисковыми ресурсами, поэтому у всех нас есть отдельные репозитории "origin" в наших индивидуальных учетных записях на linux box. Они служат для того, чтобы мы могли делиться своими изменениями друг с другом, а также как «резервная» резервная копия наших репозиториев.

Один из двух других людей создает ветку, назовем ее BugA, и они исправляют ошибки. Затем они переносят его со своей рабочей машины на машину с Linux, к которой у всех нас есть доступ, чтобы я мог просмотреть изменения и объединить их с «мастером» в моей учетной записи (который считается копией кода, отправляемого в производство).

Как только они закончат BugA, они начнут BugB с новой ветки. Когда я проверяю их работу, я обнаруживаю некоторые проблемы (лишний код, отсутствующие комментарии и т. Д.). Поэтому я внесу изменения в их код, протестирую его и передам мастеру.

Затем они присылают мне исправления для BugB, и я получаю всевозможные конфликты с их изменениями. Эти конфликты находятся в строках кода, который я изменил в их коммите.

Когда они пытаются слиться со мной, они также сообщают о конфликтах с их стороны.

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

Что я не уверен, так это что с этим делать. Как только они сливаются со своей веткой из моего репо, тогда они должны слиться с моим хозяином? 2 слияния вместо 1?

Из-за того, что у нас есть linux-репозиторий с внешним размещением, что означает удвоение толчков, удвоение слияний и т. Д ....

Неужели так и должно быть?

Answer 1

Насколько я понимаю ваш вопрос, у вас есть три удаленных репозитория ("происхождение"), где все происходит:

• ваше репо (с кодом производства) repo_mark
• репо пользователя1 repo_user1
• репо пользователя2 repo_user2

И сценарий таков:

• user1 создает ветку исправления ошибок (BugA) и делает некоторые исправления
• затем он добавляет изменения к repo_user1 (его происхождение) с git push origin BugA:BugA
• затем вы извлекаете изменения, выполняя git fetch repo_user1 и объединяете ветку BugA (включая некоторые изменения, которые вам пришлось сделать) в master из вашего origin (который считается быть мировым главным репо)

Чтобы все было согласованно, вам не нужно работать с тремя репозиториями; используйте только один . Рекомендация будет такова: только вам разрешено переходить на repo_mark/master, в то время как ваши коллеги могут передавать в филиалы Bugfix в этом репо.

Итак, user1 не толкает ветку BugA к своему источнику (которого не существует), но к repo_mark/BugA.

Как только вы внесете изменения BugA в repo_mark/master (что считается THE репо), вы сообщаете своим двум коллегам обновить их рабочие копии (то есть выполните git fetch origin где origin - это repo_mark), за которым следует

git checkout master
git rebase origin/master

Теперь все вы трое разделяете одну ветку master. И & ndash; Вы упомянули резервную копию в своем вопросе & ndash; у каждого пользователя, который fetch ed, есть полная резервная копия вашего repo_mark сейчас.

Это было бы подходящее время для удаления BugA в repo_mark, указав git

git push origin :BugA

и user1, чтобы удалить его локальную ветвь BugA.

Если в это время началась работа для BugB, пользователь, работающий с BugB, выполняет

git checkout BugB
git rebase master

после того, как вы сказали ему обновить. Могут возникнуть некоторые конфликты, но это не обязательно.

Если конфликты будут разрешены, он может продолжить работу над BugB и, наконец, перенести работу на repo_mark/BugB.

---

Редактировать: Ответы на git - главная ветка блокировки для некоторых пользователей? покажет вам, как заблокировать master для ваших коллег.

---

Редактировать 2: Конечно, вы можете сохранить два других репозитория, чтобы ваши коллеги могли создавать резервные копии своей работы: они push в эти репозитории, пока их работа не будет готова для передачи вам, а затем push до repo_mark. Но в этом случае они будут нести ответственность за синхронизацию своего репо с вашим, и в этом случае вы должны быть в ловушке.

Answer 2

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

Если это не так, как выЯ изменял их коммиты, это означает, что в вашем рабочем процессе есть что-то еще, что я пропускаю.Дайте мне знать, и я посмотрю, что еще я могу придумать.