Нажатие изменений на основе старой фиксации, как ее решить?

Question

Я только что прошел все доступные упражнения по адресу http://learngitbranching.js.org/, и сейчас я чувствую себя очень уверенно. Я понял все это и сделал каждое упражнение, не думая слишком много. Очевидно, что это только упражнения для начинающих, и сейчас я просто начинающий Git, но мне было хорошо понять что-то. Теперь я могу правильно управлять версией своей работы, вместо того чтобы полагаться на копирование файлов рабочих версий.

Во всяком случае, у меня есть вопрос о слиянии обратно в пульт, который может ввести ошибку/

Рассмотрим такой сценарий:

Я проверить последнюю мастер ветвь на Remore репо в понедельник и ответвлении локально для работы над новой функцией. Эта функция, скажем, взаимодействует с некоторыми методами класса в пользовательском определенном классе,

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

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

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

Это обычное явление? Как это разрешено в производстве? Вам просто нужно устно общаться с вашей командой, когда какой-то класс изменился, и что любой, кто работает над функцией, связанной с этим классом, должен основывать свои функции на новом классе?

Answer 1

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

После того, как вы потянете и разрешите конфликты слияния (если есть), убедитесь, что функция работает. Выполнить тесты (у вас есть тесты, верно?). Нажмите, если вы уверены, что он работает.

Кроме того, из вашего вопроса неясно, сделаете ли вы это, но, как говорит VonC: вы не нажимаете на мастер. Вы нажимаете свою ветку на удаленное репо, а затем отправляете запрос Pull/Merge.

Это не проблема, если у вас есть какая-то промежуточная среда (то есть новые коммиты не идут непосредственно на производство). В этом случае, даже если вы что-то пропустите, у него есть второй шанс быть обнаруженным, когда кто-то нажимает на приложение при постановке.

Answer 2

Я предполагаю, что происходит в том, что, когда я тяну мои файлы будут обновлять с последней версией класса и методов внутри него

Что вы делаете это на самом деле:

git checkout yourBranch 
git fetch 
git rebase origin/master 

Это будет воспроизводиться yourBranch поверх обновленных origin/master.

Затем скомпилировать, проверить, все ли работает, запускать юнит-тесты, ....
И только тогда вы отодвигают свою ветку, и сделать запрос на нагрузочный (GitHub) или объединить запрос (GitLab) в порядке для запуска проверки кода и слияния с удаленной ветвью master.

Идея остается: тест локально, если ваш код все еще работает, а затем отбросьте назад и просмотрите обзор кода (запрос pull/merge): это то, где общение происходит естественным образом, посредством комментариев кода.

Answer 3

Это обычное явление? Как это разрешено в производстве? Вам просто нужно устно общаться с вашей командой, когда какой-то класс изменился, и что любой, кто работает над функцией, связанной с этим классом, должен основывать свои функции на новом классе?

Да, это распространено, поскольку это может звучать, и также это не git, который может что-то здесь сделать. Мы, разработчик, должны убедиться, что мы регулярно проверяем наш код (периодически, как hr или ежедневно).

Я считаю, что это то, что вы должны попробовать:

1. повар код и тестовый прогон
2. перебазироваться и запустить тест
3. отправить для рассмотрения перебазироваться и запустить тест
4. слияние освоить филиал и снова тест
5. развертывать на сервере dev и тестировать дым функции вместе с другими функциями, если это возможно
6. перепроверять на этапе испытания а затем подготовить для развертывания
7. развернуть подталкивать и быть счастливым