Github, позволяющий заменять свои изменения из функциональной ветви

Question

Поскольку мы используем gitHub в качестве лицензии для нашего проекта. у нас возникают проблемы с кодом, и из-за этого нас увольняют с работы наши клиенты.

Позвольте мне объяснить ........

Мы создаем ветку элементов из основной ветви, назовем ее «X» и «Y». Теперь «X» завершил работу перед «Y» и слил код в master. Теперь «Y» приходит и говорит, что я хочу объединить, потому что они также завершили разработку, но «Y» не имеет изменений, которые «X» сделал так, когда «Y» сливает код в master, github позволяет «Y» уничтожать » X "меняется без предупреждения или конфликта.

Это функция или ошибка github?

Answer 1

Прежде всего, это кажется маловероятным, если не было конфликтов на Github и , кто бы ни работал над Y, перебазировал / слил master и уничтожил все изменения X .

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

• Тесты, гарантирующие, что никто не вводит ошибки регрессии
• Запросы на извлечение не объединяются, если они не соответствуют основной ветке. Мы придерживаемся стратегии перебазирования, но вы также можете использовать стратегию слияния
• Если проекты тесно связаны, они сначала отправляются в эпическую ветвь, где их тщательно проверяют на соответствие требованиям с использованием автоматизированных инструментов, а также A / B-тестирование перед их объединением в мастер.

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

Answer 2

Я вижу две разные проблемы здесь:

Слияние удаленных работ

Это определенно не проблема для Github. Я видел подобные проблемы с людьми (включая меня), которые еще не были обучены правильному использованию Git.

Я настоятельно советую вам и всем членам вашей команды внимательно прочитать git book , по крайней мере, первые главы. Сначала это может вызвать у вас головную боль, как и у меня, но я действительно сразу почувствовал пользу.

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

Иметь рабочий процесс, который соответствует вашей команде и ситуации

Этот вопрос очень широкий. Вы можете прочитать это в качестве отправной точки.