Chapter 6. Remote Collaboration

Remote Collaboration Overview

Remote Collaboration Overview
Tag:

In a typical remote collaboration, you need to seamlessly work on both your local computer (i.e., the command line and a text editor) and a Remote Repository on the GitHub website.

The following is one of the typical flows of remote collaboration on Git & GitHub.

A typical cycle of remote collaboration

  1. Developer A (a project leader and the owner of the Remote Repository) establishes a link between his Local Repository and the Remote Repository used for the project. To establish the connection, he runs the git remote command.
  2. Once Developer A's Local Repository is linked with the Remote Repository, he can push his project directory to the Remote Repository by running the git push command. He also gives Developer B access to the repository at this point.
  3. After Developer B obtains access to the Remote Repository, she can bring the project directory from the repository by running the git clone command. The git clone command establishes a link between the Remote Repository and her Local Repository, and the command also creates a copy of the project directory on her local computer.
  4. There are two approaches for getting the project files from the Remote Repository the second time:
    • 1) Running the git pull command
    • 2) Running the git fetch command followed by the git merge command.
    • Note: The git pull command works as the git fetch command and git merge command. The git pull command is useful to save time, however, there are some cases when you need to run the git fetch command. This will be explained later.
  5. Once Developer B obtains the project directory under the master branch, she is ready to make her edits (e.g., adding a new feature of the program). To start her editing, she creates a new branch (topic branch) to separate her work from the main line of code development. After that, she edits the code on the new branch and creates a commit when her work is done.
  6. To share the edited code under the topic branch, Developer B pushes the branch into the Remote Repository by running the git push command.
  7. At this stage, the code edited by Developer B is not integrated into the master branch yet. Before integrating it, she asks Developer A to review the code and merge it with the master branch through a pull request. A pull request is a form on GitHub to create a request for a reviewer to review code and merge it with the main branch (e.g., the master branch).
  8. Once Developer A receives a pull request, he reviews the code and decides if the new code is ready to merge or still requires further edits. If further edits are required, he gives Developer B feedback on her code.
  9. If the code developed by Developer B is ready to merge, Developer A merges the topic branch with the master branch on the GitHub website.

Practice

Objective:
Prepare for practices

This section gives you information about how to prepare for practice in this chapter. The actual practice will start from the next page.

1. Accounts used in the practice explanation

As explained earlier, to fully understand the remote collaboration approach with Git and GitHub, you need to understand at least two different user perspectives:

1. The owner of the Remote Repository (Developer A)

2. A collaborator of the Remote Repository (Developer B)

The roles and account information details are described in the illustration below.

Remote-Collaboration-Overview

If there are two roles in the practice section on the same page, we'll use the following boxes to make it clear from which perspective the section is being explained.

bloovee-round-icon.pngAction by Developer A

Describe Developer A's actions here

skyblue-round-icon.pngAction by Developer B

Describe Developer B's actions here

2. Commit history rules for this practice

For practice purposes, we set a rule for commit messages, so that you can easily follow what each commit is about.

Example

commit message "M2LB"

M – Branch (e.g., M is Master, A is Branch_A)

2 – Commit order (e.g., 2 is the second commit on the branch)

L – Local vs. Remote (L is committed in the Local Repository, R is committed in the Remote Repository)

B – Developer who made the commit (e.g., A is Developer A, B is Developer B)

We also put the same letters as the content of practice files that are committed so you can easily see the relations between the commit and the edited content.

Note: This approach is only for practice purposes. In actual projects, you need to use a concise description of the key changes in the code (e.g., "fixed landing page UI", "integrated APIs", etc.).

In a typical remote collaboration, you need to seamlessly work on both your local computer (i.e., the command line and a text editor) and a Remote Repository on the GitHub website.

The following is one of the typical flows of remote collaboration on Git & GitHub.

A typical cycle of remote collaboration

  1. Developer A (a project leader and the owner of the Remote Repository) establishes a link between his Local Repository and the Remote Repository used for the project. To establish the connection, he runs the git remote command.
  2. Once Developer A's Local Repository is linked with the Remote Repository, he can push his project directory to the Remote Repository by running the git push command. He also gives Developer B access to the repository at this point.
  3. After Developer B obtains access to the Remote Repository, she can bring the project directory from the repository by running the git clone command. The git clone command establishes a link between the Remote Repository and her Local Repository, and the command also creates a copy of the project directory on her local computer.
  4. There are two approaches for getting the project files from the Remote Repository the second time:
    • 1) Running the git pull command
    • 2) Running the git fetch command followed by the git merge command.
    • Note: The git pull command works as the git fetch command and git merge command. The git pull command is useful to save time, however, there are some cases when you need to run the git fetch command. This will be explained later.
  5. Once Developer B obtains the project directory under the master branch, she is ready to make her edits (e.g., adding a new feature of the program). To start her editing, she creates a new branch (topic branch) to separate her work from the main line of code development. After that, she edits the code on the new branch and creates a commit when her work is done.
  6. To share the edited code under the topic branch, Developer B pushes the branch into the Remote Repository by running the git push command.
  7. At this stage, the code edited by Developer B is not integrated into the master branch yet. Before integrating it, she asks Developer A to review the code and merge it with the master branch through a pull request. A pull request is a form on GitHub to create a request for a reviewer to review code and merge it with the main branch (e.g., the master branch).
  8. Once Developer A receives a pull request, he reviews the code and decides if the new code is ready to merge or still requires further edits. If further edits are required, he gives Developer B feedback on her code.
  9. If the code developed by Developer B is ready to merge, Developer A merges the topic branch with the master branch on the GitHub website.

Practice

Objective:
Prepare for practices

This section gives you information about how to prepare for practice in this chapter. The actual practice will start from the next page.

1. Accounts used in the practice explanation

As explained earlier, to fully understand the remote collaboration approach with Git and GitHub, you need to understand at least two different user perspectives:

1. The owner of the Remote Repository (Developer A)

2. A collaborator of the Remote Repository (Developer B)

The roles and account information details are described in the illustration below.

Remote-Collaboration-Overview

If there are two roles in the practice section on the same page, we'll use the following boxes to make it clear from which perspective the section is being explained.

bloovee-round-icon.pngAction by Developer A

Describe Developer A's actions here

skyblue-round-icon.pngAction by Developer B

Describe Developer B's actions here

2. Commit history rules for this practice

For practice purposes, we set a rule for commit messages, so that you can easily follow what each commit is about.

Example

commit message "M2LB"

M – Branch (e.g., M is Master, A is Branch_A)

2 – Commit order (e.g., 2 is the second commit on the branch)

L – Local vs. Remote (L is committed in the Local Repository, R is committed in the Remote Repository)

B – Developer who made the commit (e.g., A is Developer A, B is Developer B)

We also put the same letters as the content of practice files that are committed so you can easily see the relations between the commit and the edited content.

Note: This approach is only for practice purposes. In actual projects, you need to use a concise description of the key changes in the code (e.g., "fixed landing page UI", "integrated APIs", etc.).

Tag: