A non-bare repository contains .git/ as well as a snapshot of your
+tracked files that you can directly edit called the working tree (the
+actual files you can edit).
+
This is where we edit and commit changes.
+
When we create a repository with gitinit, it is a non-bare, “normal”, repository.
A non-bare repository contains .git/ as well as a snapshot of your
+tracked files that you can directly edit called the working tree (the
+actual files you can edit).
+
This is where we edit and commit changes.
+
When we create a repository with gitinit, it is a non-bare, “normal”, repository.
As a reviewer, we will learn how to ask for changes in a pull request.
+
As a reviewer, we will learn how to suggest a change in a pull request.
+
As a submitter, we will learn how to modify a pull request without closing
+the incomplete one and opening a new one.
+
+
Exercise tasks:
+
+
Create a new branch and one or few commits: in these improve something but also
+deliberately introduce a typo and also a larger mistake which we will want to fix during the code review.
+
Open a pull request towards the main branch.
+
As a reviewer to somebody else’s pull request, ask for an improvement and
+also directly suggest a change for the small typo.
+
As the submitter, learn how to accept the suggested change.
+
As the submitter, improve the pull request without having to close and open
+a new one: by adding a new commit to the same branch.
+
Once the changes are addressed, merge the pull request.
Someone has given you access to a repository online and you want to contribute?
+
We will learn how to make a copy and send changes back.
+
Then, we make a “pull request” that allows a review.
+
Once we know how code review works, we will be able to propose changes
+to repositories of others and review changes submitted by external
+contributors.
repository: The project, contains all data and history (commits, branches, tags).
+
commit: Snapshot of the project, gets a unique identifier (e.g. c7f0e8bfc718be04525847fc7ac237f470add76e).
+
branch: Independent development line. The main development line is often called main.
+
tag: A pointer to one commit, to be able to refer to it later. Like a commemorative plaque
+that you attach to a particular commit (e.g. phd-printed or paper-submitted).
+
cloning: Copying the whole repository to your laptop - the first time. It is not necessary to download each file one by one.
+
forking: Taking a copy of a repository (which is typically not yours) - your
+copy (fork) stays on GitHub/GitLab and you can make changes to your copy.
In order to make a complete copy a whole repository, the gitclone command can be used. When cloning, all the files, of all or selected branches, of a repository are copied in one operation. Cloning of a repository is of relevance in a few different situations:
+
+
Working on your own, cloning is the operation that you can use to create multiple instances of a repository on, for instance, a personal computer, a server, and a supercomputer.
+
The parent repository could be a repository that you or your colleague own. A common use case for cloning is when working together within a smaller team where everyone has read and write access to the same git repository.
+
Alternatively, cloning can be made from a public repository of a code that you would like to use. Perhaps you have no intention to work on the code, but would like to stay in tune with the latest developments, also in-between releases of new versions of the code.
When a fork is made on GitHub/GitLab a complete copy, of all or selected branches, of the repository is made. The copy will reside under a different account on GitHub/GitLab. Forking of a repository is of high relevance when working with a git repository to which you do not have write access.
+
+
In the fork repository commits can be made to the base branch (main or master), and to other branches.
+
The commits that are made within the branches of the fork repository can be contributed back to the parent repository by means of pull or merge requests.
There are two more ways to create “copies” of repositories into your user space:
+
+
A repository can be marked as template and new repositories can be
+generated from it, like using a cookie-cutter.
+The newly created repository will start with a new history, only one commit, and not
+inherit the history of the template.
+
+
+
+
You can import a repository from another hosting service or web address.
+This will preserve the history of the imported project.
+
+
+
+
+
Discussion
+
+
Visit one of the repositories/projects that you have used recently and try to find out
+how many forks exist and where they are.
+
In which situations could it be useful to start from a “template” repository by generating?
We need a mechanism to communicate changes between the repositories.
+
We will pull or fetch updates from remote repositories (we will soon discuss the difference between pull and fetch).
+
We will push updates to remote repositories.
+
We will learn how to suggest changes within repositories on GitHub and across repositories (pull request).
+
Repositories that are forked or cloned do not automatically synchronize themselves:
+We will learn how to update forks (by pulling from the “central” repository).
+
A main difference between cloning a repository and forking a repository is that the former is a general operation for generating copies of a repository to different computers, whereas forking is a particular operation implemented on GitHub/GitLab.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/branch/main/contributing/index.html b/branch/main/contributing/index.html
new file mode 100644
index 0000000..e3cf550
--- /dev/null
+++ b/branch/main/contributing/index.html
@@ -0,0 +1,269 @@
+
+
+
+
+
+
+ How to contribute changes to somebody else’s project — Collaborative distributed version control documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
How to contribute changes to somebody else’s project
This is a list of all exercises and solutions in this lesson, mainly
+as a reference for helpers and instructors. This list is
+automatically generated from all of the other pages in the lesson.
+Any single teaching event will probably cover only a subset of these,
+depending on their interests.
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Cloning a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Submit a pull request towards the main branch.
+
+
What will be new in this exercise:
+
+
If you create the changes locally, you will need to push them to the remote repository.
+
Learning what a protected branch is and how to modify a protected branch: using a pull request.
+
Cross-referencing issues and pull requests.
+
Practice to review a pull request.
+
Learn about the value of draft pull requests.
+
+
Exercise tasks:
+
+
Open an issue where you describe the change you want to make. Note down the
+issue number since you will need it later.
+
Create a new branch.
+
Make a change to the recipe book on the new branch and in the commit
+cross-reference the issue you opened (see the walk-through below for how to do that).
+
Open a pull request towards the main branch.
+
Review somebody else’s pull request and give constructive feedback.
+
Try to create a new branch with some half-finished work and open a draft
+pull request. Verify that the draft pull request cannot be merged since it
+is not meant to be merged yet.
As a reviewer, we will learn how to ask for changes in a pull request.
+
As a reviewer, we will learn how to suggest a change in a pull request.
+
As a submitter, we will learn how to modify a pull request without closing
+the incomplete one and opening a new one.
+
+
Exercise tasks:
+
+
Create a new branch and one or few commits: in these improve something but also
+deliberately introduce a typo and also a larger mistake which we will want to fix during the code review.
+
Open a pull request towards the main branch.
+
As a reviewer to somebody else’s pull request, ask for an improvement and
+also directly suggest a change for the small typo.
+
As the submitter, learn how to accept the suggested change.
+
As the submitter, improve the pull request without having to close and open
+a new one: by adding a new commit to the same branch.
+
Once the changes are addressed, merge the pull request.
+
+
+
+
+
How to contribute changes to repositories that belong to others
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Forking a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Opening and merging pull requests.
+
+
What will be new in this exercise:
+
+
Opening a pull request towards the upstream repository.
+
Learning that your fork can get out of date.
+
After the pull requests are merged, updating your fork with the changes.
+
Learn how to approach other people’s repositories with ideas, changes, and requests.
+
+
Exercise tasks:
+
+
Open an issue in the upstream exercise repository where you describe the
+change you want to make. Take note of the issue number.
+
Create a new branch in your fork of the repository.
+
Make a change to the recipe book on the new branch and in the commit cross-reference the issue you opened.
+See the walk-through below for how to do this.
+
Open a pull request towards the upstream repository.
+
After few pull requests are merged, update your fork with the changes.
+
Check that in your fork you can see changes from other people’s pull requests.
(optional) Centralized-3: Cross-referencing issues using “#N”
+
We will submit another change by a pull request but this time we will first create an issue.
+
+
Open an issue on GitHub and describe your idea for a change. This gives
+others the chance to give feedback/suggestions. Note the issue number, you
+will need it in step 3.
+
Create a new branch and switch to it.
+
On the new branch create a commit and in the commit message write what you
+did, but also add that this “closes #N” (replace N by the actual issue number from step 1).
+
Push the branch and open a new pull request. If you forgot to refer to the
+issue number in step 3, you can still refer to it in the pull request
+form (add a “closes #N” to the title or description).
+
Note how now commits, pull requests, and issues can be cross-referenced by including #N.
+
Notice how after the pull request is merged, the issue gets automatically
+closed. This only happens for certain keywords like closes or fix.
+
Discuss the value of cross-referencing them and of auto-closing issues
+with commits or pull requests.
(optional) Centralized-4: Why did we create a feature branch “yourname-somefeature”? (exercise/discussion)
+
Pushing directly to the main branch is perfectly fine for simple personal projects -
+the pull-request workflows covered here are for larger projects or for collaborative development.
+Guidelines for simpler workflows are given in the
+how much Git is necessary? episode of the git-intro lesson.
+
In collaborative development, whenever we update our repository we create a new branch
+and create a pull-request. Let’s now imagine that everyone in your group (or one person on two different clones)
+makes a new change (create a new file)
+but without creating a new branch.
+
+
You all create a new file in the main branch, stage and commit your change locally.
+
Try to push the change to the upstream repository:
+
$ gitpushoriginmain
+
+
+
You probably see something like this:
+
$ gitpush
+
+To https://github.com/user/repo.git
+ ! [rejected] main -> main (non-fast-forward)
+error: failed to push some refs to 'https://github.com/user/repo.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes (e.g. 'git pull') before pushing again. See the
+'Note about fast-forwards' section of 'git push --help' for details.
+
+
+
+
+
+
The push only worked for one participant (one clone).
+
Discuss why push for everybody else in this group was rejected?
+
+
+
Solution
+
The push for everyone except one person fails because they are missing one
+commit in their local repository that exists on the remote. They will first
+need to pull the remote changes before pushing their own, which will usually
+result in a merge commit.
+
+
+
+
+
How to contribute changes to repositories that belong to others
(optional) Distributed-3: Making changes to your pull request after it has been opened.
+
You can do that by pushing additional commits to the same branch where you opened the pull
+request from. Observe how they end up added to your pull request.
(optional) Distributed-4: Squash merge a pull request
+
If you complete this exercise much earlier than others, create a new pull
+request with two or more commits.
+
Then, when reviewing the change as maintainer, accept these with “Squash and
+merge” and later compare the source and target repositories/branches how they
+differ after the small commits got squashed into one.
In the forking layout, again we call one repository the “central”
+repository but people push to forks (their own copies of the
+repository on GitHub/GitLab/Bitbucket).
+
Features:
+
+
Anybody can propose contributions without asking for advance permission
+(to public projects).
+
Maintainer still has full control over what is merged.
+
Contributors now have more than one remote to work with.
+
+
This is used by almost all large (and small) open-source projects
+these days. Real life examples:
In the forking layout described above we work with multiple remotes,
+in this case two remotes: One remote refers to the “central” repository, and the other
+remote refers to the fork.
+
+
There is nothing special about the name origin. The origin is an alias/placeholder (think of “sticky note” referring to an URL).
We will work with a new repository for this exercise!
+
For this exercise we will fork a different repository compared to earlier today.
+Please step out of the repository and check that you fork the forking-workflow-exercise.
First fork the exercise repository (please carefully check with your exercise group
+which repository you should fork).
+
+
Then clone your fork to your computer. The repository URL
+should include your username. Clone using the SSH path you get from
+the webpage, not the https URL from the web browser. The URL should start with
+git@github.com:. Otherwise, you won’t be able to push later.
+
+
Pictorial representation of this step
+
Here is a pictorial representation of this part:
+
+
This is how it looks after we fork:
+
+
+
+
A fork is basically a (bare) clone.
+
The forked repo and the fork are in principle independent repositories.
+
When forking we copy all commits, all branches.
+
+
After we clone the fork we have three in principle independent repositories:
Before we start any coding, open a new “Issue” on the central repository as a
+“proposal” where you describe your idea for a recipe with the possibility to
+collect feedback from others. After creating this issue note the issue number.
+We will later refer to this issue number.
+
Discuss why it can be useful to open an issue before
+starting the actual coding.
Before we do any modification, we create a new branch and switch to it: this is
+a good reflex and a good practice. Choose a branch name which is descriptive of
+its content. For example:
+
$ gitbranchmyname-feature# describes both who it belongs to and the purpose
+$ gitswitchmyname-feature
+
+
+
On the new branch create a new file which will hold your recipe,
+for instance traditional_coderefinery_tacos.md (but change the name). You can get inspired
+here. Hopefully we all use different
+file names, otherwise we will experience conflicts later (which is also interesting!).
+
There is also a file called test.py which will automatically verify whether your recipe contains the string
+“taco” (case insensitive). This is there to slowly introduce us to automated testing.
+
Once you are happy with your recipe, commit the change and in your commit
+message reference the issue which you have opened earlier with “this is my
+commit message; closes #N” (use a more descriptive message and replace N by the
+actual issue number from step B).
Now push your new branch to your fork. Your branch is probably called something
+else than “myname-feature”. Also verify where “origin” points to.
+
$ gitpushoriginmyname-feature
+
+
+
+
If you get a password request for https://github.com when you try to push
+
Probably you cloned with the HTTPS URL (see gitremote-v to
+confirm). You can change this to SSH by going to the repository page,
+clicking “Code”, copying the SSH URL (starts with git@github.com:),
+and then updating the URL with:
Go to the central repository, and list all pull requests and view your your pull request.
+Remember that the pull request is created on the original repostory.
+
Wait here until we integrate all pull requests into the central repo
+together.
+
Observe how the issues automatically close after the pull requests are merged
+(provided the commit messages contain the right keywords).
+
+
(optional) Distributed-2: Send a conflicting pull request
+
If you complete parts A-E much earlier than others, try to open another pull request
+where you anticipate a conflict with your first pull request.
+
+
+
(optional) Distributed-3: Making changes to your pull request after it has been opened.
+
You can do that by pushing additional commits to the same branch where you opened the pull
+request from. Observe how they end up added to your pull request.
+
+
+
+
+
Exercise: Part 2 - code review and merging changes
+
We do this step together. The instructor shows a submitted
+pull request, discusses what features to look at, and how to discuss and review.
+
At the same time, maintainers can review open pull requests from their exercises groups.
+
+
(optional) Distributed-4: Squash merge a pull request
+
If you complete this exercise much earlier than others, create a new pull
+request with two or more commits.
+
Then, when reviewing the change as maintainer, accept these with “Squash and
+merge” and later compare the source and target repositories/branches how they
+differ after the small commits got squashed into one.
Luke Skywalker: You know, I did feel something. I could almost see the remote.
+
Ben Kenobi: That’s good. You’ve taken your first step into a larger world.
+
+
[from Star Wars Episode IV - A New Hope]
+
+
Discussion: Always create a feature branch
+
For each pull request create a new branch. Motivation:
+
+
Limits the risk that commits get accidentally appended to an open pull
+request (remember: pull requests are from branch to branch, not from commit
+to branch).
+
History-rewrite (rebased and/or squashed commits) on the central repository
+does not lead to a diverging branch on the fork.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/branch/main/forking-workflow/index.html b/branch/main/forking-workflow/index.html
new file mode 100644
index 0000000..6b234c4
--- /dev/null
+++ b/branch/main/forking-workflow/index.html
@@ -0,0 +1,196 @@
+
+
+
+
+
+
+ How to contribute changes to repositories that belong to others — Collaborative distributed version control documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
How to contribute changes to repositories that belong to others
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Forking a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Opening and merging pull requests.
+
+
What will be new in this exercise:
+
+
Opening a pull request towards the upstream repository.
+
Learning that your fork can get out of date.
+
After the pull requests are merged, updating your fork with the changes.
+
Learn how to approach other people’s repositories with ideas, changes, and requests.
+
+
Exercise tasks:
+
+
Open an issue in the upstream exercise repository where you describe the
+change you want to make. Take note of the issue number.
+
Create a new branch in your fork of the repository.
+
Make a change to the recipe book on the new branch and in the commit cross-reference the issue you opened.
+See the walk-through below for how to do this.
+
Open a pull request towards the upstream repository.
+
After few pull requests are merged, update your fork with the changes.
+
Check that in your fork you can see changes from other people’s pull requests.
In order to collaborate efficiently using Git, it’s essential to have a solid
+understanding of how remotes work, and how to contribute changes through pull
+requests or merge requests. The git-intro lesson
+teaches participants how to
+work efficiently with Git when there is only one developer (more precisely: how
+to work when there are no remote Git repositories yet in the picture). This
+lesson dives into the collaborative aspects of Git and focuses on the possible
+collaborative workflows enabled by web-based repository hosting platforms like
+GitHub.
+
This lesson is meant to directly benefit workshop participants who have prior
+experience with Git, enabling them to put collaborative workflows involving
+code review directly into practice when they return to their normal work. For
+novice Git users (who may have learned a lot in the git-intro lesson) this
+lesson is somewhat challenging, but the lesson aims to introduce them to the
+concepts and give them confidence to start using these workflows later when
+they have gained some further experience in working with Git.
If participants run gitgraph they might notice origin/HEAD. This has been
+omitted from the figures to not overload the presentation. This pointer represents the
+default branch of the remote repository.
The centralized collaboration episode is densest and introduces many new concepts,
+so at least an hour is required for it.
+
The forking-workflow exercise repeats familiar concepts (only
+introduces forking and distributed workflows), and it takes maybe half the
+time of the first episode.
+
The “How to contribute changes to somebody else’s project” episode can be
+covered relatively quickly and offers room for discussion if you have time left.
+However, this should not be skipped as this is perhaps the key learning outcome.
Exercise leads typically prepare exercise repositories for the exercise group
+(although the material speaks about “maintainer” who can also be one of the
+learners). Preparing the first exercise (centralized workflow) will take more
+time than preparing the second (forking workflow). Most preparation time is not
+the generating part but will go into communicating the URL to the exercise
+group, communicating their usernames, adding them as collaborators, and waiting
+until everybody accepts the GitHub invitation to join the newly created
+exercise repository.
+
Live stream:
+
+
Create the centralized exercises in an organization (not under your username) so
+that you can give others admin access to add collaborators. Also this way you
+can then fork yourself if needed.
+
For CR workshops, the exercises were placed under
+https://github.com/cr-workshop-exercises. The instructors or team leads need to have owner status in the organization in order to invite people.
+
We have created two versions of each a day in advance to signal which one might end up
+being discussed on recording/stream:
+
+
centralized-workflow-exercise-recorded
+
centralized-workflow-exercise
+
forking-workflow-exercise-recorded
+
forking-workflow-exercise
+
+
+
Protect the default branch of the two centralized-* repositories.
+
We create a organization team, stream-exercise-participants. The
+centralized workflow exercise repos have this team added as a
+collaborator (not forking - they fork so they don’t need write
+access there).
+
We have collected usernames of people who want to contribute via
+issues on GitHub. Make a fifth repository, access-requests,
+create a sample access request issue there, and have learners make a
+new issue in that repository. The day/morning before the day of the lesson the instructor or team leader now has to invite the learners to the team. Three steps:
+1. copy the learners GitHub username from the issue
+2. go to team member page, example linked here and invite that username to the team (this means first clicking invite and then scrolling down to click the “add username to …” button. This sends an email to that users email that is connected to their GitHub account.
+3. In the issue, copy following text (or similar) to the issue and “close with comment”:
+
WehaveaddedyoutotheCodeRefineryexerciserepository.
+
+Whatyoushoulddobeforetheexercisestarts:
+
+YouwillgetaninvitationfromGitHubtoyouremailaddress(thatGitHubknowsabout).Pleaseacceptthatinvitationsothatyoucanparticipateinthecollaborativeexercise.
+Tomakesureyoudon't get too many emails during the exercise, don'tforgetto"unwatch"bothhttps://github.com/cr-workshop-exercises/centralized-workflow-exerciseandhttps://github.com/cr-workshop-exercises/centralized-workflow-exercise-recorded.
+To"unwatch",gototherepositoryandclickthe"Unwatch"button(topmiddleofthescreen)andthenselect"Participating and @mentions".
+
+
+
+
+
``
+
+
Why a fifth repository? So that learners don’t get emails from all
+other access requests once they get added to the team
The difference between pull and pull requests can be confusing, explain clearly
+that pull requests or merge requests are a different mechanism specific to
+GitHub, GitLab, etc.
+
+
+
Pull requests are from branch to branch, not from commit to branch
+
The behavior that additional commits to a branch from which a pull request has
+been created get appended to the pull request needs to be explained.
Learn how to couple scripts to Git repository events.
+
+
+
+
Instructor note
+
+
10 min teaching/demonstration
+
+
+
Sometimes you would like Git events (commits, pushes, etc.) to trigger scripts
+which take care of some tasks. Hooks are scripts that are executed
+before/after certain Git events. They can be used to enforce nearly any kind of
+policy for your project. There are client-side and server-side hooks.
You can typically edit them through a web interface on GitHub/GitLab.
+
+
pre-receive: before accepting any references
+
update: like pre-receive but runs once per pushed branch
+
post-receive: after entire process is completed
+
Typical use:
+
+
Maintenance work
+
Automated tests
+
Refreshing of documentation/website
+
Sanity checks
+
Code style checks
+
Email notification
+
Rebuilding software packages
+
+
+
+
+
+
Actions, workflows, and continuous integration services
+
GitHub and GitLab let you define workflows/actions/recipes which are triggered
+by e.g. gitpush or by a release (tag creation). They can be customized and
+almost any automation you can think of becomes possible.
+
These services use hooks under the hood. These days, project are more likely to
+use these higher-level services rather than Git hooks directly.
We have learned how to make a Git repository for a single person. What
+about sharing?
+
+
Share the folder using email or using some file sharing service:
+This would lead to many back and forth emails and would be difficult
+keep all copies synchronized.
+
One person’s repository on the web: allows one person to keep track of
+more projects, gain visibility, feedback, and recognition.
+
Common repository for a group: everyone can directly update the same repository.
+Good for small groups.
+
Forks or copies with different owners: anyone can suggest changes, even without
+advance permission. Maintainers approve what they agree with.
+
+
Being able to share more easily (going down the above list) is
+transformative (easier to change something, that is you are not the sole owner)
+because it allows projects to scale to a new level.
+This can’t be done without proper tools.
+
In this lesson we will learn how to keep repositories in sync and how to
+work with remote repositories on GitHub and other services. We will
+discover and exercise the centralized as well as the forking workflows,
+and finally look into how to automate tasks using Git hooks.
We will do this exercise on GitHub but also
+GitLab and
+Bitbucket allow similar workflows and
+basically everything that we will discuss is transferable. With this
+material and these exercises we do not endorse the company
+GitHub. We have chosen to demonstrate a
+number of concepts using examples with
+GitHub because it is currently the most
+popular web platform for hosting Git repositories and the chance is
+high that you will interact with
+GitHub-based repositories even if you choose
+to host your Git repository on another platform.
remote: Roughly, another git repository on another computer. A
+repository can be linked to several other remotes.
+
push: Send a branch from your current repository to another repository
+
fetch: Update your view of another repository
+
pull: Fetch (above) and then merge
+
origin: Default name for a remote repository.
+
origin/NAME: A branch name which represents a remote branch.
+
main: Default name for main branch.
+
merge: Combine the changes on two branches.
+
conflict: When a merge has changes that affect the same lines,
+git can not automatically figure out what to do. It presents the
+conflict to the user to resolve.
+
issue: Feature of web repositories that allows discussion
+related to a repository.
+
pull request: A GitHub/Gitlab feature that allows you to send a
+code suggestion using a branch, which allows one-button merging. In
+Gitlab, called “merge request”.
+
git hook: Code that can run before or after certain actions, for
+example to do tests before allowing you to commit.
+
bare repository: A copy of a repository that only is only the .git
+directory: there are no files actually checked out. Directory names
+usually like something.git
Understand how to collaborate using a centralized workflow.
+
Understand the difference between local branch, origin/branch, and remote branch.
+
+
+
+
Instructor note
+
+
30 min teaching
+
30 min exercises
+
+
+
+
Meaning of “central” in a distributed version control
+
In this episode, we will explore the usage of a centralized workflow for collaborating online on a project
+within one repository on GitHub. This means that everyone has
+access to that central repository - convenient (but doesn’t scale to a huge
+project).
+
In the next section, we will see that Git is
+distributed version control.
+This means that any type of repository links that you can think of can be
+implemented - not just “everything connects to one central server”.
In this exercise we will practice collaborative centralized workflow in
+groups (but you can also collaborate with us as individual).
+One person (maintainer) will create the exercise repository, and
+collaborators will contribute to it. We’ll discuss how this leads
+to code review and discuss a number of typical pitfalls.
+
+
Exercise preparation
+
+
+
Form not too large groups (4-5 persons).
+
Each group needs to appoint someone who will host the shared
+GitHub repository: the maintainer.
+This is typically the exercise lead (if available). Everyone else
+is a collaborator.
Then everyone in your group needs their GitHub account to be added as collaborator to the exercise repository:
+
+
Collaborators give their GitHub usernames to their chosen maintainer.
+
Maintainer gives the other group members the newly created GitHub repository URL.
+
Maintainer adds participants as collaborators to their project (Settings → Manage Access → Invite a collaborator).
+
+
+
+
The instructors are the maintainers. All watchers are
+collaborators. This exercise is only possible during our
+livestream courses.
+The preparation typically happens already the day before.
+
+
If you have not requested access (we email about it typically the day before this lesson)
+
If you have not yet requested access, could you please open an
+issue in this
+repository.
+Wait a
+minute for staff to add you, then wait for the invite email to arrive and
+accept the invitation from the email and “unwatch” repositories (below).
+
+
Choose only one to work with (you must have requested access already, see above)
Alternatively check the inbox for the email account you registered with
+GitHub. GitHub emails you an invitation link, but if you don’t receive it
+you can go to your GitHub notifications in the top right corner. The
+maintainer can also “copy invite link” and share it within the group.
+
+
+
+
+
Watching and unwatching repositories
+
+
Now that you are a collaborator, you get notified about new issues and pull
+requests via email.
+
If you do not wish this, you can “unwatch” a repository (top of
+the project page).
+
However, we recommend watching repositories you are interested
+in. You can learn things from experts just by watching the
+activity that come through a popular project.
Centralized-1: Clone a repository, add a file, push changes as a branch, and create a pull request
+
+
Before we start with the exercise, instructor points to the preparation (above).
+
Then work on steps A-H.
+
There are also optional exercises.
+
Before and after each action you take, run the following informational
+commands:
+
+
gitgraph - almost every time
+
gitstatus - when you modify files
+
+
+
+
+
+
Hint for breakout rooms
+
If the helper in the room is the one who sets up the central repository, they
+cannot easily demostrate the steps via screen-sharing as the repository’s maintainer. A
+good alternative is to have one of the learners screen-share and get advice on the
+steps from other learners and helpers!
Where REPOSITORY-URL is the repository created by the exercise
+maintainer.
+
Clone using the SSH path you get from the webpage (the one that starts with
+git@github.com:), not the one that starts with https://github.com.
+Otherwise, you won’t be able to push later.
+
+
Representation of what happens when you clone
+
+
+
Here and in what follows, “c1” is a commit, “b1” etc. are commits on side branches
+and “m1” is a merge commit.
+
+
We clone the entire history, all branches, all commits. In our case, we have one branch (we did not include all branches when creating our repository from template) and we have only one commit (initial commit).
+
gitclone creates pointers origin/main so you can see the branches of the origin.
+
origin refers to where we cloned from.
+
origin is a shortcut for the full URL.
+
origin/main is a read-only pointer.
+
The branches starting with origin/ only move during gitpull or gitfetch or gitpush.
+
Only gitpull or gitfetch or gitpush require network.
+
All other operations are local operations.
+
+
+
+
+
Step B. Change directory into the newly created directory
+
$ cdcentralized-workflow-exercise
+
+
+
Try to find out where this repository was cloned from using gitremote-v.
+
+
+
Step C. Create a branch yourname-somefeature pointing at your commit
+
Create a branch from the current main. Also adapt “yourname-somefeature” to a better name:
The yourname- prefix has no special meaning here (not like origin/): it is just part of a
+branch name to indicate who made it.
+
+
+
Step D. Create a file with a unique name, e.g.: yourusername.txt
+
In this file share your favourite cooking recipe or haiku or Git trick or
+whatever (we will push soon to a public repository so don’t share something you
+don’t want to become public for the duration of the exercise).
If you get a password request for https://github.com when you try to push
+
Probably you cloned with the HTTPS URL (see gitremote-v to
+confirm). You can change this to SSH by going to the repository page,
+clicking “Code”, copying the SSH URL (starts with git@github.com:),
+and then updating the URL with:
+
$ gitremoteset-urloriginSSH-REPOSITORY-URL
+
+
+
+
+
Now the commit also exists on the remote repository
+
+
+
+
+
Meaning of -u
+
The -u or --set-upstream will connect the local branch with the newly created upstream/remote branch
+and track it. This has the following advantages:
+
+
If you from here on only type gitpush or gitpull without branchname, Git will know what branch you
+refer to (depending also on your Git configuration). However, we still recommend to explicitly type where
+you want to push/pull to/from and which branch explicitly.
+
When you type gitstatus, Git will inform you whether your local branch is ahead or behind the upstream branch
+that it tracks.
+
+
However, also without the -u this step and the rest of the exercise will
+work. The fact that the local and remote branch are not connected is not a
+problem if you explicitly type out the remote and branch name every time.
+
+
+
+
Step G. Browse the network of branches and commits
+
After you have pushed your branch and other participants have too, browse the
+network of branches and commits (on GitHub click on Insights -> Network) and
+discuss what you see.
Submit a pull request from your branch towards the main branch.
+Do this through the web interface.
+
Meaning of a pull request: think of it as change proposal. In a popular project, it means that anyone can
+contribute with almost no work on the maintainer’s side - a big win.
+
There are several options to open a pull request:
+
+
Follow the link printed to terminal output when git-pushing a branch to GitHub/GitLab
+
Visit the GitHub repository in the browser after pushing the branch and click on the green button “Compare & pull request”
+
Click on “Pull requests” on top of the GitHub repository and either “Compare & pull request” or “New pull request”
+
Click on “Branches” and then “New pull request” from the respective branch
+
+
+
+
+
Exercise: Part 2 - code review and merging changes
+
+
Centralized-2: Merge the pull requests (together)
+
+
We do step 2A and 2B together (instructor demonstrates, and everybody follows along in their repositories).
+
+
+
+
Instructor note
+
At this stage it might be good to show how to submit and how to review a pull request.
+
+
When co-teaching change roles and switch screenshares also.
We do this step together on the main screen (in the main room) or on stream. The instructor shows a submitted
+pull request, discusses what features to look at, and how to discuss and review.
+
At the same time, helpers can review open pull requests from their exercises groups.
+
+
Once the pull-request is accepted, the change is merged
+
+
+
+
Finally also discuss the “network” on GitHub.
+
+
Instructor note
+
At this stage demonstrate how to suggest small changes to pull/merge requests:
Your branch yourname-somefeature is not needed anymore but more importantly,
+you need to sync your local copy: Everybody needs to do this step in their
+exercise repository but we do this together in the main room so that we can
+discuss this step and ask questions.
(optional) Centralized-3: Cross-referencing issues using “#N”
+
We will submit another change by a pull request but this time we will first create an issue.
+
+
Open an issue on GitHub and describe your idea for a change. This gives
+others the chance to give feedback/suggestions. Note the issue number, you
+will need it in step 3.
+
Create a new branch and switch to it.
+
On the new branch create a commit and in the commit message write what you
+did, but also add that this “closes #N” (replace N by the actual issue number from step 1).
+
Push the branch and open a new pull request. If you forgot to refer to the
+issue number in step 3, you can still refer to it in the pull request
+form (add a “closes #N” to the title or description).
+
Note how now commits, pull requests, and issues can be cross-referenced by including #N.
+
Notice how after the pull request is merged, the issue gets automatically
+closed. This only happens for certain keywords like closes or fix.
+
Discuss the value of cross-referencing them and of auto-closing issues
+with commits or pull requests.
(optional) Centralized-4: Why did we create a feature branch “yourname-somefeature”? (exercise/discussion)
+
Pushing directly to the main branch is perfectly fine for simple personal projects -
+the pull-request workflows covered here are for larger projects or for collaborative development.
+Guidelines for simpler workflows are given in the
+how much Git is necessary? episode of the git-intro lesson.
+
In collaborative development, whenever we update our repository we create a new branch
+and create a pull-request. Let’s now imagine that everyone in your group (or one person on two different clones)
+makes a new change (create a new file)
+but without creating a new branch.
+
+
You all create a new file in the main branch, stage and commit your change locally.
+
Try to push the change to the upstream repository:
+
$ gitpushoriginmain
+
+
+
You probably see something like this:
+
$ gitpush
+
+To https://github.com/user/repo.git
+ ! [rejected] main -> main (non-fast-forward)
+error: failed to push some refs to 'https://github.com/user/repo.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes (e.g. 'git pull') before pushing again. See the
+'Note about fast-forwards' section of 'git push --help' for details.
+
+
+
+
+
+
The push only worked for one participant (one clone).
+
Discuss why push for everybody else in this group was rejected?
+
+
+
Solution
+
The push for everyone except one person fails because they are missing one
+commit in their local repository that exists on the remote. They will first
+need to pull the remote changes before pushing their own, which will usually
+result in a merge commit.
+
+
+
+
Discussion: How to make changes to remote branches
+
If there is a remote branch somefeature, we can create a local branch and start tracking origin/somefeature like this:
+
$ gitswitchsomefeature
+
+
+
Once we track a remote branch, we can pull from it and push to it:
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Cloning a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Submit a pull request towards the main branch.
+
+
What will be new in this exercise:
+
+
If you create the changes locally, you will need to push them to the remote repository.
+
Learning what a protected branch is and how to modify a protected branch: using a pull request.
+
Cross-referencing issues and pull requests.
+
Practice to review a pull request.
+
Learn about the value of draft pull requests.
+
+
Exercise tasks:
+
+
Open an issue where you describe the change you want to make. Note down the
+issue number since you will need it later.
+
Create a new branch.
+
Make a change to the recipe book on the new branch and in the commit
+cross-reference the issue you opened (see the walk-through below for how to do that).
+
Open a pull request towards the main branch.
+
Review somebody else’s pull request and give constructive feedback.
+
Try to create a new branch with some half-finished work and open a draft
+pull request. Verify that the draft pull request cannot be merged since it
+is not meant to be merged yet.
We have learned how to make a Git repository for a single person. What
+about sharing?
+
+
Share the folder using email or using some file sharing service:
+This would lead to many back and forth emails and would be difficult
+keep all copies synchronized.
+
One person’s repository on the web: allows one person to keep track of
+more projects, gain visibility, feedback, and recognition.
+
Common repository for a group: everyone can directly update the same repository.
+Good for small groups.
+
Forks or copies with different owners: anyone can suggest changes, even without
+advance permission. Maintainers approve what they agree with.
+
+
Being able to share more easily (going down the above list) is
+transformative (easier to change something, that is you are not the sole owner)
+because it allows projects to scale to a new level.
+This can’t be done without proper tools.
+
In this lesson we will learn how to keep repositories in sync and how to
+work with remote repositories on GitHub and other services. We will
+discover and exercise the centralized as well as the forking workflows,
+and finally look into how to automate tasks using Git hooks.
We will do this exercise on GitHub but also
+GitLab and
+Bitbucket allow similar workflows and
+basically everything that we will discuss is transferable. With this
+material and these exercises we do not endorse the company
+GitHub. We have chosen to demonstrate a
+number of concepts using examples with
+GitHub because it is currently the most
+popular web platform for hosting Git repositories and the chance is
+high that you will interact with
+GitHub-based repositories even if you choose
+to host your Git repository on another platform.
Someone has given you access to a repository online and you want to contribute?
+
We will learn how to make a copy and send changes back.
+
Then, we make a “pull request” that allows a review.
+
Once we know how code review works, we will be able to propose changes
+to repositories of others and review changes submitted by external
+contributors.
repository: The project, contains all data and history (commits, branches, tags).
+
commit: Snapshot of the project, gets a unique identifier (e.g. c7f0e8bfc718be04525847fc7ac237f470add76e).
+
branch: Independent development line. The main development line is often called main.
+
tag: A pointer to one commit, to be able to refer to it later. Like a commemorative plaque
+that you attach to a particular commit (e.g. phd-printed or paper-submitted).
+
cloning: Copying the whole repository to your laptop - the first time. It is not necessary to download each file one by one.
+
forking: Taking a copy of a repository (which is typically not yours) - your
+copy (fork) stays on GitHub/GitLab and you can make changes to your copy.
In order to make a complete copy a whole repository, the gitclone command can be used. When cloning, all the files, of all or selected branches, of a repository are copied in one operation. Cloning of a repository is of relevance in a few different situations:
+
+
Working on your own, cloning is the operation that you can use to create multiple instances of a repository on, for instance, a personal computer, a server, and a supercomputer.
+
The parent repository could be a repository that you or your colleague own. A common use case for cloning is when working together within a smaller team where everyone has read and write access to the same git repository.
+
Alternatively, cloning can be made from a public repository of a code that you would like to use. Perhaps you have no intention to work on the code, but would like to stay in tune with the latest developments, also in-between releases of new versions of the code.
When a fork is made on GitHub/GitLab a complete copy, of all or selected branches, of the repository is made. The copy will reside under a different account on GitHub/GitLab. Forking of a repository is of high relevance when working with a git repository to which you do not have write access.
+
+
In the fork repository commits can be made to the base branch (main or master), and to other branches.
+
The commits that are made within the branches of the fork repository can be contributed back to the parent repository by means of pull or merge requests.
There are two more ways to create “copies” of repositories into your user space:
+
+
A repository can be marked as template and new repositories can be
+generated from it, like using a cookie-cutter.
+The newly created repository will start with a new history, only one commit, and not
+inherit the history of the template.
+
+
+
+
You can import a repository from another hosting service or web address.
+This will preserve the history of the imported project.
+
+
+
+
+
Discussion
+
+
Visit one of the repositories/projects that you have used recently and try to find out
+how many forks exist and where they are.
+
In which situations could it be useful to start from a “template” repository by generating?
We need a mechanism to communicate changes between the repositories.
+
We will pull or fetch updates from remote repositories (we will soon discuss the difference between pull and fetch).
+
We will push updates to remote repositories.
+
We will learn how to suggest changes within repositories on GitHub and across repositories (pull request).
+
Repositories that are forked or cloned do not automatically synchronize themselves:
+We will learn how to update forks (by pulling from the “central” repository).
+
A main difference between cloning a repository and forking a repository is that the former is a general operation for generating copies of a repository to different computers, whereas forking is a particular operation implemented on GitHub/GitLab.
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Cloning a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Submit a pull request towards the main branch.
+
+
What will be new in this exercise:
+
+
If you create the changes locally, you will need to push them to the remote repository.
+
Learning what a protected branch is and how to modify a protected branch: using a pull request.
+
Cross-referencing issues and pull requests.
+
Practice to review a pull request.
+
Learn about the value of draft pull requests.
+
+
Exercise tasks:
+
+
Open an issue where you describe the change you want to make. Note down the
+issue number since you will need it later.
+
Create a new branch.
+
Make a change to the recipe book on the new branch and in the commit
+cross-reference the issue you opened (see the walk-through below for how to do that).
+
Open a pull request towards the main branch.
+
Review somebody else’s pull request and give constructive feedback.
+
Try to create a new branch with some half-finished work and open a draft
+pull request. Verify that the draft pull request cannot be merged since it
+is not meant to be merged yet.
As a reviewer, we will learn how to ask for changes in a pull request.
+
As a reviewer, we will learn how to suggest a change in a pull request.
+
As a submitter, we will learn how to modify a pull request without closing
+the incomplete one and opening a new one.
+
+
Exercise tasks:
+
+
Create a new branch and one or few commits: in these improve something but also
+deliberately introduce a typo and also a larger mistake which we will want to fix during the code review.
+
Open a pull request towards the main branch.
+
As a reviewer to somebody else’s pull request, ask for an improvement and
+also directly suggest a change for the small typo.
+
As the submitter, learn how to accept the suggested change.
+
As the submitter, improve the pull request without having to close and open
+a new one: by adding a new commit to the same branch.
+
Once the changes are addressed, merge the pull request.
Exercise: Collaborating within the same repository (25 min)
+
What is familiar from the previous workshop days:
+
+
Forking a repository.
+
Creating a branch.
+
Committing a change on the new branch.
+
Opening and merging pull requests.
+
+
What will be new in this exercise:
+
+
Opening a pull request towards the upstream repository.
+
Learning that your fork can get out of date.
+
After the pull requests are merged, updating your fork with the changes.
+
Learn how to approach other people’s repositories with ideas, changes, and requests.
+
+
Exercise tasks:
+
+
Open an issue in the upstream exercise repository where you describe the
+change you want to make. Take note of the issue number.
+
Create a new branch in your fork of the repository.
+
Make a change to the recipe book on the new branch and in the commit cross-reference the issue you opened.
+See the walk-through below for how to do this.
+
Open a pull request towards the upstream repository.
+
After few pull requests are merged, update your fork with the changes.
+
Check that in your fork you can see changes from other people’s pull requests.
Understand how to collaborate using a centralized workflow.
+
Understand the difference between local branch, origin/branch, and remote branch.
+
+
+
+
Instructor note
+
+
30 min teaching
+
30 min exercises
+
+
+
+
Meaning of “central” in a distributed version control
+
In this episode, we will explore the usage of a centralized workflow for collaborating online on a project
+within one repository on GitHub. This means that everyone has
+access to that central repository - convenient (but doesn’t scale to a huge
+project).
+
In the next section, we will see that Git is
+distributed version control.
+This means that any type of repository links that you can think of can be
+implemented - not just “everything connects to one central server”.
In this exercise we will practice collaborative centralized workflow in
+groups (but you can also collaborate with us as individual).
+One person (maintainer) will create the exercise repository, and
+collaborators will contribute to it. We’ll discuss how this leads
+to code review and discuss a number of typical pitfalls.
+
+
Exercise preparation
+
+
+
Form not too large groups (4-5 persons).
+
Each group needs to appoint someone who will host the shared
+GitHub repository: the maintainer.
+This is typically the exercise lead (if available). Everyone else
+is a collaborator.
Then everyone in your group needs their GitHub account to be added as collaborator to the exercise repository:
+
+
Collaborators give their GitHub usernames to their chosen maintainer.
+
Maintainer gives the other group members the newly created GitHub repository URL.
+
Maintainer adds participants as collaborators to their project (Settings → Manage Access → Invite a collaborator).
+
+
+
+
The instructors are the maintainers. All watchers are
+collaborators. This exercise is only possible during our
+livestream courses.
+The preparation typically happens already the day before.
+
+
If you have not requested access (we email about it typically the day before this lesson)
+
If you have not yet requested access, could you please open an
+issue in this
+repository.
+Wait a
+minute for staff to add you, then wait for the invite email to arrive and
+accept the invitation from the email and “unwatch” repositories (below).
+
+
Choose only one to work with (you must have requested access already, see above)
Alternatively check the inbox for the email account you registered with
+GitHub. GitHub emails you an invitation link, but if you don’t receive it
+you can go to your GitHub notifications in the top right corner. The
+maintainer can also “copy invite link” and share it within the group.
+
+
+
+
+
Watching and unwatching repositories
+
+
Now that you are a collaborator, you get notified about new issues and pull
+requests via email.
+
If you do not wish this, you can “unwatch” a repository (top of
+the project page).
+
However, we recommend watching repositories you are interested
+in. You can learn things from experts just by watching the
+activity that come through a popular project.
Centralized-1: Clone a repository, add a file, push changes as a branch, and create a pull request
+
+
Before we start with the exercise, instructor points to the preparation (above).
+
Then work on steps A-H.
+
There are also optional exercises.
+
Before and after each action you take, run the following informational
+commands:
+
+
gitgraph - almost every time
+
gitstatus - when you modify files
+
+
+
+
+
+
Hint for breakout rooms
+
If the helper in the room is the one who sets up the central repository, they
+cannot easily demostrate the steps via screen-sharing as the repository’s maintainer. A
+good alternative is to have one of the learners screen-share and get advice on the
+steps from other learners and helpers!
Where REPOSITORY-URL is the repository created by the exercise
+maintainer.
+
Clone using the SSH path you get from the webpage (the one that starts with
+git@github.com:), not the one that starts with https://github.com.
+Otherwise, you won’t be able to push later.
+
+
Representation of what happens when you clone
+
+
+
Here and in what follows, “c1” is a commit, “b1” etc. are commits on side branches
+and “m1” is a merge commit.
+
+
We clone the entire history, all branches, all commits. In our case, we have one branch (we did not include all branches when creating our repository from template) and we have only one commit (initial commit).
+
gitclone creates pointers origin/main so you can see the branches of the origin.
+
origin refers to where we cloned from.
+
origin is a shortcut for the full URL.
+
origin/main is a read-only pointer.
+
The branches starting with origin/ only move during gitpull or gitfetch or gitpush.
+
Only gitpull or gitfetch or gitpush require network.
+
All other operations are local operations.
+
+
+
+
+
Step B. Change directory into the newly created directory
+
$ cdcentralized-workflow-exercise
+
+
+
Try to find out where this repository was cloned from using gitremote-v.
+
+
+
Step C. Create a branch yourname-somefeature pointing at your commit
+
Create a branch from the current main. Also adapt “yourname-somefeature” to a better name:
The yourname- prefix has no special meaning here (not like origin/): it is just part of a
+branch name to indicate who made it.
+
+
+
Step D. Create a file with a unique name, e.g.: yourusername.txt
+
In this file share your favourite cooking recipe or haiku or Git trick or
+whatever (we will push soon to a public repository so don’t share something you
+don’t want to become public for the duration of the exercise).
If you get a password request for https://github.com when you try to push
+
Probably you cloned with the HTTPS URL (see gitremote-v to
+confirm). You can change this to SSH by going to the repository page,
+clicking “Code”, copying the SSH URL (starts with git@github.com:),
+and then updating the URL with:
+
$ gitremoteset-urloriginSSH-REPOSITORY-URL
+
+
+
+
+
Now the commit also exists on the remote repository
+
+
+
+
+
Meaning of -u
+
The -u or --set-upstream will connect the local branch with the newly created upstream/remote branch
+and track it. This has the following advantages:
+
+
If you from here on only type gitpush or gitpull without branchname, Git will know what branch you
+refer to (depending also on your Git configuration). However, we still recommend to explicitly type where
+you want to push/pull to/from and which branch explicitly.
+
When you type gitstatus, Git will inform you whether your local branch is ahead or behind the upstream branch
+that it tracks.
+
+
However, also without the -u this step and the rest of the exercise will
+work. The fact that the local and remote branch are not connected is not a
+problem if you explicitly type out the remote and branch name every time.
+
+
+
+
Step G. Browse the network of branches and commits
+
After you have pushed your branch and other participants have too, browse the
+network of branches and commits (on GitHub click on Insights -> Network) and
+discuss what you see.
Submit a pull request from your branch towards the main branch.
+Do this through the web interface.
+
Meaning of a pull request: think of it as change proposal. In a popular project, it means that anyone can
+contribute with almost no work on the maintainer’s side - a big win.
+
There are several options to open a pull request:
+
+
Follow the link printed to terminal output when git-pushing a branch to GitHub/GitLab
+
Visit the GitHub repository in the browser after pushing the branch and click on the green button “Compare & pull request”
+
Click on “Pull requests” on top of the GitHub repository and either “Compare & pull request” or “New pull request”
+
Click on “Branches” and then “New pull request” from the respective branch
+
+
+
+
+
Exercise: Part 2 - code review and merging changes
+
+
Centralized-2: Merge the pull requests (together)
+
+
We do step 2A and 2B together (instructor demonstrates, and everybody follows along in their repositories).
+
+
+
+
Instructor note
+
At this stage it might be good to show how to submit and how to review a pull request.
+
+
When co-teaching change roles and switch screenshares also.
We do this step together on the main screen (in the main room) or on stream. The instructor shows a submitted
+pull request, discusses what features to look at, and how to discuss and review.
+
At the same time, helpers can review open pull requests from their exercises groups.
+
+
Once the pull-request is accepted, the change is merged
+
+
+
+
Finally also discuss the “network” on GitHub.
+
+
Instructor note
+
At this stage demonstrate how to suggest small changes to pull/merge requests:
Your branch yourname-somefeature is not needed anymore but more importantly,
+you need to sync your local copy: Everybody needs to do this step in their
+exercise repository but we do this together in the main room so that we can
+discuss this step and ask questions.
(optional) Centralized-3: Cross-referencing issues using “#N”
+
We will submit another change by a pull request but this time we will first create an issue.
+
+
Open an issue on GitHub and describe your idea for a change. This gives
+others the chance to give feedback/suggestions. Note the issue number, you
+will need it in step 3.
+
Create a new branch and switch to it.
+
On the new branch create a commit and in the commit message write what you
+did, but also add that this “closes #N” (replace N by the actual issue number from step 1).
+
Push the branch and open a new pull request. If you forgot to refer to the
+issue number in step 3, you can still refer to it in the pull request
+form (add a “closes #N” to the title or description).
+
Note how now commits, pull requests, and issues can be cross-referenced by including #N.
+
Notice how after the pull request is merged, the issue gets automatically
+closed. This only happens for certain keywords like closes or fix.
+
Discuss the value of cross-referencing them and of auto-closing issues
+with commits or pull requests.
(optional) Centralized-4: Why did we create a feature branch “yourname-somefeature”? (exercise/discussion)
+
Pushing directly to the main branch is perfectly fine for simple personal projects -
+the pull-request workflows covered here are for larger projects or for collaborative development.
+Guidelines for simpler workflows are given in the
+how much Git is necessary? episode of the git-intro lesson.
+
In collaborative development, whenever we update our repository we create a new branch
+and create a pull-request. Let’s now imagine that everyone in your group (or one person on two different clones)
+makes a new change (create a new file)
+but without creating a new branch.
+
+
You all create a new file in the main branch, stage and commit your change locally.
+
Try to push the change to the upstream repository:
+
$ gitpushoriginmain
+
+
+
You probably see something like this:
+
$ gitpush
+
+To https://github.com/user/repo.git
+ ! [rejected] main -> main (non-fast-forward)
+error: failed to push some refs to 'https://github.com/user/repo.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes (e.g. 'git pull') before pushing again. See the
+'Note about fast-forwards' section of 'git push --help' for details.
+
+
+
+
+
+
The push only worked for one participant (one clone).
+
Discuss why push for everybody else in this group was rejected?
+
+
+
Solution
+
The push for everyone except one person fails because they are missing one
+commit in their local repository that exists on the remote. They will first
+need to pull the remote changes before pushing their own, which will usually
+result in a merge commit.
+
+
+
+
Discussion: How to make changes to remote branches
+
If there is a remote branch somefeature, we can create a local branch and start tracking origin/somefeature like this:
+
$ gitswitchsomefeature
+
+
+
Once we track a remote branch, we can pull from it and push to it:
In the forking layout, again we call one repository the “central”
+repository but people push to forks (their own copies of the
+repository on GitHub/GitLab/Bitbucket).
+
Features:
+
+
Anybody can propose contributions without asking for advance permission
+(to public projects).
+
Maintainer still has full control over what is merged.
+
Contributors now have more than one remote to work with.
+
+
This is used by almost all large (and small) open-source projects
+these days. Real life examples:
In the forking layout described above we work with multiple remotes,
+in this case two remotes: One remote refers to the “central” repository, and the other
+remote refers to the fork.
+
+
There is nothing special about the name origin. The origin is an alias/placeholder (think of “sticky note” referring to an URL).
We will work with a new repository for this exercise!
+
For this exercise we will fork a different repository compared to earlier today.
+Please step out of the repository and check that you fork the forking-workflow-exercise.
First fork the exercise repository (please carefully check with your exercise group
+which repository you should fork).
+
+
Then clone your fork to your computer. The repository URL
+should include your username. Clone using the SSH path you get from
+the webpage, not the https URL from the web browser. The URL should start with
+git@github.com:. Otherwise, you won’t be able to push later.
+
+
Pictorial representation of this step
+
Here is a pictorial representation of this part:
+
+
This is how it looks after we fork:
+
+
+
+
A fork is basically a (bare) clone.
+
The forked repo and the fork are in principle independent repositories.
+
When forking we copy all commits, all branches.
+
+
After we clone the fork we have three in principle independent repositories:
Before we start any coding, open a new “Issue” on the central repository as a
+“proposal” where you describe your idea for a recipe with the possibility to
+collect feedback from others. After creating this issue note the issue number.
+We will later refer to this issue number.
+
Discuss why it can be useful to open an issue before
+starting the actual coding.
Before we do any modification, we create a new branch and switch to it: this is
+a good reflex and a good practice. Choose a branch name which is descriptive of
+its content. For example:
+
$ gitbranchmyname-feature# describes both who it belongs to and the purpose
+$ gitswitchmyname-feature
+
+
+
On the new branch create a new file which will hold your recipe,
+for instance traditional_coderefinery_tacos.md (but change the name). You can get inspired
+here. Hopefully we all use different
+file names, otherwise we will experience conflicts later (which is also interesting!).
+
There is also a file called test.py which will automatically verify whether your recipe contains the string
+“taco” (case insensitive). This is there to slowly introduce us to automated testing.
+
Once you are happy with your recipe, commit the change and in your commit
+message reference the issue which you have opened earlier with “this is my
+commit message; closes #N” (use a more descriptive message and replace N by the
+actual issue number from step B).
Now push your new branch to your fork. Your branch is probably called something
+else than “myname-feature”. Also verify where “origin” points to.
+
$ gitpushoriginmyname-feature
+
+
+
+
If you get a password request for https://github.com when you try to push
+
Probably you cloned with the HTTPS URL (see gitremote-v to
+confirm). You can change this to SSH by going to the repository page,
+clicking “Code”, copying the SSH URL (starts with git@github.com:),
+and then updating the URL with:
Go to the central repository, and list all pull requests and view your your pull request.
+Remember that the pull request is created on the original repostory.
+
Wait here until we integrate all pull requests into the central repo
+together.
+
Observe how the issues automatically close after the pull requests are merged
+(provided the commit messages contain the right keywords).
+
+
(optional) Distributed-2: Send a conflicting pull request
+
If you complete parts A-E much earlier than others, try to open another pull request
+where you anticipate a conflict with your first pull request.
+
+
+
(optional) Distributed-3: Making changes to your pull request after it has been opened.
+
You can do that by pushing additional commits to the same branch where you opened the pull
+request from. Observe how they end up added to your pull request.
+
+
+
+
+
Exercise: Part 2 - code review and merging changes
+
We do this step together. The instructor shows a submitted
+pull request, discusses what features to look at, and how to discuss and review.
+
At the same time, maintainers can review open pull requests from their exercises groups.
+
+
(optional) Distributed-4: Squash merge a pull request
+
If you complete this exercise much earlier than others, create a new pull
+request with two or more commits.
+
Then, when reviewing the change as maintainer, accept these with “Squash and
+merge” and later compare the source and target repositories/branches how they
+differ after the small commits got squashed into one.
Luke Skywalker: You know, I did feel something. I could almost see the remote.
+
Ben Kenobi: That’s good. You’ve taken your first step into a larger world.
+
+
[from Star Wars Episode IV - A New Hope]
+
+
Discussion: Always create a feature branch
+
For each pull request create a new branch. Motivation:
+
+
Limits the risk that commits get accidentally appended to an open pull
+request (remember: pull requests are from branch to branch, not from commit
+to branch).
+
History-rewrite (rebased and/or squashed commits) on the central repository
+does not lead to a diverging branch on the fork.
+
+
+
+
+
+
How to contribute changes to somebody else’s project
+
+
Objectives
+
+
Avoid frustration and surprises by first discussing and then coding.
Learn how to couple scripts to Git repository events.
+
+
+
+
Instructor note
+
+
10 min teaching/demonstration
+
+
+
Sometimes you would like Git events (commits, pushes, etc.) to trigger scripts
+which take care of some tasks. Hooks are scripts that are executed
+before/after certain Git events. They can be used to enforce nearly any kind of
+policy for your project. There are client-side and server-side hooks.
You can typically edit them through a web interface on GitHub/GitLab.
+
+
pre-receive: before accepting any references
+
update: like pre-receive but runs once per pushed branch
+
post-receive: after entire process is completed
+
Typical use:
+
+
Maintenance work
+
Automated tests
+
Refreshing of documentation/website
+
Sanity checks
+
Code style checks
+
Email notification
+
Rebuilding software packages
+
+
+
+
+
+
Actions, workflows, and continuous integration services
+
GitHub and GitLab let you define workflows/actions/recipes which are triggered
+by e.g. gitpush or by a release (tag creation). They can be customized and
+almost any automation you can think of becomes possible.
+
These services use hooks under the hood. These days, project are more likely to
+use these higher-level services rather than Git hooks directly.
A non-bare repository contains .git/ as well as a snapshot of your
+tracked files that you can directly edit called the working tree (the
+actual files you can edit).
+
This is where we edit and commit changes.
+
When we create a repository with gitinit, it is a non-bare, “normal”, repository.
remote: Roughly, another git repository on another computer. A
+repository can be linked to several other remotes.
+
push: Send a branch from your current repository to another repository
+
fetch: Update your view of another repository
+
pull: Fetch (above) and then merge
+
origin: Default name for a remote repository.
+
origin/NAME: A branch name which represents a remote branch.
+
main: Default name for main branch.
+
merge: Combine the changes on two branches.
+
conflict: When a merge has changes that affect the same lines,
+git can not automatically figure out what to do. It presents the
+conflict to the user to resolve.
+
issue: Feature of web repositories that allows discussion
+related to a repository.
+
pull request: A GitHub/Gitlab feature that allows you to send a
+code suggestion using a branch, which allows one-button merging. In
+Gitlab, called “merge request”.
+
git hook: Code that can run before or after certain actions, for
+example to do tests before allowing you to commit.
+
bare repository: A copy of a repository that only is only the .git
+directory: there are no files actually checked out. Directory names
+usually like something.git
This is a list of all exercises and solutions in this lesson, mainly
+as a reference for helpers and instructors. This list is
+automatically generated from all of the other pages in the lesson.
+Any single teaching event will probably cover only a subset of these,
+depending on their interests.
In order to collaborate efficiently using Git, it’s essential to have a solid
+understanding of how remotes work, and how to contribute changes through pull
+requests or merge requests. The git-intro lesson
+teaches participants how to
+work efficiently with Git when there is only one developer (more precisely: how
+to work when there are no remote Git repositories yet in the picture). This
+lesson dives into the collaborative aspects of Git and focuses on the possible
+collaborative workflows enabled by web-based repository hosting platforms like
+GitHub.
+
This lesson is meant to directly benefit workshop participants who have prior
+experience with Git, enabling them to put collaborative workflows involving
+code review directly into practice when they return to their normal work. For
+novice Git users (who may have learned a lot in the git-intro lesson) this
+lesson is somewhat challenging, but the lesson aims to introduce them to the
+concepts and give them confidence to start using these workflows later when
+they have gained some further experience in working with Git.
If participants run gitgraph they might notice origin/HEAD. This has been
+omitted from the figures to not overload the presentation. This pointer represents the
+default branch of the remote repository.
The centralized collaboration episode is densest and introduces many new concepts,
+so at least an hour is required for it.
+
The forking-workflow exercise repeats familiar concepts (only
+introduces forking and distributed workflows), and it takes maybe half the
+time of the first episode.
+
The “How to contribute changes to somebody else’s project” episode can be
+covered relatively quickly and offers room for discussion if you have time left.
+However, this should not be skipped as this is perhaps the key learning outcome.
Exercise leads typically prepare exercise repositories for the exercise group
+(although the material speaks about “maintainer” who can also be one of the
+learners). Preparing the first exercise (centralized workflow) will take more
+time than preparing the second (forking workflow). Most preparation time is not
+the generating part but will go into communicating the URL to the exercise
+group, communicating their usernames, adding them as collaborators, and waiting
+until everybody accepts the GitHub invitation to join the newly created
+exercise repository.
+
Live stream:
+
+
Create the centralized exercises in an organization (not under your username) so
+that you can give others admin access to add collaborators. Also this way you
+can then fork yourself if needed.
+
For CR workshops, the exercises were placed under
+https://github.com/cr-workshop-exercises. The instructors or team leads need to have owner status in the organization in order to invite people.
+
We have created two versions of each a day in advance to signal which one might end up
+being discussed on recording/stream:
+
+
centralized-workflow-exercise-recorded
+
centralized-workflow-exercise
+
forking-workflow-exercise-recorded
+
forking-workflow-exercise
+
+
+
Protect the default branch of the two centralized-* repositories.
+
We create a organization team, stream-exercise-participants. The
+centralized workflow exercise repos have this team added as a
+collaborator (not forking - they fork so they don’t need write
+access there).
+
We have collected usernames of people who want to contribute via
+issues on GitHub. Make a fifth repository, access-requests,
+create a sample access request issue there, and have learners make a
+new issue in that repository. The day/morning before the day of the lesson the instructor or team leader now has to invite the learners to the team. Three steps:
+1. copy the learners GitHub username from the issue
+2. go to team member page, example linked here and invite that username to the team (this means first clicking invite and then scrolling down to click the “add username to …” button. This sends an email to that users email that is connected to their GitHub account.
+3. In the issue, copy following text (or similar) to the issue and “close with comment”:
+
WehaveaddedyoutotheCodeRefineryexerciserepository.
+
+Whatyoushoulddobeforetheexercisestarts:
+
+YouwillgetaninvitationfromGitHubtoyouremailaddress(thatGitHubknowsabout).Pleaseacceptthatinvitationsothatyoucanparticipateinthecollaborativeexercise.
+Tomakesureyoudon't get too many emails during the exercise, don'tforgetto"unwatch"bothhttps://github.com/cr-workshop-exercises/centralized-workflow-exerciseandhttps://github.com/cr-workshop-exercises/centralized-workflow-exercise-recorded.
+To"unwatch",gototherepositoryandclickthe"Unwatch"button(topmiddleofthescreen)andthenselect"Participating and @mentions".
+
+
+
+
+
``
+
+
Why a fifth repository? So that learners don’t get emails from all
+other access requests once they get added to the team
The difference between pull and pull requests can be confusing, explain clearly
+that pull requests or merge requests are a different mechanism specific to
+GitHub, GitLab, etc.
+
+
+
Pull requests are from branch to branch, not from commit to branch
+
The behavior that additional commits to a branch from which a pull request has
+been created get appended to the pull request needs to be explained.