This lab introduces GitHub. If you haven’t already done so, please submit your GitHub ID using the form linked from this week’s guide.
The distributed configuration management tool we introduce in this course is GitHub, which is based on Git.
We’ll use Git/GitHub both to submit both individual and team assignment code. Git is traditionally used via the command line and these lab materials will present it that way, but you can also use Git GUI tools if you’d like to do so. E.g., WebStorm provides a Git/GitHub plugin (see also GUI Clients).
You’ll be using course-provided code on GitHub.
Clone a copy of the course sample code found in https://github.com/kvlinden-courses/cs262-code.
% git clone https://github.com/kvlinden-courses/cs262-code.git % cd cs262-code
This repo includes useful code for selected class assignments.
Make it a practice of pulling changes from this course repo before you use it to make sure that you have the most recent code. Treat it as read-only.
You’ll also be using GitHub to submit course assignments.
For this exercise, push your Expo applications from the first two labs to new repo(sitory)s on your GitHub account as follows.
On GitHub, create a new private repo under your
personal account named cs262
, and grant read
access to the course instructors and assistants (Do this
using Settings→Manage
access→Invite teams
or people; see the Moodle forum for our GitHub
IDs). You will submit all lab and homework applications as
subdirectories in this repo. Private repos require
authentication, which now requires a GitHub personal access
token. These tokens are machine-specific and can be
saved in IDEs (e.g., Intellij, VSCode) and or
command-line tools (e.g., GitBash, Linux).
On your development machine:
Go to your development directory and clone your new (empty) repo into that directory as you did with the class code above. N.b. GitHub will give you the appropriate URL to use (see the green “Code” button).
lab01
and lab02
sub-directories in this new Git repo directory and copy
the readme file into the root of the lab subdirectory.
The structure should look as follows: cs262 lab01 my-lab01-app README.md lab02 my-lab02-app README.md cs262-code ...
Note that Expo automatically creates a Git repo for each new project,
which would create a nested repo for every assignment — possible
but tricky. Instead, we ask you to manually delete the .git
folder in each of your application directories.
This lab is based on hyperlink to lab source.
hacks that I had to make
Answers to the lab questions:cs262
repo directory, add,
commit and push your lab code to your new
cs262
GitHub repo.
% git add . % git commit -m "a concise, informative commit message" % git branch -M main % git push origin main
On GitHub:
node_modules
should be
.git-ignored.
At this point we should both have access to your new repo.
For future lab and homework assignments, you’ll create
new sub-directories in your cs262
Git repo
directory and push them as you did these first two. The
structure will be as follows:
cs262 - lab01 - lab02 - homework1 - lab04 - …
This way, you will have one Git repo, with a single
.git
sub-directory in the root, and a separate
sub-directory for each assignment, each of which will contain a
full application file structure. Note that there isn't a lab03
directory because this lab doesn't require any new code.
Be sure to include the .gitignore
file in each application
sub-directory in order to prevent committing/pushing (large!) non-source
files unnecessarily to Git/GitHub (e.g., the node_modules/
directory for NodeJS applications); most application builders create
this
file automatically. GitHub should store source code only.
We’ll also use GitHub for team project code and collaboration.
Your team should do the following.
Designate one team member to go to GitHub and:
calvin-cs262-fall20XX-teamY
).
Here’s an example team organization: https://github.com/calvin-cs262-organization. This organization will hold all your team code and deliverables throughout the semester. You can now begin to collaborate using this organization as a shared resource.
All team members should now do the following:
% git checkout -b temp/username
username.txt
.
Include a (fun, likely irrelevant) message in
the file.
% git add newFilename
% git push origin temp/username
On GitHub:
GitHub should now show pull requests from all team members.
Finally, all team members can move back to the main branch on their local machines, pull the changes from GitHub, and verify that all the files have been downloaded locally.
% git checkout main
Leave the junk files and the test branches out there for a week so that we can confirm that you’ve pushed them; the team should delete them all later.
You’re now in a position to build and push your project 1 (Inception-Vision), hello-world prototype to the client repo.
As with your team Trello board, your GitHub repo(s) should be active throughout the week. Code should be getting written; pull requests made, reviewed and merged; etc. Check out the “Pulse” and the ”Graphs” provided by GitHub for your team repo(s) (see the menu bar on the right). We’ll use these tools to monitor your team progress and participation.
Development in Scrum is punctuated by sprint planning and review sessions. In this session we will do the following.
Normally, these planning meetings are separate and each takes time, so we’ll only be able to get you started by hitting the highlights.
Participate actively in your team’s meeting.
Please update your Moodle “Project Teams” entry by adding a hyperlink for your GitHub organization.
There is nothing to submit in Moodle for this lab. Push your work to the GitHub repo you identified in the GitHub IDs file given in the guide.