I was recently working on a side project that seemed like it would have lots of large, binary assets. Unfortunately, that's just the sort of thing Git struggles with. While I was trying new things, I decided to also look at Azure Repos for Git hosting. Unfortunately, while Git works great for source control of code and other text files, it can be cumbersome for working with large binary files like audio or video samples. When you change a text file, Git only has to store the difference between the old and new file; for binary files, Git has to store the entire file again, even if only a single byte changed. For large, frequently changing files, that can bloat your repository making simple operations slow and cumbersome. That all happens seamlessly behind the scenes - when you checkout you see the actual binary files in your repository, they just aren't stored in the usual Git file structure. The two technologies aren't compatible as far as I can see. I decided to give Azure Repos a try. I describedso see that one for how to install git lfs started. Creating a new project with Azure Repos We'll start by creating a new project. Go tosign in with your Microsoft account and create a new project. I gave mine the imaginative name: TestRepo. When I created my project, only Azure Pipelines was enabled presumably as that's all I've used previously. Flick the switch, and Azure Repos is enabled for the project: After refreshing the page, you'll see the Azure Repos symbol appear on the left. The username is my organisation name andrewlocknot an install git lfs address I have install git lfs to. Nevertheless, I tried the password for my Microsoft account, but that didn't work. In order to push to your Azure Repos repository, you need to generate some new credentials. But watch out, it's a trap. Instead of setting a simple password to use with Git, you should use a personal access token. They're theso they should really make it more obvious: Personal access tokens let you create a password for use with the command install git lfs or other Git client without using your Azure DevOps Services username and password directly. An expiration date is set on these tokens when they are created and you can restrict the scope of the data they can access. Enter this value at the command prompt for git push -u origin --all and you'll be authenticated. If you're using Windows, Git-credential manager should take care of renewing and managing the token for you, so you shouldn't have to worry about authenticating again. First of all, I thought it might be to do withbut that had nothing to do with it. If you run git lfs install inside a Git repository as I didthen it also adds additional hooks. Object reference not set to an instance of an object. Object reference not set to an instance of an object. Total 643 delta 1reused 0 delta 0 remote: Analyzing objects. Note the fatal: NullReferenceException encountered. Not sure install git lfs that's about. It's not a big deal, was just interesting to notice. Exploring the files in Azure Repos If you navigate to your repository in Azure Repos, you can browse the files in your repo just as though they were committed directly. I was mostly just interested in the workflow and how it differs from normal git. With the exception of setting up the file paths to track, the answer seems to be - not much. One issue I ran into initially was failing to set up the tracking properly for some files by using the wrong combination of wildcards. I strongly recommend running git lfs ls-files after setting up the initial tracking to ensure you're actually tracking the files you think you are. Another way of checking this is to see what the files look like inside the. Another interesting feature for teams as opposed to solo developers is. Given that merge conflicts on binary files are a disaster, the centrally locked approach makes a lot of sense. Finally, I'd be remiss if I didn't mention. Unfortunately I only discovered this after muddling my way through, so I strongly recommend reading that first. I don't think I'll have much use for it personally, but I can certainly see the value for people working who like Git but are working with large binary files. As for Azure Repos, you can't really argue with free private repositories. If you're considering buying into the other Azure DevOps services too, then it makes even more sense to consider them. For open source projects though, GitHub is definitely still the way to go. Summary In this post I showed how to create a Git repository with Azure Repos and how to create git credentials for accessing your repo from the command line. I don't see myself having to use it often, but it's good to know it's there if I need it!.
