I am wondering if there is a detailed list of tools/practices that can be used to QA websites. The tools that seem to get most mention are link checkers, validators and Selenium IDE. In my capacity, only the link checker and validator seem to work well. I'm not a QA specialist, so I don't know what it is that they do and want to be more informed about this topic.
How to QA websites?
As a developer, I know you always get the bug that makes you swear (under your breath) at the QA - but I don't think the fix/don't fix decision should be given to the developer - as demonstrated by the excuses you mention!! The most humble of programmers resents bugs appearing in his/her code and thus can be tempted to give you a hard time. I think a little friction between testers and devs is a necessary evil (providing you buy them a beer at the end of the day!). 'It's not a bug it's a feature' is a common retort but sometimes valid, which is probably why an important person to involve is probably someone from the business side (if that makes sense in what you do).
In my experience, it is worth recording stuff even if they are not possible to fix right now - you can always assign a sliding priority scale and just fix down to a certain level. Regularly reviewing bugs with the tester/dev together can help as well.
Sometimes testing is done once on the development branch, and again after merged into the release branch. But that is a process choice, not a requirement.
If you only release from the "mainline" branch, you might consider changing your QA process so that you only test after changes are merged into the release branch. And rely on the developer to test their changes pre/post merge. This is more typical.
With what you have now, it sounds like maybe you have one branch per developer (just a guess). And you submit bugs against each development branch. I would seriously consider changing this process. It is not maintainable and will be very challenging tracking bugs after merges.
As TrueWill suggested, setting up a continous integration would be a good idea. Supplement that with frequent (daily) builds. Then have QA test the builds.
There are numerous resources to get you started in testing. I suggest doing a little reading offline and online. One great testing book is How to Break Software, by James Whittaker. He's also got a follow up book that I am currently reading How to Break Software Security.
More important than the tools you use and the technology of the target application (web, java, c#, ...) is your approach to testing. What are the requirements of your system? What is it supposed to do? What is it not supposed to do? Start with these broad questions and use them to drill down into more specifics like Should the FizzBuzz module allow duplicate entries?
You cannot just jump directly into test tooling, as they are just tools, and without the right testing approach, they could do more harm than good.