* 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 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`
## `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 phase is ***staging*** with `git add`:
* The first step is ***staging*** with `git add`:
* The command `git add readme.md` stages the file `readme.md`
* 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`.
* ***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
* Be careful! Only do this after checking what changes have been made with `git status`
* ***Note 2:*** 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
* With `git add file`, you tell Git that you have done something to `file`, and want to record those changes into Git history.
* This doesn't record those changes yet! This is just a preparation step.
* To undo `git add readme.md`, use `git restore --staged readme.md`
* ***Note 1:*** Use `git add <filename> -p` if you only want to stage ***some*** lines from a file you've worked on.
* ***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
* In the commit, you will explain what changes you've made
* This message will be visible in GitHub
* `git commit -m "add new enemy"`
* In the commit, you will explain what changes you've made
* This message will be visible in the Git history
* `git commit -m "add new feature"`
* 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 back between different points (See `git checkout`)
* Commit message should clearly, concisely tell what kind of changes you have made
* 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 previously-made commit action is **local**
* The third step is ***pushing*** the changes to a remote repository
* The previously-made commit action is ***local***
* No changes have gone to the remote repository yet!
* 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:
```
fatal: The current branch master has no upstream branch.
@ -101,73 +159,70 @@ theme: buutti
```
* 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***.
## 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`
* 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>`
* 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
* `git remote -v`
<!-- _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" -->
* Initialize a new repository locally.
* Create a new file `GitTest.md` with some lines of text in it.
* Commit changes.
* Create a new empty repository on GitHub.
* 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!
1) Initialize a new repository locally with `git init`.
2) Create a new file `GitTest.md` with some lines of text in it.
3) Commit changes.
4) Create a new empty repository on GitHub.
5) Use `git remote add origin <url>` to connect your local repo to the GitHub repo.
6) Push changes to GitHub. Go to GitHub and see that `GitTest.md` is there!
## `git pull`
* `git pull` applies changes from the remote repository into the local repository
* Counterpart to `push`
* Very common when working in a team
* Counterpart to `push`, but does actually two commands in one
* 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***
* 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
* [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)
* 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`
* 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
* 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
*.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`
## VS code: Source control
@ -195,35 +250,39 @@ theme: buutti
## Exercise 2. Git collaboration
## Exercise 3. Git collaboration
<!--_class: "exercise invert" -->
* 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.
* Then, everyone should make changes to the markdown file in the repository!
Work on this exercise with your group.
1) Choose someone's test repository from Exercise 1a to use in this exercise.
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?
<!-- _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]
```
* 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`
## 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
* [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)
borb
2 weeks ago
