Ever had the issue where your Git repo has a branch that your local hasn't picked up on? This can often happen when a branch has just been created.

The solution is simple just run...

f your using Team Development for Sitecore (TDS) and Github or Git as your source control you may experience an issue where TDS is unable to create/update some of the items in Sitecore, due to a content length issue.

The error will look something like this:

Failed to load version 1 for language en
Length of field content does not match the content-length attribute. File name: name, field id: {id}

What's happening comes down to how Github encodes line ending. If your item contains a Rich Text field you can end up with data that has been serialized with both CRLF and LF as the line feed. This will have been included in the content length. However when you push to Git, the CRLF value will have been removed making the content length value incorrect.

To overcome this issue you need to update your .gitattributes file to treat these files differently. Just add this to your file:

# TDS files should be treated as binary
*.item -text

How do I create a .gitattributes file?

If you don't have a .gitattributes file you may run into an issue with windows where it won't let you create it, due to requiring a file-name rather than just an extension.

To create the file:

1. Create the text file gitattributes.txt
2. Open it in a text editor and add your rules, then save and close
3. Hold SHIFT, right click the folder you're in, then select Open command window here
4. Then rename the file in the command line, with ren gitiattributes.txt .gitattributes

This is one of those great examples of writing a blog post to yourself to remind you how to do something.

If your using Visual Studio 2012 then to add Git support you will need the Visual Studio Tools for Git plugin created by Microsoft's TFS Power Tools Team (http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c), if your using a later version of Visual Studio then it's already built in.

If you're thinking in of using Git Hub as your source control provider then the most basic thing you're going to need to know is how do you get the Git plugin to link up to GitHub. Here's a couple of different methods;

Creating a Project in Git Hub

Click New Repository. Enter a new, Select Public or Private and click Create new Repository.

A new repository will be created in Git Hub

Clone the Project in Visual Studio

Now the project has been created in Git Hub you will need to clone it to your machine so that you can start adding files and sync then back.

Open a new instance of Visual Studio and do the following:

1. Open the Team Explorer window
2. Click the connect button
3. In the list of Local Git Repositories click clone
4. In the URL box enter the HTTP URL from Git Hub
5. The second box should auto populate with a location on your hard disk
6. Click Clone

Creating a Repository on Git Hub using the Git Hub app

Rather than creating the Git Hub repo through the GitHub website you can use their app. Once you've got the app installed and logged in do the following:

1. Select the GitHub account you want to add the repo to on the left
2. Click Create button at the top
3. Enter a name and click create
4. The repository will be created in GitHub and automatically sync with the folder on your machine

Adding an existing Repository to Visual Studio

If you already have a repository cloned on your machine but it's not showing in Team Explorer you can add it by clicking on Add

1. Click the Connect button to view the list of local repositories
2. Click add an enter the path to the repository on your hard drive
3. Click Add

I've seen companies that have no form of source control, companies using backups as source control, people still using Source Safe along with a whole bunch of actual good source control solutions such as Git and SVN. But when I say what's your source control strategy I don't mean what tool are you using, I mean how are you using it.

Checking you're code into source control adds many benefits such as merging, versioning, reverting etc, but to get the most out of it you really need a strategy to define how you will use it. There is no one right way and the strategy you use ultimately depends on your team size and what you are doing.

Here are a few example strategies:

The didn't know about a strategy approach

You've got a source control solution, you're regularly checking your code in but you've never made a branch.

This is actually quite common. Everyone is developing against the same branch, you've got all the benefits of seeing who changed which piece of code, you can revert when you need to revert and when you do an update there's some help with merging.

What you don't get though is the ability to have work happening in parallel and one being released before the other. If you needed to do a release either you have to have a way of hiding the unfinished updates as the code is pushed to live or some way of reverting just those bits.

A branch for every feature

The other extreme is to have all development work happen on a new branch. When it's ready to be release the code is merged back into the trunk and then released (plus some testing along the way).

The advantages of this are your trunk is always the same as what's on live meaning emergency fix's can be made without trying to find the last release in the source control history. Developers can also work separately without stepping each other toes and can release.

However with more than one development happening at the same time, whoever merges second could have a big job on their hands. All that branching is also going to be time consuming.

Updating branches often

So you're using branches and to avoid a tricky merge are keeping the branch up to date regularly, possibly daily. Anyone who's tried to merge a feature branch after 3 months of development can testify that it doesn't always go smoothly and can take some time.

Only updating the branch at the end

You've decided to accept the large merge at the end of the project. You don't like it but figure all those small merges during the project actually add up to more time than one big one at the end. You can then also concentrated on getting the feature built without the regular merge distraction.

A tag for each release

If you've ever needed to find a previous release and only have the history to go on it can be hard. If there's no comment that says release to live you are basically guessing based on release date and last commit.

A tag is basically the same as a branch and if its part of your release plan, you've got a good way of finding each release to live.

A branch for live, a branch for dev

In this setup you have a live branch that always match's what's on the live site. There's less need for tags as commits to this branch are normally also a release to live, and because the branch is always in sync with live, emergency fix's are taken care of.

The downside with this approach is everyone is working on the dev branch, so exceptions should be made and feature branches used when it makes sense.

So…

So there are some of the strategies I've come across, but there will be plenty more. What you do ultimately relates to what kind of work you do, how frequently you release and what kind of team size you have. But the one thing you must do with all of them is make comments on each commit. If you don't then source control becomes virtually useless.