Another way to phrase this question is, "How do multiple developers use the same code base in their work?"
Selenium automation is just using an open source library to set up testing. It's not any different to what your developers do in your teams codebase. The process and setup are the same.
What does that look like?
Ensure the Selenium project is set up in a code repository (Github, Bitbucket, etc)
Ensure any work QA/Test automation engineers have setup a story to work in (usually in Jira). This can be a separate ticket for automation only or you can attach the work to the same story developers use.
Create a new branch in git to attach to the story you created.
In git or your code IDE/Editor, pull down that new branch.
Create any automation tests you need.
Submit a pull request when you're done coding. Here, you'll want the other Selenium contributors to review each others work.
Once the pull request is approved, you'll merge your code the main branch.
Following standard developer coding practices will ensure that multiple people can work in the same codebase to do Selenium automation coding.
I think the above answer explained the process. I would like to highlight the architectural shortcomings that could have made you ask this question.
As we may need to reuse the methods and other code of one page to another
This can be easily handled if the test automation follows the page object model. This ensures that methods and actions specific to a page are within the specific page class.
You can pull the latest changes each time before you start writing a page method to check if the method is already developed in the page class by someone else. If everyone follows this then it can avoid creating duplicate methods that does the same thing.
Add proper code commenting for methods that are not self-explanatory ( It is a code smell if much of code requires comments and are not self-explanatory. Meaning a second reviewer of code cannot understand what the code author intended to do unless a comment is provided. Code should be self-explanatory, anyone should be able to read the code and understand what it is supposed to do)
Provided proper code demos at sprint end. This keeps the entire team on the same page. There should be regular standup and code review to avoid unnecessary and duplicate codes.
Create a proper framework (Framework is not just fancy eclipse project structure, it defines rules and standards on how code should be written). Make sure unnecessary abstractions and complexities are removed, make sure everyone in the team are aware on how to write code logic and abstract it according to the framework.