Multiple Developers working on the same file

Index

“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:

  • Fetch
  • Rebase
  • Start work on File1
  • Save the changes
  • Stage
  • Commit
  • Push

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

Push_rejected_nonfastforward.jpg

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.RebaseWarning
    • 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: RebaseInteractiveMode
      1. Continue
      2. Skip Patch
      3. Abort
      4. Reset

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.

Index

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s