Collaborating with Git

# Collaborating with Git

Architecture & Deployment

**Notes:**

Learn how to collaborate on [GitHub](https://github.com) with [Git](https://git-scm.com).

**You will need**

- [Git](https://git-scm.com)
- A free [GitHub](https://github.com) account
- A Unix CLI

**Recommended reading**

- [Version control with Git](/course/201-git/)
- [Git branching](/course/202-git-branching/slides/)

---

## Distributed version control system

Working with remote repositories

---

### What is a remote?

**Notes:**

A **remote repository** is a version of your project that is hosted on the
Internet or network somewhere. You can have **several of them**.

Collaborating with others involves **pushing** and **pulling** data to and from
these remote repositories when you need to share work.

---

### Centralized workflow

There are [many ways](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows) to work with Git as a team. Many
teams will simply use a simple **centralized workflow**:

**Notes:**

In this workflow:

- A **shared central repository** is hosted on GitHub.
- Each developer has a **repository on their local machine**.
  - Each developer will add the shared repository as a **remote**.

---

### Integration manager workflow

The classic workflow for many open source projects:

**Notes:**

- The **project maintainer pushes to their public repository**.
- **Contributors clone that repository**, make changes, **push to their own
  public copy** and make a **merge request** on GitHub (or via email).
- The **maintainer merges changes** on GitHub (or locally and then pushes them
  to the main repository).

One of the main advantages of this approach is that you can continue to work,
and **the maintainer of the main repository can pull in your changes at any
time**. Contributors don't have to wait for the project to incorporate their
changes — each party can work at their own pace.

---

### Benevolent dictator workflow

A workflow for very large projects:

**Notes:**

- Regular **developers work on their topic branch** and rebase their work on top
  of `main` in the reference repository.
- **Lieutenants merge the developers' topic branches** into their `main` branch.
- The **dictator merges the lieutenants' `main` branches** into the dictator’s
  `main` branch.
- Finally, the **dictator pushes that `main` branch to the reference
  repository** so the other developers can rebase on it.

This kind of workflow isn’t common, but can be useful in **very big projects**,
or in highly hierarchical environments. It allows the project leader (the
dictator) to delegate much of the work and collect large subsets of code at
multiple points before integrating them.

---

### GitHub

[GitHub](https://github.com) is a web-based Git repository hosting service.

**Notes:**

It offers all of the **distributed version control** and **source code
management (SCM)** functionality of **Git** as well as other features like
access control, bug tracking, feature requests, task management, and wikis for
every project.

[distributed-workflows]: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows
[git]: https://git-scm.com
[github]: https://github.com