Introduction

Pushing an existing local Git repository to Team Foundation Service is basically the same as pushing to any other remote Git server. The modern Microsoft product name is Azure DevOps Services, but the workflow is still: create an empty remote repository, add it as a remote, then push your local branches and tags.

Start With an Empty Remote Repository

The cleanest migration path is to create a new empty Git repository in Azure DevOps and avoid initializing it with conflicting content.

If the remote already contains a README or other initial commit, Git will treat the histories as unrelated, and your first push may be rejected unless you merge or force-push intentionally.

So the preferred sequence is:

• create the repo in Azure DevOps
• copy the HTTPS or SSH clone URL
• leave the repo empty if possible

Add the Azure DevOps Remote

Inside your existing local repository, add a new remote.

git remote add origin https://dev.azure.com/your-org/your-project/_git/your-repo
git remote -v

If you already use origin for another server, choose a different remote name such as azure.

git remote add azure https://dev.azure.com/your-org/your-project/_git/your-repo

The remote name does not matter technically. It is just a label in your local repo.

Push the Current Branch

If your current branch is the one you want as the main branch on the server, push it and set upstream tracking.

git push -u origin main

If your default branch is still named master, replace main with master.

The -u option tells Git to remember that this local branch tracks the remote branch, which makes later git push and git pull commands simpler.

Push All Branches and Tags

If you want the entire repository history, not just one branch, push all branches and tags.

git push --all origin
git push --tags origin

That migrates branch tips and annotated history references, but note that Git server settings, pull requests, permissions, and pipeline definitions do not come from Git history itself. Those must be recreated separately in Azure DevOps.

Authentication Options

Azure DevOps repositories can be accessed with HTTPS or SSH depending on your setup.

With HTTPS, Git may prompt you for credentials or rely on Git Credential Manager. With SSH, you need a registered public key.

If a push fails with authentication errors, verify:

• the remote URL is correct
• your Azure DevOps permissions allow pushing
• cached credentials are not stale
• the organization and project names match the URL exactly

What If the Remote Is Not Empty?

If the remote already has an initial commit, you have two main choices.

If that remote commit should be preserved, fetch it and merge or rebase intentionally.

git fetch origin
git log --oneline --graph --all

If the remote content is disposable and you really want your local repository to replace it, force-push carefully.

git push --force-with-lease origin main

Use that only when you are sure nobody depends on the remote history yet.

Verifying the Migration

After the push, check the remote in Azure DevOps:

• confirm the expected default branch exists
• verify tags if they matter to your release flow
• inspect a few commits to ensure history arrived intact
• set branch policies if the new repo will be used by a team

At this stage, your Git content is migrated, but collaboration settings still need review.

Common Pitfalls

The biggest mistake is pushing into a remote repository that already contains an initial commit and then being surprised by history conflicts.

Another mistake is assuming all metadata migrates with Git. Only repository history, branches, and tags move with git push.

A third issue is reusing the origin name when it already points somewhere else, which can lead to accidental pushes to the wrong server.

Finally, do not use plain --force unless you mean to overwrite remote history without safety checks. Prefer --force-with-lease when history rewriting is truly necessary.

Summary

• Create an empty Azure DevOps repository when possible.
• Add it as a remote with git remote add.
• Push the main branch with git push -u origin main or the equivalent branch name.
• Push all branches and tags if you want the full repository migrated.
• Handle authentication separately through HTTPS credentials or SSH keys.
• Be careful if the remote already has commits, because the first push may not be a simple fast-forward.