I have completed two Github tutorials but this topic was not covered in any of them.
My confusion is, when 5 developers are working on the same branch, they all start working at 10 in the morning, they all pull the repo from remote to their local machine, and makes changes to the same files, when they push their commits to the remote at 5 in evening, the github will receive 5 different commits with 5 different versions of the same file(s), in this case will Github show an error for merge conflicts or it will simply replace the previous versions of a branch by the version who will push the last in time?
Also I was wondering, if anyone can push changes to any branch on the repo, won't he overwrite the previous branch, won't there be an issue with this?
When we "git restore [commit hash]", can we go back to the commits that were made after the commit hash we just restored to?
I apologize if these were naive questions, I am a learner in github so I am confused. Please help.
In your example, if you have five developers working on the same project, they will typically have five separate branches that they are working on. When those developers are ready to integrate their changes, they will typically open a pull request to merge their changes to the main branch.
At that point, if there are conflicts with the main branch, GitHub will warn that the change has conflicts, and won't permit it to be merged. If not, the developers can merge them in whatever order they like, and in each case, if the previous changes don't conflict with what's in the main branch as it progresses, they can be merged.
Note that GitHub never resolves merge conflicts itself. If there's a conflict, then someone with push access to the branch must resolve the conflicts and include an appropriate resolution. Until that's done, the branch won't be mergeable.
If users are all working on the same branch, then, by default, when pushing with Git, after the first change has been pushed, the server will realize that the push of the changes from the other developers is not a fast-forward. That is, the server side has commits that the client does not, and thus, the operation is aborted because to allow the push would override the existing changes. A thoughtful and considerate colleague would either push to another branch or communicate with their colleagues at this point.
However, having said that, a user can use a force push to overwrite those changes anyway and simply destroy them, replacing them with whatever's in the pushed branch. This can often be useful when a single person is working on a single branch and needs to rebase, which almost never leads to a fast-forward push.
In no event does a push result in a conflict. The result of a push is either a success because the push is a fast-forward, a success because the push isn't a fast-forward but it's a force push, or a failure of some sort.
As I mentioned above, practically, it's best to use pull requests with independent branches to make independent changes rather than all pushing to the same branch, since this results in fewer failed pushes and an easier workflow.