0

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.

Yogie
  • 986
  • 2
  • 12
  • 14
  • 2
    Short answer is that Github does not solve any conflict ever. And as you yourself seem to suspect, you'd be better off reading a bit of doc around the branching and merging concept. [Here](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) for a good start. – Romain Valeri May 05 '23 at 08:16
  • 2
    There are protections in place when pushing into a branch in git _by default_ (which can be overridden by `force-pushing`, just in case).... and then, there are other protections availlable on top of that provided by github where a branch can be setup to make it impossible to force-push or even to force using pull requests to be able to move a branch forward. I agree with @RomainValeri that you should read about it. – eftshift0 May 05 '23 at 08:24
  • @RomainValeri the article you suggested talks about Git, I have good clarity on how Git works, I am just confused about resolvnig merge conflicts during pushing to same branch on remote (Github). I guess the only way to avoid overwriting each other's work is that a new branch should be created per topic per user (developer), is that correct? That may be because Github simply hosts commits and not compare it. But then since Github allows anyone pulling and pushing changes to your branch, then anyone can overwrite your work. – Yogie May 05 '23 at 08:55
  • 1
    Thee are never merge conflicts during pushing. Every push either fast-forwards remote branches or overrides them, never merges. – phd May 05 '23 at 09:47

1 Answers1

1

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.

bk2204
  • 64,793
  • 6
  • 84
  • 100