Синхронизация TFS и GIT

Ответ 1

Невозможно синхронизировать 2 репозитория, раздельно автоматизировавшись на 100% с любым решением, которое вы выбираете (для достижения автоматической синхронизации вы должны либо быстро выполнить синхронизацию, либо заблокировать нажатие git или зарегистрироваться TFVC, когда одна из двух команд начинает синхронизацию).

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

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

Вам нужно клонировать ваш репозиторий TFS в репозитории bare:

git tfs clone https://server/tfs/TeamCollection $/project/trunk --bare --with-branches

тогда вам нужно записать в свой тэг post-receive этого репозитория bare что-то вроде этого (я не помню, если он работает):

branch=$(git rev-parse --symbolic --abbrev-ref $1)
if [ "master" == "$branch" ]; then
    branch="default" 
fi
git tfs rcheckin --bare -i $branch

При этом каждый раз, когда кто-то вводит репозиторий git, коммиты будут проверяться в TFS.

Для большего удобства (иначе они всегда будут иметь скучные конфликты, чтобы решить, когда они пытаются нажать), вы можете синхронизировать репозиторий git с сервером TFS с запланированной задачей с помощью команды (таким образом, они будут знать о новых коммитовских раньше):

git tfs fetch --all

Примечание. Я не помню, могла ли эта команда использоваться в репозитории bare (теперь, когда я думаю об этом, я так не думаю). В противном случае вам придется использовать вместо git tfs fetch -b=myGitBranch -i tfsRemote для каждой существующей ветки:(

Но я уверен, что они никогда не смогут работать с ветвями, которые еще не были созданы в tfs:( Инструмент git -tfs действительно не может автоматически создать ветвь TFVC из истории git. Технически, это возможно, но я не думаю, но никогда не развивал (потому что git -tfs - это больше, чтобы убежать от TFVC, чем инструмент для проверки вашего развития в нем...)

И некоторые другие вещи могут быть трудными или невозможными...

Надеюсь, это поможет.

PS:

• что трудная работа, которую вы пытаетесь сделать для кого-то, не используемого для git -tfs... и того, что я не рекомендую делать.
• Я настоятельно рекомендую идти тем же путем, что и Microsoft, и переносить все на git (даже при необходимости на сервере TFS или VSTS, если это необходимо), таким образом синхронизация будет намного проще (даже если не 100% автоматическая;-)). Я сделал хороший документ о том, как перейти от TFVC: https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/migrate_tfs_to_git.md
• Попробуйте убедить ваше предприятие в том, что каждая команда должна выбирать и осваивать свои инструменты, а не навязывать некоторые варианты.

Ответ 2

Основное изменение, с которым был задан этот вопрос (в четвертом квартале 2013 года), заключается в том, что TFS 2015/2017 теперь имеет официальную поддержку хранилищ Git. См. " Git и TFS".

Таким образом, разумный подход заключался бы в следующем:

• используйте инструмент git-tfs, чтобы экспортировать существующую историю проектов TFS в новый репозиторий Git.
• разделить, что Git repo в одну основную кодовую базу и несколько небольших репозиториев, каждая из которых представляет часть, которую вы хотите, чтобы другие участники получили доступ к
• ссылайтесь на те sub-repos как подмодули в основной кодовой базе
• наконец, создайте проекты TFS (на этот раз с помощью Git repos), чтобы отбросить эти репозитории на сервер TFS.

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

И в любое время; из основного coderepo repo вы можете обновить эти подмодули с помощью:

git submodule update --recursive --remote --rebase

(а затем протестируйте, добавьте, зафиксируйте и нажмите: ваше основное репо Git будет ссылаться на последние разработки из этих подмодулей)

Плюс, учитывая l--''''''---------'''''''''''' предыдущий вопрос, который поможет с одним репо с слишком большим количеством файлы.
Хотя для этого скоро будет (ish) GVFS.

Альтернативный подход, упомянутый l--''''''---------'''''''''''':

Я лично хочу иметь возможность использовать Git для своих собственных изменений, я бы имеют несколько наборов изменений в GIT, тогда я бы объединил их в один, и затем преобразуйте этот набор изменений в традиционный набор изменений TFS и проверьте что в этом случае у меня просто есть 1 регистрация на элемент TFS

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