Verified Commit 0aec1847 authored by Eliot Berriot's avatar Eliot Berriot
parents 3a5fef84 169388ef
Pipeline #2841 passed with stages
in 27 seconds
......@@ -22,7 +22,7 @@ Other resources you may want to check:
## How do we collaborate on software?
**Like most projects, successful software projects work best when multiple people can work on different tasks in parallel.** In a tyical organization, you expect accountants, managers, secretaries, salesfolks, and in fact everyone to work on their own tasks, seamlessly, at the same time.
**Like most projects, successful software projects work best when multiple people can work on different tasks in parallel.** In a typical organization, you expect accountants, managers, secretaries, salesfolks, and in fact everyone to work on their own tasks, seamlessly, at the same time.
You want, as much as possible, to avoid situations when someone needs to wait for someone else to proceed. We call those situations bottlenecks. An example of a bottleneck would be having a single phone in a 100-person company: everyone would have to wait to make a call, which would be a waste of time.
......@@ -187,18 +187,18 @@ In the previous scenario, Alice was alone. But on day 14, her friend Bob wants t
When Alice started to work on the project, she was using her local copy, which we call a *repository*. **You can think of a repository as a workspace, belonging to someone (Alice, in this case).**
Since Bob wants to start contributing, he will need his own repository. One way to do that is for Alice to *push*, or publish, her repository on a platform like GitHub or Gitlab, have Bob create an account there, and use the *fork* button. Forking essentially means "creating a copy of someone else's repository".
Since Bob wants to start contributing, he will need his own repository. One way to do that is for Alice to *push*, or publish, her repository on a platform like GitHub or GitLab, have Bob create an account there, and use the *fork* button. Forking essentially means "creating a copy of someone else's repository".
Git and GitHub have similar names, but are different beasts, and their differences become visible when you start talking about collaboration. **If I go back to my document analogy, git is similar to a text editor, like Word or LibreOffice.** It's a tool you install on your computer to work on your documents. **On the other hand, GitHub and similar platforms like Gitlab or Bitbucket are closer to Google Docs**: those are web service that host your work, and make it browsable and editable by others.
Git and GitHub have similar names, but are different beasts, and their differences become visible when you start talking about collaboration. **If I go back to my document analogy, git is similar to a text editor, like Word or LibreOffice.** It's a tool you install on your computer to work on your documents. **On the other hand, GitHub and similar platforms like GitLab or Bitbucket are closer to Google Docs**: those are web service that host your work, and make it browsable and editable by others.
You don't *have to* use GitHub if you're using git, but both tend to be used together because they serves different purposes.
When Bob forks Alice's repository, on GitHub, he ends up with an exact copy of her repository. It's Git's equivalent of "sending your thesis by email to a friend".
So, Bob has a working repository, and starts adding some commits on the master branch:
So, Bob has a working repository, and starts adding some commits on the `improvements` branch he created especially for that purpose:
```
| Bob's workspace / master branch
| Bob's workspace / improvements branch
|
| (previous commits omitted)
|
......@@ -212,7 +212,7 @@ So, Bob has a working repository, and starts adding some commits on the master b
|
```
Bob added two commits on day 14 and 15. He'd like this to be included in Alice's repository. One way to do that using platforms like GitHub or Gitlab is to create a *pull request* (named *merge request* in Gitlab, but those are the same thing). Pull requests are often abbreviated PRs.
Bob added two commits on day 14 and 15. He'd like this to be included in Alice's repository. One way to do that using platforms like GitHub or GitLab is to create a *pull request* (named *merge request* in GitLab, but those are the same thing). Pull requests are often abbreviated PRs.
Do you remember when Alice merged her `experiment` branch in her `master` branch in the previous section? A pull request is essentially asking someone to merge a branch from your repository, into a branch of their repository.
......@@ -220,7 +220,7 @@ So, Bob creates the Pull Request:
> Hello Alice!
>
> I'd like to merge the branch `master` from my repository into the `master` branch of your repository
> I'd like to merge the branch `improvements` from my repository into the `master` branch of your repository
>
> I've added one commit that fixes a typo, and one commit that improves the performance.
>
......@@ -232,7 +232,7 @@ When Alice receives that pull request, she'll be able to review Bob's commits, a
During the code review, Alice will read the changes introduces by Bob's commit, suggest some changes, and when she's satisfied with the result, accept the pull request.
Accepting the pull request will merge Bob's `master` branch into the `master` branch in her repository:
Accepting the pull request will merge Bob's `improvements` branch into the `master` branch in her repository:
```
......@@ -244,9 +244,9 @@ Accepting the pull request will merge Bob's `master` branch into the `master` br
|
* Commit from day 13: Alice edited lines 5 to 9 (from experiment branch)
|
* Commit from day 14: Bob edited lines 8 (from bob/master branch)
* Commit from day 14: Bob edited lines 8 (from bob/improvements branch)
|
* Commit from day 15: Bob deleted line 12 (from bob/master branch)
* Commit from day 15: Bob deleted line 12 (from bob/improvements branch)
|
```
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment