Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Build First Lecture #29

Closed
wants to merge 1 commit into from
Closed

Build First Lecture #29

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 52 additions & 16 deletions notes/2023-09-07.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
## Introductions

- Dr. Sarah Brown
- Please address me as Dr. Brown or Professor Brown,
- Please address me as Dr. Brown or Professor Brown

+++

Expand Down Expand Up @@ -33,6 +33,20 @@ questions can be "graded"



+++



### GitHub

- This class is not a GitHub class
- GitHub is the main tool that we will be using in this course
- Not expecting you to be familiar with it
- Homework is submitted through GitHub in a non-traditional way
- Great practice for real-life software development with a team or even individual
- More on that later


+++


Expand Down Expand Up @@ -119,7 +133,7 @@ Large Language Models will change what programming looks like, but understanding
- college is not about the facts, but the processes

```{note}
We may not think that we use the fact that we know the order of letters in the English language very often. Most of us learned the alphabet with a song, but we do not sing that on a dialy basis.
We may not think that we use the fact that we know the order of letters in the English language very often. Most of us learned the alphabet with a song, but we do not sing that on a daily basis.

However, we do fill out forms where we have to, for example, find the state we live in, in a dropdown and knowing the alphabetical order of the states helps us find ours faster.

Expand Down Expand Up @@ -168,17 +182,22 @@ Your KWL chart is where you will start by tracking what you know now/before we s

+++
1. click on .gihub, then workflows, then track.yml
2. click the 3 dots menu and select delete
3. commit directly to main with the default message
4. back to the main code tab
5. Click the pencil to edit the readme
6. Add your name
7. Add a descriptive commit message
8. Choose create a branch and open a pull request
9. name the branch
10. Click on the list of commits, now you have one more!


2. pay attention to what commits are currently present (will explain what a commit is in a few minutes)
3. click the 3 dots menu and select delete
4. commit directly to main with the default message
5. notice that one commit had been added (hmmm, what does this mean?)
6. back to the main code tab
7. Click the pencil to edit the readme
8. Add your name
9. Add a descriptive commit message
10. Choose create a branch and open a pull request
11. name the branch
12. Click on the list of commits, now you have one more!

```{Commits}
Commits represent a message to your future self/teammates/viewers.
They mark what signifigant change has been made between one "checkpoint" in the status of a project and the next
```



Expand All @@ -202,7 +221,7 @@ In your KWL chart, there are a lot of different topics that are not obviously re
+++


We will use learning the tools to understand how computer scientists think and work.
We will try to understand how computer scientists think and work through learning about the tools they use and some of their history.



Expand Down Expand Up @@ -264,9 +283,26 @@ GitHub Docs are really helpful and have screenshots
+++

## Git and GitHub terminology
<!--
I will expand this section of the lecture notes to what I think ought to be included in the introductory lectures.
I realize that all this information might not fit in the first lecture. I also realize that terms mentioned here are mentioned in more detail in future lectures.
But working with GitHub might be somewhat of a dive into an abyss of the unknown for some (as it was for me when I took this class first) and that might make it intimidating.
The terms are explained in future lectures in a technical manner. Where here, I attempt to bring them up in the simplest way possible "toddler terms"
After the first class, students are required to diploy the reflection workflow. Creating a pr, and being told to assign an instructor as a reviewer to it and commit changes.
Hopefully the following will serve as a simple intro to what these terms mean to reduce confusion.
-->
We also discussed some of the terminology for git. We will also come back to these ideas in greater detail later.


Software version control systems are used among software developers for two main reasons. To hold checkpoints of the project's history showing different versions of the project and explaining the changes between one version and the one before it. And for developers to be able to collaborate with each other on the same project as two developers can each be working on a different part of the project, each on a different branch and then once they’re done they can both contribute their individual changes to the main branch of the project. In this class we are using GitHub. GitHub is a version control system that is present online (meaning that it is accessible from any device) and visualizes the versioning of projects in a nice way.

A project's repository normally has a main/master branch that holds the official, release-ready or release-intended version of the project and other branches that are copies of main or of another branch at some point in history, that are used to make contributions, changes or fixes to the code. Every change that occurs on the code of a branch needs to be logged by a commit made by the developer with a commit message that describes what the change was and possibly explains the reason. Each commit will represent a new checkpoint (version) in the branch's history. Once changes on a branch are tested and ready to be included in the main branch a pull request is made by the developers of the branch asking a project manager or lead to review the changes and accept or reject them being merged with main. If two branches made different changes to the same line or block of code and are being merged together a merge conflict will occur, that needs to be resolved by a project manager that will look at the two versions of the code, compare them and choose which of them will be kept in the code and which will be discarded.

A project can exist in multiple places at the same time, although each instance of the project in each place is considered its own version of the project. For example, a project's instance on GitHub is considered to be the online version of the project (online repo), aka mainstream (it is most likely to be considered the mainstream because it will constantly be maintained and updated my the project managers and developers and all other instances will be synced to it). A local instance of the project is most likely to exist on each developer's personal machine. Every instance of the project needs to be frequently synced with the mainstream. Getting an instance synced to new changes that occurred on the mainstream is done by performing a "pull" which is pulling all the changes from mainstream to the local instance. On the other hand, syncing the mainstream with changes that a developer performed on their local repo is done by performing a "push" which is pushing the changes from the local repo to the mainstream.




We also discussed some of the terminology for git. We will also come back to these ideas in greater detail later.

+++

Expand Down Expand Up @@ -342,4 +378,4 @@ When you click that link join the existing team, do not make a new one
## Practice

```{include} ../_practice/2023-09-07.md
```
```
Loading