There are a couple of things here that need to be addressed.
First, there is the two code bases. You've got your code. Your friend has his code. Wen you do a merge (somehow) you're doing it without the ability to see the changes that did it before.
You don't need github to do this. You could have a master git repo on a thumb drive, and then merge to and from that. Github makes it easier to do this (and harder to lose it). Working from the thumb drive though, you wouldn't have as complete a set of tutorials on how to use it or the other things that github has that are quite nice.
Next, there are the issues. You don't have a clear division of labor and tracking of this labor:
- Who is working on what?
- What changes fix what?
The github issue tracker within github allows you to assign who is working on a given issue and identify what state it is in. It also hooks up nicely if you tag the commits with the issue number, which then shows back in the issue tracker part of Github. This makes it clear when you later want to go back and see "what did I change to make issue #5 work?" - you can go to issue 5 and see the commits.
This doesn't prevent anyone from actually working on anything though. You or your friend could disregard the issue tracker and work on whatever. Working with other people takes discipline - properly communicating what you are doing, taking tasks, finishing tasks, and saying that they are done and then moving the changes into a place where other people on the project can make use of them.
If you, or your coworker are not disciplined to do this you will have problems.
Git or any VCS will not fix the problem of "basically what's been happening is we end up working on the exact same thing, or we write code for components that doesn't work with components the other person has written" on its own. You could do that today - write out all the specs on paper and have a stack of index cards with all the things that need to be done. Divvy up the index cards and work on them according to the written spec. No git involved in that process at all. An online version control system makes it easier to do this, if you are willing to work with it. But, if you aren't going to take the steps to actually be disciplined in your work habits in the first place, its just going to be extra tedious work.
As to overkill? Nope. Its not overkill. Its a very useful tool set that has a lot of features that you will use some day. There are simpler version control systems (I used RCS back in the day and it worked fine for my college projects with partners (drunken checkins are easier to revert than begging the lab staff for a restore from the nightly backup). Aside from the cloud and server nature of git, it had just a steep of a learning curve as RCS.
Note that many IDEs today have git support built in that make using it much easier. You've got this tagged with netbeans - consider reading Using Git Support in NetBeans IDE.