update and finish lecture 1

main
borb 2 weeks ago
parent 324543ba94
commit d99270507a

File diff suppressed because one or more lines are too long

@ -5,59 +5,113 @@ paginate: true
math: mathjax math: mathjax
theme: buutti theme: buutti
--- ---
<!-- headingDivider: 3 --> <!-- headingDivider: 4 -->
<!-- class: invert --> <!-- class: invert -->
# Project management 1. Git basics # Project management 1. Git basics
## Basic Git workflow
* You have to tell everything you want to happen to Git ***explicitly*** by using ***Git commands***
* A common Git workflow consists of these four steps:
1) ***Edit:*** You make changes in some code file
2) ***Stage:*** You tell Git what files you've changed ([`git add`](#git-add))
3) ***Commit:*** You tell Git what changes you made in that file ([`git commit`](#git-commit))
4) ***Push:*** You upload those changes to a remote repository ([`git push`](#git-push))
## Repositories ## Repositories
* ***Repository*** is essentially a place to store code files in * ***Repository*** ("repo") is essentially a place to store code files in
* Usually, we are dealing with ***two*** repositories: a ***local*** and a ***remote*** one * Usually, we are dealing with ***two*** repositories: a ***local*** and a ***remote*** one
* A local repository is the one on your computer * A local repository is the one on your computer
* A remote repository is stored in a cloud service like GitHub * A remote repository is stored in a cloud service like GitHub
* [Here](https://github.com/borbware/unity-basics-course) is the remote repository for the materials of this course * [Here](https://github.com/borbware/unity-basics-course) is an example of a remote repository on GitHub
* Changes are synced between these two repositories ***manually*** * Changes are synced between these two repositories ***manually***
## `git init` ## Git commands
* You have to tell everything you want to happen to Git ***explicitly*** by using ***Git commands***
* Commands are of the form `git commandname`
* Some commands include ***handles*** that give extra modifiers to the commands:
* `git commandname --handle` or a shorthand `git commandname -h`
## Getting started with GitLab
* Go to [www.gitlab.com](http://www.gitlab.com) and create a new account, if you don't already have one
* If you have an existing GitHub account, you can use it to log into GitLab
* (You'll need to set a password to GitLab after logging in)
* After logging in, you can create a new ***project***
* This is what GitLab calls repositories
* In GitLab, projects are located in ***groups*** or ***namespaces***
* *You should have separate repositories for different programs*
* We will store future home assignments in a single repository
* Larger projects will have their own repositories
### Creating a repository
1) In GitLab, *New Project > Create blank project*
2) Give a name to the project, which automatically becomes its URL (see: Project slug)
3) Use your own user namespace (Good for personal projects)
4) You can set project visibility to Private (only you can see it) or Public (anyone can see it)
5) If you want, you can initialize the repository with a README.md file
* It's a **_Markdown_** file, essentially a text file containing information about the project.
* ***Note:*** These lectures are also written in Markdown, and you can use Markdown syntax to format text on Discord. It's neat!
---
* Initialization needs to be done for every new Git repository <div class='centered'>
![w:950px](imgs/gitlab.png)
</div>
## Initializing a repository
* ***Initialization*** needs to be done for every new Git repository
* There are two ways to initialize a repo: * There are two ways to initialize a repo:
* a) Creating the local repository first: * a) Creating the remote repository first **/** continuing an existing project:
* Use `git init` to make your current folder a new Git repository
* b) Creating the remote repository first **/** continuing an existing project:
* *Clone* a remote repository into your computer (See: [`git clone`](#git-clone)) * *Clone* a remote repository into your computer (See: [`git clone`](#git-clone))
* b) Creating the local repository first with [`git init`](#git-init)
* ***Note:*** Never initialize a Git repository in a cloud storage folder! * ***Note:*** Never initialize a Git repository in a cloud storage folder!
## `.git` folder ### `.git` folder
* Initialization adds a hidden `.git` folder inside a directory * Initialization adds a hidden `.git` folder inside a directory
* This is where Git stores all its repository data. * This is where Git stores all its repository data.
* ***Do not touch it!*** * ***Do not touch it!*** Let Git handle its contents on its own.
* The .git folder ONLY appears in the root directory of the repository * The `.git` folder ONLY appears in the root directory of the repository
* If you see the `.git` folder in any of the subdirectories of the repository, something has gone wrong! * If you see the `.git` folder in any of the subdirectories of the repository, something has gone wrong!
* You have initialized a repository inside repository * You might have initialized a repository inside repository
* This should never happen!
## `git clone`
* Remote repositories have an URL address that can be used to download the code to your machine
* The address can be found under the *Clone* button in the repository webpage
* Use the URL to download a remote repository:
* Run `git clone <URL>`
* Example: `git clone https://github.com/borbware/unity-basics-course.git`
* Remember: this initializes the repo, so `git init` not needed.
* Simplest way to create a new, empty repository:
* 1 - Initialize the repo in the Github/Gitlab/etc website
* 2 - Clone the repo.
## `git status`
* Using the command `git status` shows your current situation. ## Exercise 1a. Cloning a repo
<!--_class: "exercise invert" -->
Create a new repository on GitLab and clone it with HTTPS to your machine.
## Basic Git workflow
* A common Git workflow consists of three steps:
* These are the steps you have to go through every time you want Git to know about the changes you've made!
* So, after writing some changes, you do this:
1) ***Stage:*** You tell Git what files you've changed ([`git add`](#git-add))
2) ***Commit:*** You tell Git what changes you made in that file ([`git commit`](#git-commit))
3) ***Push:*** You upload those changes to a remote repository ([`git push`](#git-push))
### Note: `git status`
* When inside a repository, using the command `git status` shows your current situation.
* If you're unsure what to do, it's never a bad idea to run `git status` * If you're unsure what to do, it's never a bad idea to run `git status`
![bg right width: 80%](imgs/git-status.png) ![bg right width: 80%](imgs/git-status.png)
## `git add` ### `git add`
* Uploading changes to GitHub from your local machine takes three steps (see [Basic Git workflow](1-git-basics#basic-git-workflow) from earlier) * The first step is ***staging*** with `git add`:
* The first phase is ***staging*** with `git add`:
* The command `git add readme.md` stages the file `readme.md` * The command `git add readme.md` stages the file `readme.md`
* After doing it, `git status` tells this: * After doing it, `git status` tells this:
``` ```
@ -68,30 +122,34 @@ theme: buutti
--- ---
* Basically, with `git add file` you tell Git that you want to do *something* with `file`. * With `git add file`, you tell Git that you have done something to `file`, and want to record those changes into Git history.
* ***Note:*** If you just want to push all the changes you've made, you can use `git add .` to stage all the files in your current folder and its subfolders * This doesn't record those changes yet! This is just a preparation step.
* Be careful! Only do this after checking what changes have been made with `git status` * To undo `git add readme.md`, use `git restore --staged readme.md`
* ***Note 2:*** Use `git add <filename> -p` if you only want to stage **some** lines from a file you've worked on. * ***Note 1:*** Use `git add <filename> -p` if you only want to stage ***some*** lines from a file you've worked on.
* ***Note 3:*** The counterpart to `git add` is `git rm`, which removes previously added files from Git's perspective * ***Note 2:*** You can use `git add .` to stage ***all*** the files in your current folder and its subfolders at once
* This is a neat way to shoot yourself in the foot and stage something you didn't intend to!
## `git commit` ### `git commit`
* After you have staged all the files you want, the second step is to ***commit*** your changes * After you have staged all the files you want, the second step is to ***commit*** your changes
* In the commit, you will explain what changes you've made * In the commit, you will explain what changes you've made
* This message will be visible in GitHub * This message will be visible in the Git history
* `git commit -m "add new enemy"` * `git commit -m "add new feature"`
* Every new commit creates a new point in the project timeline.
* You can always jump back between different points (See `git checkout`)
* Commit message should clearly, concisely tell what kind of changes you have made * Commit message should clearly, concisely tell what kind of changes you have made
* Prefer present tense ("Do x" instead of "Did x")
* Every new commit creates a new point in the project timeline.
* You can always jump between different points in timeline (See `git checkout`)
## `git push` ### `git push`
* The third step is ***pushing*** the changes to GitHub * The third step is ***pushing*** the changes to a remote repository
* The previously-made commit action is **local** * The previously-made commit action is ***local***
* No changes have gone to the remote repository yet! * No changes have gone to the remote repository yet!
* To upload changes to the remote repository, use `git push` * To upload changes to the remote repository, use `git push`
* Then you're done! * Then you're done, and you can check your changes are visible in the remote repository
---
#### Setting upstream
* ***Note:*** When pushing for the first time, Git might nag you: * ***Note:*** When pushing for the first time, Git might nag you:
``` ```
fatal: The current branch master has no upstream branch. fatal: The current branch master has no upstream branch.
@ -102,72 +160,69 @@ theme: buutti
* You can just follow its orders (see the command on the third line!) and you're good to go * You can just follow its orders (see the command on the third line!) and you're good to go
* Generally, when Git gives you a warning, error, or some other message, it's a good idea to ***read it and follow the orders***. * Generally, when Git gives you a warning, error, or some other message, it's a good idea to ***read it and follow the orders***.
## Exercise 1b. Pushing changes
<!--_class: "exercise invert" -->
Continue the previous exercise.
1) In your local repository, create a new file `GitTest.md` with some lines of text in it.
2) Commit and push changes to GitLab.
3) Go to GitLab and see that the file is there!
## `git init`
* `git clone` always creates a new folder for a project
* If we have started working on a project without using Git, and have a project folder locally, it might be easier to use `git init` to initialize the project instead
* To do so, navigate to your project folder in the command line, and use `git init` to make your current folder a new Git repository
## `git remote` ## `git remote`
* If you have initialized a Git repo already with `git init`, don't use `git clone`! * Now, your local repo needs to be connected to a remote repository
* Create an ***empty*** remote repo with no Readme file, so your remote repository doesn't clash with your local one.
* If you have initialized a Git repo with `git init`, you can't use `git clone` to connect your local repo to a remote one
* Instead, run `git remote add origin <URL>` * Instead, run `git remote add origin <URL>`
* Here, the name `origin` refers to the remote repository * Here, the name `origin` refers to the remote repository
* `origin` is just the default name for a remote: other names can be used instead! * `origin` is just the default name for a remote: other names can be used as well
* To check which remote repository the current local repository is linked to, use * To check which remote repository the current local repository is linked to, use
* `git remote -v` * `git remote -v`
<!-- _footer: "A repository can have multiple remotes. Use `git remote` to list them all." --> <!-- _footer: "A repository can have multiple remotes. Use `git remote` to list them all." -->
## Exercise 1a. Initializing a repo ## Exercise 2. Initializing a repo the local way
<!--_class: "exercise invert" --> <!--_class: "exercise invert" -->
* Initialize a new repository locally. 1) Initialize a new repository locally with `git init`.
* Create a new file `GitTest.md` with some lines of text in it. 2) Create a new file `GitTest.md` with some lines of text in it.
* Commit changes. 3) Commit changes.
* Create a new empty repository on GitHub. 4) Create a new empty repository on GitHub.
* Use `git remote add origin <url>` to connect your local repo to the GitHub repo. 5) Use `git remote add origin <url>` to connect your local repo to the GitHub repo.
* Push changes to GitHub. Go to GitHub and see that `GitTest.md` is there! 6) Push changes to GitHub. Go to GitHub and see that `GitTest.md` is there!
## `git pull` ## `git pull`
* `git pull` applies changes from the remote repository into the local repository * `git pull` applies changes from the remote repository into the local repository
* Counterpart to `push` * Counterpart to `push`, but does actually two commands in one
* Very common when working in a team * It's the same thing as doing `git fetch <branch>`, and then `git merge <branch>`"
* Using `git pull` is very common when working in a team
* **Note**: During teamwork it's a good idea to ***always pull before pushing*** * **Note**: During teamwork it's a good idea to ***always pull before pushing***
* If you only work alone on a single computer, seldom needed * If you only work alone on a single computer, seldom needed
<!-- _footer: "`git pull` is actually two commands in one. It's the same thing as doing `git fetch <branch>` + `git merge <branch>`" -->
## `git clone`
* Remote repositories have an URL address that can be used to download the code to your machine
* The address can be found under the *Clone* button in the repository webpage
* Use the URL to download a remote repository:
* Run `git clone <URL>`
* Example: `git clone https://github.com/borbware/unity-basics-course.git`
* Remember: this initializes the repo, so `git init` not needed.
* Simplest way to create a new, empty repository:
* 1 - Initialize the repo in the Github/Gitlab/etc website
* 2 - Clone the repo.
## Exercise 1b. Cloning a repo
<!--_class: "exercise invert" -->
* Create a new repository on GitHub and clone it with HTTPS to your machine.
* Then, create a new file `GitTest.md` with some lines of text in it.
* Commit and push changes to GitHub.
* Go to GitHub and see that the file is there!
## Extra: HTTPS vs SSH ## Extra: HTTPS vs SSH
<!-- _class: "extra invert" --> <!-- _class: "extra invert" -->
* There are two ways to communicate with GitHub, ***HTTPS*** and ***SSH*** * There are two ways to communicate with GitHub, ***HTTPS*** and ***SSH***
* HTTPS: `https://github.com/borbware/unity-basics-course.git` * HTTPS: `https://github.com/borbware/unity-basics-course.git`
* the easier way * The easier way
* you log in with your GitHub credentials that get stored in the Git Credential Manager * You log in with your GitLab credentials that get stored in the Git Credential Manager
* SSH: `git@github.com:borbware/unity-basics-course.git` * SSH: `git@github.com:borbware/unity-basics-course.git`
* [Connecting to GitLab with SSH](https://docs.gitlab.com/user/ssh/)
* [Connecting to GitHub with SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) * [Connecting to GitHub with SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh)
* You need to generate a computer-specific SSH key and add it to your GitHub settings * You need to generate a computer-specific ***SSH key*** and add it to your GitHub settings
## `.gitignore` ## `.gitignore`
* Sometimes your project has local files that should ***NOT*** be uploaded to GitHub * Sometimes your project has local files that should ***NOT*** be uploaded to GitLab
* List those files in a `.gitignore` file in your Git project folder * List those files in a `.gitignore` file in your Git project folder
* You can create it by yourself and define file names or folders which Git will then ignore in the commits, e.g., * You can create it by yourself and define file names or folders which Git will then ignore in the commits, e.g.,
``` ```
@ -175,7 +230,7 @@ theme: buutti
/folder /folder
*.html *.html
``` ```
* ***Note:*** If you add a file to `.gitignore` that was committed earlier, Git doesn't "forget" it automatically. * ***Note:*** If you add a file to `.gitignore` that was committed earlier, Git doesn't "forget" it automatically
* You can make Git forget it with `git rm --cached filename` * You can make Git forget it with `git rm --cached filename`
## VS code: Source control ## VS code: Source control
@ -195,35 +250,39 @@ theme: buutti
![bg height:90%](imgs/vscode-working-tree.png) ![bg height:90%](imgs/vscode-working-tree.png)
## Exercise 2. Git collaboration ## Exercise 3. Git collaboration
<!--_class: "exercise invert" --> <!--_class: "exercise invert" -->
* Work on this exercise with your group. Work on this exercise with your group.
* Choose someone's test repository from Exercise 1b to use in this exercise.
* While others clone the repo to their machine, the owner should add other group members as collaborators of the repo in the repository's settings on GitHub. 1) Choose someone's test repository from Exercise 1a to use in this exercise.
* Then, everyone should make changes to the markdown file in the repository! 2) While others clone the repo to their machine, the owner should add other group members as ***collaborators*** of the repo in the repository's settings on GitLab.
* Left sidebar: *Manage > Members*
* Click *Invite members* and add others as *Developer* or *Maintainer*.
3) Then, everyone should make changes to the markdown file in the repository!
What happens if you make changes to the same line simultaneously? What happens if you make changes to the same line simultaneously?
<!-- _footer: In GitLab, the setting is under Manage > Members --> ## Note about longer `push` and `pull` commands
* After initialization, why don't `push` and `pull` commands work?
* Answer: because when you don't clone the repo, but add the remote into an empty repo with `git remote add origin`, the remote and local branches aren't connected yet.
* Thus, Git doesn't yet know which ***branch*** to pull from
* You can decide it manually on each pull with `git pull origin main`
* The branches can be connected in the first `push` with `git push --set-upstream origin main`
* Afterwards, we can just use `git push` and `git pull`.
## Troubleshooting: master vs. main ## Troubleshooting: `master` vs. `main`
``` ```
error: failed to push some refs to [your-url] error: failed to push some refs to [your-url]
``` ```
* Possible reason: GitHub has a `main` branch, while your local repository has `master` * Possible reason: GitLab has a `main` branch, while your local repository has `master`
* ***Fix:*** Run `git branch -m main` to rename your local `master` to `main` * ***Fix:*** Run `git branch -m main` to rename your local `master` to `main`
## Note about longer `push` and `pull` commands
* After initialization, why do I have to use longer `push` and `pull` commands?
* Short answer: because we didn't clone the repo, but rather added the remote into an empty one with `git remote add origin`.
* `git pull origin main`: After adding a remote, we don't yet know which ***branch*** to pull from. `main` (or `master`!) is the default branch
* `git push --set-upstream origin main`: In the first `push`, we decide which branch to link our current branch into.
* Afterwards, we can just use `git push` and `git pull`.
## Reading ## Reading
* [Using version control in VS code](https://code.visualstudio.com/docs/sourcecontrol/overview) * [Using version control in VS code](https://code.visualstudio.com/docs/sourcecontrol/overview)
* [GitHub Git cheat sheet](https://education.github.com/git-cheat-sheet-education.pdf)

Binary file not shown.

After

Width:  |  Height:  |  Size: 82 KiB

Loading…
Cancel
Save