Концепции коммитов и слияний в Git (для тех, кто понимает SVN)

Question

Я возился с разработкой для iOS и узнал, что Xcode теперь интегрируется с Git, а не с SVN. Так что теперь я забочусь об изучении основ Git.

Мне не особо нужен распределенный контроль версий - возможно, мне проще централизовать централизацию своего централизованного мозга. Но быстрый просмотр позже, я нашел это: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow Это здорово! Это тот рабочий процесс, к которому я привык!

Но, хотя он показывает мне команды, все еще есть некоторые основы распределенной природы Git, которые мне не хватает.

• В SVN я бы проверял N разных экземпляров (рабочих копий) источника, потому что, возможно, я работаю над более чем одной веткой функций одновременно.

• В Git ... я продолжаю слышать, что я клонирую хранилище . Как мне сопоставить эту идею с «У меня работает N экземпляров рабочей копии»?

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

• В Git ... я предполагаю, что я могу сделать коммит из моегорабочая копия в ветви функций в моем локальном репо, соответствует ли локальное репо центральному репо или нет? Как перенести мое изменение из локального репо в центральное репо и как отразить конфликты слияния (особенно, если изменение, которое уже зафиксировано в локальном репо, конфликтует с другим изменением, которое превратилось в центральное репо?)

• В SVN я реинтегрирую ветвь объекта путем:

  1. проверки (из центрального репо) ветки разработки (в номенклатуре ссылки Atlassian) нарабочая копия
  2. Применение слияния SVN изменений в ветви функций (в центральном репо) к моей рабочей копии ветви разработки
  3. Разрешение любых конфликтов слияния в моей локальной рабочей копии
  4. Отправка моей рабочей копии в разрабатываемую ветвь (опять же, в центральном репо)

• Как этот процесс выглядит в Git, особенно вокруг разрешения-слияниябиты?

Answer 1

В git вы делаете вещи иначе, чем в SVN, и если вы пытаетесь отразить свой SVN-процесс, вы можете плыть против течения.

1. Нормальный процесс в git должен иметь хранилище, которое является полной копией удаленного хранилища (локальные и центральные хранилища равны, когда речь идет о том, что они содержат) - это git clone.

2. git очень хорошо переключает ветки, и у вас есть одно проверенное рабочее дерево.

3. Если вам нужно одновременно извлекать 2 разные ветви, то:

   1. Измените процесс / настройку так, чтобы вам не нужно,ИЛИ
   2. Получить 2-ую копию центрального (удаленного) репо. Затем вы можете проверить две разные ветви, так как copy1 и copy2 являются полностью независимыми.

4. Стандартный процесс для интеграции ваших изменений в main / development /Основные ветки зависят от вашей стратегии git, и в подавляющем большинстве настроек они содержат шаги фиксации, нажатия, слияния. Есть также шаги запроса на извлечение.

---

Вот простой пример:

1. git clone - в большинстве случаев вы делаете это один раз. Теперь у вас есть репо, который ... ну ... клон центрального репо. Они равны: если кто-то потеряет центральное репо, ваша локальная копия будет иметь всю историю и ветви, которые были у центрального репо (если ваше локальное репо было обновлено, очевидно).
2. git checkout -b feature/branch1 - Создать филиал, в котором вы будете работать
3. Работа работать, работать
4. git commit
5. git push - теперь ваши изменения находятся в удаленном репо, и онибезопасно - если ваш компьютер умирает, он не потерян.
6. git checkout develop - переключитесь на целевую ветку, чтобы на следующих шагах мы могли перенести изменения, сделанные другими, в нашу ветку функций, чтобы увидеть, все лиработает вместе и разрешает любые конфликты.
7. git pull - получить изменения, сделанные в удаленном (центральном) репо, объединенном с вашей веткой разработки (это не должно иметь конфликтов, потому что вы не работали с веткой develop, это должно быть fast-forward ).
8. git checkout feature/branch1 (нет -b) переключиться на ветку функций, чтобы подготовиться к слиянию.
9. git merge develop - получить изменения других пользователейв вашу ветку.
10. git push - сделать так, чтобы удаленное хранилище содержало вашу ветку с объединенными изменениями из develop
11. Теперь все меняется в зависимости от того, используете вы запросы на включение или нет.
    1. Если вы используете pull-запросы, , которые не являются функцией git (они находятся поверх git) , тогда вы создадите pull-запрос (чаще всего через веб-инструмент). скорее всего, или, может быть, ваша IDE), а затем кто-то рассмотрит ваши изменения и объединит их с разработкой - не должно быть никаких конфликтов, потому что ваша интегрированная разработка в вашу ветку недавно.
    2. Если вы не используете запрос на извлечение, вам нужно оформить develop, объединить свою ветку и нажать развернуть к центральному репо.

Обратите вниманиеВы можете настроить некоторые из этих шагов, когда станете более опытными.

Answer 2

. Я продолжаю слышать, что клонирую хранилище. Как мне сопоставить эту идею с «У меня запущено N экземпляров рабочей копии»?

«N экземпляров рабочей копии» будет использовать команду git worktree : один клонированный репозиторий, несколько рабочих деревьев.

Как перенести мое изменение из локального репо в центральное репо,

С помощью git push

и как отразить конфликты слияния

Используя git pull, с правильной конфигурацией чтобы перебазировать ваши локальные коммиты поверх обновленной извлеченной ветки.

(сделать только один раз)

git config --global pull.rebase true
git config --global rebase.autoStash true

Вы можете разрешитьлюбые конфликты напрямую из XCode .