Синхронизируйте TFS и GIT

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

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

В любом случае, вы могли бы почти достичь того, чего хотите (это зависит от ваших ожиданий: нужна ли вам поддержка ветвления --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
• Постарайтесь убедить свое предприятие, что каждая команда должна выбирать и осваивать свои инструменты, а не навязывать какой-то выбор.

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

Таким образом, разумным подходом будет:

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

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

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

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

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

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

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

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