I have created a .gitignore file and it keeps showing up in the unstaged changes area.
Why does git not take care of this automatically as this is kind of configration file for the project(repo)? Can't be a part of the repository by default? Why is such behavior included in design? Are there any use cases for such design?
Because the contents of that file probably need to change as the code in the project changes. Which means you want to be able to store the version history of the .gitignore file itself, along with the files making up the project. And that means that you'll be using the normal git commands to control when you commit that file.
So there's nothing else for git to do. You need to use the git commands anyway to manage committing .gitignore properly (it wouldn't make any more sense to implicitly commit .gitignore everytime you edit it than it would do implicitly commit any other file as soon as it changed), and doing so covers all the use cases of keeping track of the file. So there's no need for git to treat .gitignore specially.
In addition to the other answers ...
If you want the ignored files to be tracked as part of the repo, and shared by other people who check it out, then the .gitignore file(s) must be tracked (checked in and versioned) like any other file.
If you don't want the list of ignored files to be checked in and versioned then add filenames to .git/info/exclude in the root of the repo. That file is not checked in, so changes to it won't keep showing up as unstaged changes. That file is "part of the repository by default", but is not versioned like files in the working tree.
there are at least three ways to ignore files in git:
these settings are stored in the metadata of your git installation / the current clone. they are not transferred when creating a new clone and are thus not shared between users.
however, people noticed that often they all want to ignore the same files and they would like to exchange the list of ignored files. this list changes with time, so it is reasonable to put it under version control. and, as one principle of unix, everything is a file and plaintext if possible, you end up with a .gitingore file. now that you have a repository and a file that needs to be version controlled and exchanged between all the users of the repository --- why not simply add the file to the repository? that way you need no special logic and no hidden configuration files, everything just works.
and this is the third way to ignore files in git:
in my personal opinion .gitignore files are one of the things that make git awesome.
PS: to elaborate a bit more on the "why is it not there by default": i do not answer the question directly, but thinking about these questions might help:
all these things are strongly recommended and best practices, but from a technical point of view you can do without. and git has a tendency to do only the bare minimum to make things work. defaults in git strive to be reasonable but minimalstic. this is great but sometimes it makes it harder for beginners.
Basically, .gitignore is just a file.
Git is a very generic tool and does not incorporate any special cases without a good reason. And there is no reason good enough why .gitignore file should be treated separately.
This way users have the power to choose whether they want to have a one-suits-all .gitignore and check it in. Or allow every client to have its own set of ignored files.
.gitignore file can wreak havoc on a repository, checking them in automatically could be disastrous.