Lots of things to say here. First and probably the most important if you have been working on your own, your ideas are not the only good ones.
Further, rarely in a career do you join a team that is starting to build something new from scatch with no decisions made prior to your arrival. Expect that there will be decisons made about tools, architecture, techniques, standards that you don't agree with. Sometimes these descisions were made years earlier and are not subject to change as too much code would have to change to do so.
The person new to the team must first establish a reputation as someone who can accomplish things before trying to change the team or the way they do business. Until you have the respect of your peers and supervisors, you cannot effectively manage change. So when you first join a team, learn what they do and how they do it and establish yourself as a team player and valuable employee before trying to make people do things the way you want to.
I bring this up because usually this is the first issue people face when starting to work as a team, the loss of total control over what tools they use, how the software is architected and how to write code.
For instance if the team has a coding standard (which may or may not be formally written (but is generally apparent from the existing code when it is is informal), then follow it even if you don't like it. These standards make it easier for people to understand code they didn't write, so follow them. Insisting on doing this sort of stuff your way is the fast track to people not wanting to work with you.
Be aware that the time to argue for a change or a diffeernt way of doing things is before the decision has been made. You will get your chance later, have some patience at first.
Now how to get that respect and become a team player. First, do the tasks you are assigned to do and do them on time as much as possible and as well as the enviroment will allow you to. If you have meetings where software decisions are discussed (A planning meeting for a new project for instance), speak up with your ideas, but also listen respectfully to the ideas of others.
Talk to your team mates. Remeber that they may not have seen your resume and thus don't know what experience you have that might be valuable to them, so if you have expertise in something that is clearly on the horizon and someone else is stumped, offer some advice. But do it carefully, don't come off as a know-it-all.
Compliments to others can go a long way towards them accepting you as a part of the team. But make them genuine, people can spot a phony compliment a mile away.
Offer to do some of the tasks that are unpopular.
Learn where everything is and how to do most common tasks. Become the go-to person for domain knowledge or even how to submit a help desk request.
Take on the hard tasks if you feel you have the programming chops to do them, but don't be surprised if you have to prove yourself on easier things first before being allowed to do the harder more interesting things.
Be aware that you are now responsible for more than yourself. If you are having a problem and need help, ask for it. Don't let the team down by hiding problems or by pretending you are going to meet a deadline that you have no chance of making. If your delay will cause a delay for someone else, make sure they know well in advance. I can remember a project where we were all supposed to use something that one person was going to develop. He didn't ask questions of anyone else, he didn't let us know how he was getting along in the task and he didn't get it done which affected about 20 other things and made a lot of people certain to never recommend him or want towork with him in the future.
Treat people with respect, even those you personally do not like. To get respect, you have to give respect.
Learn the fine art of compromise. You can only get some of what you want by giving others some of what they want.
Have a positive, can-do attitude. And then translate that can-do into did-do. Nothing makes you a more valuable team memeber than the rest of the team knowing you will deliver.
Don't be defensive in code reviews (if other people will have to maintain your code and they will in a team, then they have a right to ask questions and try to make your code something they can understand) and don't be personally attacking when you do them for other people. Keep things professional.