Intro to GitHub: find your repo, run your first loop

Week 0 onboarding. About 30 minutes of reading, then a short do-it-now checklist at the end. This is the first lesson in a thread that runs all term, so it stays small on purpose: get onto GitHub, learn to read the class organization page, and run one full clone, commit, and push. The deeper moves (branches, pull requests, issues, continuous integration, project boards) each get their own lesson later.

Why this matters, and why it is safe to practice here

When you start an internship, the first day is not about writing brilliant code. It is about getting your accounts working, finding the team's repository, and running the team's everyday loop once on something small. The people who struggle in week one are almost never the ones who could not solve the problem. They are the ones who had never used Git and GitHub for real and did not want to admit it.

This course fixes that ahead of time, and it does it without making the practice scary. Here is how a lab works in CSCD 211, and why it is safe to fumble. You do your work in a private repository that only you and your instructor can see, so no classmate watches you learn. You run the lab's tests on your own machine to check your work, as often as you like, and you push your commits whenever you want. There is no score waiting for you before the deadline: you decide when your work is ready, the way you will on the job. Your official submission is a separate step. At the end you upload a zip of your project to the Canvas assignment, and that zip is what the gradebook is built on, so it must match what you pushed. GitHub is where the work happens; Canvas is where your official submission lands. After the deadline the course grader runs once on your final commit and produces your score, so you are graded on what you turn in by the deadline, not on your first try, and every mistake you make along the way is recoverable. (Lab 0 this week is the warm-up: there is no code to grade yet, so you practice the clone, commit, and push loop, and the test-and-zip rhythm begins at Lab 1.)

The one promise of this lesson: by the end you can find your lab repository on the class organization page, do one complete clone, commit, and push, and, from Lab 1 on, finish by zipping your work and submitting it to Canvas.

Part 1: what you are looking at on the organization page

The class lives in a GitHub organization called EWU-CSCD211-Su26. An organization is just a shared home for a group's repositories. When you open it signed in, you are looking at the organization's front page as a member.

Your lab repository itself arrives a particular way, and it is not the plus button. You click the time-gated Accept button on the Canvas lab assignment, and GitHub creates the repository for you, named for you and the lab, with the starter files already in it. So on the organization page itself, the two things you reach for are:

• The Repositories tab, to find your assignment repository after you have accepted it.
• The People tab, to see your classmates and confirm you are a member of the organization.

The plus button in the top right makes a brand-new, empty repository from scratch. You do not need it for your first lab, and a later lesson will tell you when you do. Making your own repository now would give it the wrong name and none of the starter files, so reach for Accept, not plus, to get your lab.

Everything else is context you will grow into. The full map of every button is below as a reference card. Read the part above now, and come back to the card when you wonder what something does.

You are a member, not an owner, and that changes the page

Your instructor owns the organization. You are a member of it. Members see fewer controls than owners, and that is correct, not a broken page. The clearest sign is the Settings tab: owners have one, you do not, and its absence means the permissions are working as intended. If you compare your screen to a screenshot from the instructor and see fewer tabs, you are not missing anything. You are seeing the normal member view.

One more thing you may notice that is not part of GitHub at all: a small floating pill that says something like "Claude is active in this tab group." That is a browser extension drawing on top of the page. It belongs to your browser, not to GitHub, and you can ignore it while you learn the site. If you do not run that extension, you will never see it.

Reference card: every button and tab on the organization page

Reproduce this as a lookup, not a thing to memorize. The numbers are just labels for the regions of the page. The "Member vs owner" notes tell you which controls you should and should not see.

A. The global top bar (the dark strip across the very top). This is GitHub-wide and shows on every page when you are signed in.

Every item in this row is visible to every signed-in user. None of them need owner access.

B. The organization header (just below the top bar, specific to this org).

Seeing fewer tabs than your instructor is the expected member experience, not a permissions bug.

C. The page body (under the tabs, on Overview).

You can read and use all of these. You cannot rearrange them; that is an owner action.

D. The right sidebar (information about the org). Members and owners both see this area: a people preview, a grid of member avatars with a total count (element 23); the org's description, website, and contact links (element 24); an optional Sponsor button that is usually absent for a class (element 25); and a report-abuse link for genuinely harmful content (element 26).

E. Not part of GitHub. The floating "Claude is active in this tab group" pill (27) is a browser extension, not a GitHub control. Ignore it here.

If you use a screenshot to follow along and an element above is not on your screen, treat it as "not shown in our view" rather than something missing. The conditionally present ones (Teams, Packages, Sponsor, Copilot) are normal to be absent.

Part 2: the mental model before the buttons

Before any commands, hold one picture in your head. Git keeps your work in three places, and almost every beginner confusion ("why did my change not save?") is really a confusion about which of the three a change is currently in.

 working directory   --git add-->   staging area    --git commit-->   repository (history)
 (the files you                     (what you marked                   (the permanent record
  edit)                              to save next)                      of saved snapshots)

• The working directory is the files as they sit on your computer right now, including edits you have not saved.
• The staging area is the set of changes you have marked to go into your next save. git add moves a change from the working directory into staging.
• The repository is the permanent history of snapshots. git commit takes everything in staging and records it as one snapshot.

Two facts make the picture solid. First, a commit is a full snapshot of your tracked files, not just a list of differences, which is why you can return to any past state. Second, and this is the one most people get wrong: Git is not GitHub. Git runs entirely on your own computer with no network. GitHub is one website that hosts copies of Git repositories so people can share them. Everything in this part happens locally; GitHub does not enter until you push.

Reference card: commands mapped to the three trees

Introduce these to yourself as you need them. You do not need the whole table today.

Leave the sharp-edged commands (reset, rebase) alone for now. They cause more fear than fluency this early, and you will meet the safe ones first in a later lesson.

Part 3: your first loop, accept to clone to commit to push

Here is the whole loop for this lesson. It stops before branches and pull requests, which are the next lesson; today is just the straight line from accepting a lab to pushing your work.

1. Accept the lab. The lab assignment on Canvas links to a time-gated Accept button. Clicking it creates a repository for you inside the class organization, named for you and the lab.
2. Clone it. On the repository page, use the green Code button to copy the repository's web address, then on your computer run the clone command with that address. Cloning makes a local copy you can edit. This is the moment GitHub's copy becomes a working directory on your machine.
3. Make a change. Edit the file the lab asks you to, in your editor. The change now lives in your working directory and nowhere else.
4. Stage it. git add the file. The change is now marked for your next snapshot.
5. Commit it. git commit with a real message. The snapshot is now in your repository history.
6. Push it. git push sends your local commits up to GitHub. This is the only step that touches the network, and it is the step people mean when they wrongly say "I committed it to GitHub." Committing is local; pushing is what uploads.

Reference card: the commands, and how to write a commit message

git clone <the web address you copied>
cd <the folder it created>

# edit the file the lab asks for, then:
git add <that file>
git commit -m "Add bounds check to Stack.pop()"
git push

A commit message is for the next person who reads the history, and that person is usually future you. Write a short imperative line of about fifty characters or fewer that says what the change does. Good: Add bounds check to Stack.pop(). Not good: stuff, fixed it, asdf. The habit costs you nothing now and saves you real time later when you are reading back through what you did.

This Lab 0 drill is not autograded, and nothing here is hard to undo. This is practice infrastructure. Push early and push often, because a pushed commit is a backup of your work that lives somewhere other than your laptop.

Part 4: pushing is not submitting (the two halves)

This is the rule that prevents the most painful mistake in the course, so it appears in the very first lesson. Pushing to GitHub is not the same as turning in your lab. A finished coding lab has two halves and you need both.

First, your pushed repository is what the course grader scores: after the deadline, it runs the lab's tests on your final commit and produces your score. Before then, you check your own work by running those tests on your machine, and you push whenever you want. Second, your official submission is a zip of your project that you upload to the Canvas assignment, and it must match the commit you pushed. The repository is where the work and the grading happen; the Canvas zip is the timestamped record the gradebook is built on.

So when the lab is finished, you push your final commit, then build a zip of your project with the one command each lab gives you and submit that zip to Canvas. You do not assemble the zip by hand: the command leaves out the files that should not be in it and stamps which commit it matches, so it lines up with what the grader scored. "I pushed it to GitHub" and "I submitted it to Canvas" are two different sentences, and a lab is not done until both are true. Get in the habit now: finish and push the work on GitHub, then run that one command and submit the zip to Canvas as the last step, every time. (Lab 0 this week is the warm-up and has no zip; the two-halves rhythm starts at Lab 1.)

Part 5: what comes later in this thread

This lesson is the on-ramp. Each of these gets its own lesson as the term goes on, so treat the list as a map, not as material to learn today:

• Branches and pull requests. You will stop working directly on the main version and start doing each lab on its own branch, then open a pull request to review your own change before merging it. That is how every professional change reaches a shared codebase.
• Issues and the magic link. You will break a lab into small tracked pieces called issues, and learn how a commit that says Closes #4 checks one off automatically.
• Reading a continuous-integration run. You will read a demo run that compiles your code and runs the JUnit tests you wrote, and learn to tell a compile failure from a test failure from the log.
• Project boards. You will run a board that moves your work from Todo to In Progress to Done, the same way a real team makes its invisible work visible.

Part 6: common mistakes, cleared up

• "Git is GitHub." No. Git runs on your computer with no network. GitHub is one website that hosts Git repositories. You can do almost everything in this lesson with the internet turned off, right up until the push.
• "Committing uploads my code." No. git commit saves a snapshot locally. git push is the step that uploads it to GitHub. If your work is not on GitHub, you probably committed but did not push.
• "My page is missing the Settings tab, so something is broken." No. Settings is owner only. You are a member, and the smaller set of tabs is the correct member view.
• "The pull request replaces my Canvas submission." No. Both halves are required: the course grader scores your pushed repository after the deadline, and you still submit a matching zip to Canvas as your official record. Neither half alone is turning it in.
• "I will get a score each time I push." No. In this course you check your own work by running the lab's tests on your machine, as often as you like, and you push whenever you want. The course grader runs once, after the deadline, on your final commit. You are graded on what you turn in by the deadline, not on your first push, and learning to test your own code before you ship it is the professional habit this trains.

Part 7: try it now (the checkpoint)

Do these in order. Each maps to the one promise at the top of this lesson.

• [ ] Open EWU-CSCD211-Su26 while signed in, and find your lab repository under the Repositories tab.
• [ ] Open the People tab and confirm you can see your classmates, so you know you are really a member.
• [ ] Clone your repository, make the small change the lab asks for, then git add, git commit with a real message, and git push.
• [ ] See your commit on github.com: refresh the repository and find it in the history, so you know the push landed.
• [ ] Know the finish line: from Lab 1 on, the last step is to zip your project and submit the matching zip to Canvas. Lab 0 has no zip, so turn in what the Lab 0 assignment lists.

One short reflection to write in your own words: at the end of your first loop, what was sitting in each of the three trees, the working directory, the staging area, and the repository history? If you can answer that, you understand what just happened, not only which buttons you pressed.