I am trying to suggest a workflow using GitHub. What I have in mind is, there will be two branches in the GitHub repo which is master and dev. Other developers will fork it unto their locals. Say person A, develops a new feature in feature-1 branch in his local, pushed it to GitHub repos's dev branch, and make a pull request. Then, all the developers will pull the GitHub dev branch into their locals and test the code. If all is okay, then merge the dev branch into master.
I have been doing research about this and all I get is by doing a pull request, what other dev will do I just READ THE CODE AND COMMENT. No actual testing whatsoever.
Can someone clarify this? I thought by doing pull request all developers get notified and then pull the code, do some ACTUAL editing on the code(not just read and comment) and push it to the same pull request created earlier.
Ultimately, "what to do when reviewing" is subject to your specific workflow / team.
If you want developers to test code as part of the process, then they can pull down the source branch and use that to run the code for testing.
If you want developers to edit code as part of reviewing, then I don't have any suggestions how to manage that. I think this simply doesn't make sense (who reviews the reviewer?), but I have included my reasoning below.
Generally, the idea with a Pull Request is that other developers would review the changes and propose improvements back to the original author - not just make changes themselves. Again, this is a workflow / team specific thing, but I personally would consider it very rude for another developer to just edit my PR without talking to me first.
The assumption is that the person who wrote the original code has the most up-to-date knowledge of the subject matter / business requirements / technical limitations and so suggestions (and their reasoning) should be evaluated by them. Again, this is a workflow / team specific thing.