Блог

Как неопытный пользователь git, я пытаюсь понять, зачем использовать новую ветвь в вашем локальном репозитории и объединить ее с master, когда изменения будут готовы. Правильно ли я предполагаю, что это особенно полезно, когда вы хотите переместить главную ветвь в удаленный репозиторий после завершения локальной работы и получаете сообщение о том, что ваша главная ветвь «устарела»? Другими словами:

1. git клонирует репозиторий на мою локальную машину
2. git ветвь new_branch
3. git проверка new_branch
4. после того, как я закончил свою работу в new_branch: git checkout master
5. git объединить new_branch
6. git нажимает на удаленное репо
7. Сообщение о том, что ваша работа позади, потому что кто-то другой внес изменения после того, как я клонировал репо
8. git pull; теперь мой местный главный филиал обновлен
9. git объединить new_branch
10. git нажимает на удаленное репо
11. когда все будет в порядке, я смогу удалить свою локальную новую ветвь

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

Надеюсь, это объяснено достаточно ясно.

Тх, Люк

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

Все дело в том, чтобы сохранить master в качестве стабильной основы для работы и снизить сложность, разделив отдельные вещи. Это может быть между вами и другими людьми или между вами и вами самими. Так много в программировании делается для того, чтобы не позволить вещам запутаться.

Что делать, если вдруг вам придется работать над ДВУМЯ вещами? Появляется ошибка, или ваш босс устанавливает новый приоритет, или вы понимаете, что ваша работа пошла бы намного легче, если бы вы сначала сделали что-то другое, или вы просто отвлеклись. Если вы взяли на себя обязательство освоить, все они должны быть переплетены вместе, что делает все более сложным и подверженным ошибкам. Если вы работаете в филиалах, вы переключаетесь между филиалами.

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

Если вы используете процесс проверки, вам часто придется ждать, пока будет рассмотрен набор изменений. Было бы хорошо иметь возможность приступить к выполнению следующей задачи. Если вы работали над master, вам придется работать поверх не просмотренного кода, который может измениться. Что делать, если в обзоре будут обнаружены проблемы? Теперь вы путаете исправления для первой задачи с незавершенной работой над второй.

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

Для получения более подробной информации об основах разветвленного процесса см. Рабочий процесс ветвления функций Git.

В вашем конкретном рабочем процессе есть недостаток. Вам не нужно возвращаться после того, как вы потянете.

• git ветвь new_branch
• git проверка new_branch
  • Это может быть объединено как git checkout -b new_branch
• после того, как я закончил свою работу в new_branch: git checkout master
• git объединить new_branch
• git нажимает на удаленное репо
• Сообщение о том, что ваша работа позади, потому что кто-то другой внес изменения после того, как я клонировал репо

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

На Github это запросы на вытягивание.

Слияние выполняется на «сервере», поэтому вы немедленно извлекаете нового мастера.

• git pull; теперь мой местный главный филиал обновлен
• git объединить new_branch

Это дополнительное слияние-главная ошибка. Ваша ветвь уже была локально объединена в master. git pull это не уничтожает это, оно объединяет удаленный мастер с вашим локальным мастером. Это включает в себя вашу объединенную ветвь.

• git нажимает на удаленное репо
• когда все будет в порядке, я смогу удалить свою локальную новую ветвь

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

Вот основной рабочий процесс соло.

• Работа.
• Обновить.
• Тест.
• Поглощать.
• Поделиться.

И более подробно.

• Работа.
  • функция git checkout -b
  • Делайте небольшие, целенаправленные коммиты, каждый из которых делает что-то одно.
• Обновить
  • Делайте это так часто, как вам хотелось бы, чтобы не отстать.
  • Мастер обновления
    • мастер проверки git
    • мерзавец тяни
  • Функция обновления
    • функция проверки git
    • мастер слияния git
• Тест
  • Тестируйте так часто, как вам нравится, возможно, больше, чем вам хотелось бы.
• Поглощать
  • Функция завершена, протестирована и обновлена.
  • мастер проверки git
  • функция слияния git
  • функция git branch -d
• Поделиться.
  • гит толчок

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

Это охватывает основы. Существует множество способов оптимизировать и улучшить этот рабочий процесс. Даже при работе в одиночку рассмотрите возможность использования запросов на вытягивание Github или их эквивалента в любой используемой вами системе.