“Multiple Developers working on the same file” can be a day in a life scenario and can happen anytime in during collaborative development. There can be two main scenarios in this case:
Assumption: For both the scenarios, both the Developers already have same Project Cloned in WebIDE.
1. In the first scenario, First Developer is done with the development of File1 and Second Developer need to make changes in the same file. To do this, the second developer needs to follow steps:
- Start work on File1
- Save the changes
Above Steps syncs changes by the second Developer with GitHub.
2. In the second scenario, both the developers work parallel on the same file and a conflict resolution is required!
In this case, when say Developer1 Commits and Pushes the changes, GitHub gets updated with the changes, however, when the second Developer2 the try to “Commit” and “Push” and an error comes: Git result: REJECTED_NONFASTFORWARD
The reason for this error is that WebIDE of Developer 2 is not aware of recent changes by Developer 1 and changes by Developer 2 can’t be taken into consideration ignoring changes by the first Developer. This kind of overriding may make the system inconsistent.
In this particular case, the conflict resolution should be initiated by Developer 2 who need to initiate the resolution. Following Steps to be followed:
- Developer 2 does a Fetch
- Developer 2 performs a Rebase.
- A warning comes: Resolve the conflicts to continue. Otherwise, skip the patch, or abort the rebase.
- On clicking OK, Git Pane offers a new screen called “Rebase Interactive Mode” with a new set of buttons for conflict resolution. Rebase Interactive Mode is a set of 4 buttons as follows:
- Skip Patch
Along with these 4 options, the code shown in editor view is merged view of both the versions of files worked by both the developers. The file contains appropriate delimiters to distinguish between 2 versions.
Usage of these four buttons in Rebase Interactive Mode is as below:
1. Continue: Developer2 makes changes in the editor merged file, clicks Continue > Commit > Push. This does conflict resolution and GitHub get this version and other Developer can fetch and Rebase this Version
2. Skip Patch: Skip patch will reset the commit which causes the conflict. A dialog asks: Are you sure you want to continue? On clicking OK – Changes by current user is lost and changes by other developer are retained. Developer 1, Developer 2 and GitHub are all in sync after Skip.
3 Abort: This operation leaves operation in middle. This leaves Developer 1, Developer 2 and GitHub in Different versions(possibly). Abort keeps the changes made by current Developer2.
4. Reset: asks for confirmation:
All changes will be discarded and cannot be recovered. Are you sure you want to continue?
On clicking OK, GitHub server version is set for current Developer2.