You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead?
If you want to make use of that hour you have with the whole team, you may want to consider running a retrospective. You can introduce the retrospective with simple honesty on your part: tell them that you don't feel the previous meetings have been productive and that you want to try something different to help everyone to benefit from the hour they have together.
In retros where I work, we will have three columns on a whiteboard, usually putting a smiley, meh, and sad face at the top, e.g. :), :|, and :(. Then the team members get to put anything on the board that they would like to talk about with the whole group.
In the happy column, you can celebrate successes (like congratulating Alice and Bob on the release of a project they worked on together), and you can declare victory with new processes you're trying (like the new bug tracker is much better than the old one).
In the meh column, you put things that aren't exactly happy or sad for the week. Maybe you purchased licenses for the new version of your IDE, and somebody hasn't seen any advantages of the new IDE -- they could put that on the board to figure out if everyone else feels like the upgrade was worthless or if other people have found ways that it is actually superior to the previous version.
In the sad column, you put things that haven't gone well for the week. Identifying the pain points for the week is probably the biggest benefit of a retrospective in my opinion. The whole team gets to discuss solutions to a real problem. On teams that all work on a single codebase for instance, someone might say that the FooBar class is unmaintainable and has been the cause of hours of debugging. Suddenly you find out that everyone else on the team has also lost multiple hours this week to FooBar, but nobody spent any time to clean it up. In that case, the team may collectively decide it makes sense for someone to spend time refactoring that code next week.
After everyone writes their proposed topics on the board, I like to briefly go over each topic and have its author give a 10-30 second explanation of the topic. This section of the meeting is easy to derail, so you'll have to be careful to keep people on topic -- e.g. someone will say that X has been a problem, and someone else starts talking about a solution to the problem; solutions shouldn't be discussed until after voting. In introducing the topics, you may find ways to group together multiple, closely related topics.
After the introductions, everyone gets three votes that they can distribute among the topics however they see fit. Finally, the votes are tallied, and whichever topics have the greatest number of votes is what the team discusses. For each topic, determine if there is an action that needs to be taken. Celebrating a success usually doesn't have an action item, but refactoring specific code can be assigned to one person. The action items should usually be completable by one person, but sometimes they are "whole-team" action items such as being mindful of having good commit messages.
Most retros tend to focus on topics in the sad column, and virtually no retros discuss everything that's written on the board. The meeting tends to finish whenever time is up. Immediately after the meeting, see that the action items are assigned to specific people; do this in whichever way makes sense for your organization.
I've had great success with retrospectives. They are a great way to build cohesion in a team, and they're a great way to reflect on the previous week and to refine your process. I think that if you try these out with your team, they will be much more engaged for your meetings.
Best Answer
This is not a problem of tooling or process. It's about culture. You describe a team that is comprised of people who are sensitive of criticism and protective of their own work. It's very, very common. But it is not professional.
My advice is to start leading by example. Offer your commits for review. Be open about requesting that people highlight the problems in your approach. Be receptive to feedback. Do not be defensive, but instead explore the reasons behind the feedback & agree on actions as a team. Encourage an atmosphere of open dialog. Find a champion or two in your team who are willing to do this also.
It's hard work.