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

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

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

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

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

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

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

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

  • В SVN я реинтегрирую функциональную ветку:

    1. checking out (from the central repo) the develop branch (in the nomenclature of the Atlassian link) to a working copy
    2. Применение SVN-слияния изменений в ветке функций (в центральном репо) к моей рабочей копии ветки разработки
    3. Разрешение любых конфликтов слияния в моей локальной рабочей копии
    4. Передача моей рабочей копии в ветку разработки (опять же, в центральном репо)

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


git merge version-control svn git-merge-conflict
person kaltorak    schedule 27.10.2019    source источник
comment
Добро пожаловать в Stack Overflow. Пожалуйста, пройдите тур, а затем прочтите о том, что по теме, в справочный центр. В настоящее время этот вопрос слишком широк (пожалуйста, просто задавайте один вопрос на вопрос) и, вероятно, дублирует ряд существующих вопросов (пожалуйста, выполните поиск, прежде чем задавать). В целом, однако, похоже, что вам нужно пройти еще несколько руководств по Git. Есть много написанного для людей, пришедших из других систем контроля версий. Поищите в Интернете git для пользователей svn или аналогичные и переходите оттуда.   -  person Chris    schedule 28.10.2019

Ответы (2)


arrow_upward
0
arrow_downward

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

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

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

Используя git push

и как отскакивают конфликты слияния

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

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

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

Затем вы можете разрешить любые конфликты непосредственно из XCode.

person VonC    schedule 27.10.2019

arrow_upward
0
arrow_downward

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

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

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

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

    1. Change your process/setup so you don't need to, OR
    2. Получите вторую копию центрального (удаленного) репо. Затем вы можете проверить две разные ветки, поскольку copy1 и copy2 полностью независимы.

  4. Стандартный процесс интеграции ваших изменений в ветки main / develop / master зависит от вашей стратегии 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, это должна быть перемотка вперед).
  8. git checkout feature/branch1 (нет -b) переключитесь на ветку функций, чтобы подготовиться к слиянию.
  9. git merge develop - получать чужие изменения в свою ветку.
  10. git push - сделать так, чтобы удаленное репо содержало вашу ветку с объединенными изменениями из develop
  11. Now this is where things differ depending on if you use pull requests or not.
    1. If you use pull requests, which are not a git feature (they're on top of git) then you would create a pull request (via a web tool most likely, or maybe your IDE) and then someone would review your changes and merge them into develop - there should be no conflicts because your integrated develop to your branch recently.
    2. Если вы не используете пул-реквест, вы должны проверить develop, объединить свою ветку и отправить разработку в центральное репо.

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

person tymtam    schedule 27.10.2019