That’s part of the design concept of git: Your local repository is independent at the technical level, all actions that don’t explicitly fetch or push data from or to a remote repository are local only. So until they push and you fetch git on your local machine cannot know what commits (much less changes) your colleagues made.
The reason for this is to support distributed work: What you do with git is never blocked by what anyone else does. You can even work completely offline, and share your results later.
A common way to handle simultaneous edits with git is that everyone develops on their own branch, so you don’t get conflicts when pushing or otherwise get in each others’ way. When a feature is complete you merge that branch (or request it to be merged) into a shared branch, usually called
master. Because you’re asking here I assume you’re using Github, so: That’s what pull requests are for. There are many ways to organize this process, see Distributed Git – Distributed Workflows for examples.
A practical hint: If a feature is big and the shared branch(es) move a lot while you’re working on it, it’s usually a good idea to merge the target branch or rebase your work branch on it frequently. That way you can resolve conflicts as you go, instead of having to handle them all when your work is ready to merge.