I had to go back and re-read this to make sure I interpreted it correctly. I am also going to make some inferences.
On Friday when I was about to leave work, a co-worker stopped me and told me to make changes to already working code.
The fact that this live project would be used over the weekend by a real client in a production environment was not made known to me.
So basically you were given an assignment without an explicitly stated deadline, and, not knowing that your check-in was going to end up as part of a production release, you partially completed it Friday with the intent of finishing up after the weekend? Like a good developer, before leaving for the weekend you checked in your progress in case the cleaning crew dumped a mop bucket on your computer? It really doesn't sound like you did anything wrong per se, except that your code ended up as part of a production release. Maybe the senior developer didn't think you would stay around to work on the code, and so they never bothered to tell you about the release (dangerous assumption).
So, operating under the pretenses above, here is how I would approach it.
Be factual and objective
Your initial post is already defensive. "Well, no one told me, and QA normally tests, and.. and.. and.." Nobody cares. Stick to the facts. "I was asked right before I left to work on XYZ. I wasn't aware that there was a production release this weekend and that the code would be included. I checked in some of my changes before I left for the weekend so I didn't lose work, but they were not complete or fully tested."
Accept responsibility, and ask how you could have done better
Responsibility isn't the same as blame. Admit that you checked the code in under false assumptions and that it caused a problem. Then, instead of defending your actions, focus on something far more productive... figuring out how you can prevent it from happening again. "If I run into this situation again, would it be better if I checked my code in as a shelveset or didn't check it in at all until I felt it was production ready? Do we have a separate source control branch that I should be using for partial check-ins so they don't accidentally end up in a production release?"
Listen to the responses
It is amazing that this has to be said, but listen to what the senior developers and project managers are suggesting you do to prevent the issue. People will generally be far more willing to help someone they know is interesting in listening and learning.
This isn't the place to criticize processes
It would be totally unproductive to walk into the meeting and say, "Well, if our branching strategy was better, and we would have followed our standard processes, and..." This just comes across as blaming. It sounds to me like there very well IS an issue with process (considering untested/unapproved code got released into production), but there is a time and place to bring up these suggestions. The system currently in place is at least minimally working, and while a better system might have prevented the issue, try to fully understand the current system before pointing fingers at it.
Have compassion for yourself
You are the new dev. You made a mistake. We all have, and will continue to do so from time to time because we are human. I have found over the years that, unless you do something completely negligent and incompetent, mistakes usually aren't career-ending. You can choose to spend your energy beating yourself up about it, defending your actions, or making it right and figuring out how to do better in the future. Most people will respect a person that says, "Yep, I messed up. I'd like to fix it and I am willing to listen."