Basics: network and collaboration

Basics: network and collaboration #

Network #

In the previous section, Alice created and manipulated a git repository (with two branches).

She may also want to backup her work. To this end, she can upload some of her branches to a remote server. For instance use a cloud hosting service for git repositories (such as GitHub, Gitlab, Bitbucket, etc.).

Whenever Alice wants to upload the content of a branch, she can push this branch to the remote server.

Alice may also want to work from another computer (or a virtual machine). She can achieve this by cloning the repository from the remote server to this second machine.

Warning. By default, cloning a repository will only clone the main branch. But other branches (or all branches) can also be cloned explicitly.

Note. When two machines share a git branch, each of them has a copy of the full history of the branch.

Note. A branch can be shared with several remote servers (e.g. one for releases and one for development or continuous integration).

For these two reasons, git is sometimes called a “distributed” versioning system.

Collaboration #

Enters Bob…

Bob may want to collaborate with Alice on her project. He can clone Alice’s repository, and add his own commits.

In order to synchronize their work, Alice and Bob may agree to share the content of one or several branches (for instance the main branch).

Warning. For a smooth collaboration, code on a shared branch is expected to:

  • compile and
  • pass all unit tests defined for the project.

A basic workflow #

Alice and Bob share the main branch of their repository, and this branch is called main. This generally means that there are (at least) 3 copies of this branch: one on Alice’s machine, one on Bob’s machine, and one on the remote server.

However Alice and Bob, do not work directly on this branch. Instead, each of them works on his/her own development branch (e.g. called alice and bob respectively).

Backup #

Alice regularly pushes the content of the branch alice to the remote server, for backup purposes only. And so does Bob for the branch bob.

However, Alice does not need a local copy of bob, and Bob does not need a local copy of alice.

Sharing #

Bob has been working on a new feature, on the branch bob. His code compiles and passes all unit tests. He now feels ready to share this code with Alice (via the branch main).

However, Alice may have added commits to the main branch since Bob last looked at it.

In order to share his work, Bob:

  1. switches to (his local copy of) main (with the git checkout command), then
  2. updates his local copy of main (with the git pull command), then
  3. merges main into bob (this may require fixing merge conflicts), then
  4. merges bob into main, then
  5. pushes main to the remote server.

And Alice follows the same procedure to share her code (using alice instead of bob).

To go further #

There is a vast literature (and diverging opinions) on collaborative git workflows. This is beyond the scope of this course.

Note that many of these workflows incorporate so-called “pull requests”, which are a mechanism for to notify team members of your team that you have completed a feature. Pull requests are not a functionality of git itself, but of (some) git hosting services. To learn more about pull requests, you may consult the corresponding GitHub or Atlassian guides.