<h3id="why-version-control">Why version control?</h3>
<ul>
<lidata-marpit-fragment="1">Without version control, only one version of your code exists
<ul>
<lidata-marpit-fragment="2"><em>What happens when you realize you made a mistake and need to roll back changes you've made?</em></li>
</ul>
</li>
<lidata-marpit-fragment="3">You could use manual backups, or a cloud storage service
<ul>
<lidata-marpit-fragment="4"><em>What happens if two people connect to a cloud service and edit the same file?</em></li>
<lidata-marpit-fragment="5">Or maybe not even the same file... <em>What happens when you and your teammate have made changes to code and you need to combine your work into a single, working version?</em></li>
</ul>
</li>
<lidata-marpit-fragment="6">Version control handles all the problems above, and you can focus on the important part: programming!
<ul>
<lidata-marpit-fragment="7">You can even try out some big changes that break your software completely</li>
<lidata-marpit-fragment="8">If that doesn't work out, just roll back into the last working version!</li>
<lidata-marpit-fragment="1">Git <em>could</em> be used locally, but its usage is almost always combined with a developer platform — a remote storage service like <ahref="https://github.com/">GitHub</a>, <ahref="https://gitlab.com/">GitLab</a> or <ahref="https://bitbucket.com/">BitBucket</a>
<ul>
<lidata-marpit-fragment="2">These services can also double as a programming portfolio</li>
<lidata-marpit-fragment="2">These services can also double as a programming portfolio that can help getting hired into the industry</li>
<lidata-marpit-fragment="3">Commonly used in both open source and commercial projects</li>
</ul>
</li>
<lidata-marpit-fragment="4">In Buutti's trainings, GitLab is most commonly used</li>
<lidata-marpit-fragment="4">In Buutti's trainings, <em><strong>GitLab</strong></em> is most commonly used</li>
<lidata-marpit-fragment="1">Git is operated via the <em><strong>command line</strong></em>, a.k.a, the <em><strong>terminal</strong></em></li>
@ -145,11 +177,14 @@
<lidata-marpit-fragment="4">Linux, (also included in the Windows Git install): <em><strong>bash</strong></em></li>
</ul>
</li>
<lidata-marpit-fragment="5">We're using PowerShell, which can be accessed inside VS Code</li>
<lidata-marpit-fragment="5">We're using PowerShell, which can be accessed inside <ahref="https://code.visualstudio.com/docs/languages/powershell">VS Code</a> or <ahref="https://learn.microsoft.com/en-us/visualstudio/ide/reference/command-prompt-powershell?view=vs-2022">Visual Studio</a>
<ul>
<lidata-marpit-fragment="6">In VS Code, open/close terminal by pressing <em><strong>CTRL+Ö</strong></em> (in the Fin/Swe layout)</li>
<h3id="basic-commands-and-the-working-directory">Basic commands and the working directory</h3>
<ul>
<lidata-marpit-fragment="1">To do actions in Git, you don't press buttons, you write commands</li>
@ -171,13 +206,13 @@
<lidata-marpit-fragment="8"><em><strong>Note</strong></em>: <code>..</code> is a shorthand for to the parent directory, <code>.</code> for the current directory</li>
<h2id="extra-help-this-is-horrible">Extra: Help, this is horrible!</h2>
<ul>
<lidata-marpit-fragment="1">Do you feel more at home in graphical UIs?
<ul>
<lidata-marpit-fragment="2">There are also graphical user interfaces for Git like <ahref="https://www.gitkraken.com/">GitKraken</a>, <ahref="https://www.sublimemerge.com/">Sublime Merge</a> or <ahref="https://desktop.github.com/">GitHub Desktop</a> (GitHub only)</li>
<lidata-marpit-fragment="2">There are also graphical user interfaces for Git like <ahref="https://www.sublimemerge.com/">Sublime Merge</a>, <ahref="https://www.gitkraken.com/">GitKraken</a>, or <ahref="https://desktop.github.com/">GitHub Desktop</a> (for use with GitHub only)</li>
<lidata-marpit-fragment="3">VS Code also has very useful graphical tools for Git (more about them later!)</li>
* Git is a version control tool originally created by Linus Torvalds in 2005
* Git is a ***version control*** tool originally created by Linus Torvalds in 2005
* Keeps track of code changes
* Can be used to backup code in the cloud
* Enables cooperation with other team members
* Ubiquitous in software development
### Why version control?
* Without version control, only one version of your code exists
* *What happens when you realize you made a mistake and need to roll back changes you've made?*
* You could use manual backups, or a cloud storage service
* *What happens if two people connect to a cloud service and edit the same file?*
* Or maybe not even the same file... *What happens when you and your teammate have made changes to code and you need to combine your work into a single, working version?*
* Version control handles all the problems above, and you can focus on the important part: programming!
* You can even try out some big changes that break your software completely
* If that doesn't work out, just roll back into the last working version!
### Git vs cloud storage
* Git is different from cloud storage services like Dropbox, Google Drive or OneDrive
* Instead of automatic syncing, you deliberately *push to* and *pull from* the cloud
* Cloud services are easier for starters
* Cloud services are easier for beginners
* ...but in projects of more than one person, tracking changes would be a pain
* Git has a steep learning curve
* To ease things, there are some visual tools like **Sourcetree** or **Sublime Merge**
* To use them effectively, you still need to understand how Git works, though
* Git is used via the ***terminal*** and has a steep learning curve
* There are some visual tools like **Sourcetree** or **Sublime Merge**
* To use them effectively, though, *you must still understand how Git works*
* Git *could* be used locally, but its usage is almost always combined with a developer platform — a remote storage service like [GitHub](https://github.com/), [GitLab](https://gitlab.com/) or [BitBucket](https://bitbucket.com/)
* These services can also double as a programming portfolio
* These services can also double as a programming portfolio that can help getting hired into the industry
* Commonly used in both open source and commercial projects
* In Buutti's trainings, GitLab is most commonly used
* In Buutti's trainings, ***GitLab*** is most commonly used
</div>
<divmarkdown='1'>
</div>
</div>
## Setup
* Install Git
* Installing Git:
* Windows/Mac: [git-scm.com](https://git-scm.com)
* Installation instructions are included in the following slides.
* If a setting is not mentioned in the instructions, you can leave it as the default option.
* Linux, (also included in the Windows Git install): ***bash***
* We're using PowerShell, which can be accessed inside VS Code
* In VS Code, open/close terminal by pressing ***CTRL+Ö*** (in the Fin/Swe layout)
* We're using PowerShell, which can be accessed inside [VS Code](https://code.visualstudio.com/docs/languages/powershell) or [Visual Studio](https://learn.microsoft.com/en-us/visualstudio/ide/reference/command-prompt-powershell?view=vs-2022)
* In VS Code, open/close terminal by pressing ***CTRL+Ö*** (in the Fin/Swe layout)
* There are also graphical user interfaces for Git like [GitKraken](https://www.gitkraken.com/), [Sublime Merge](https://www.sublimemerge.com/) or [GitHub Desktop](https://desktop.github.com/) (GitHub only)
* There are also graphical user interfaces for Git like [Sublime Merge](https://www.sublimemerge.com/), [GitKraken](https://www.gitkraken.com/), or [GitHub Desktop](https://desktop.github.com/) (for use with GitHub only)
* VS Code also has very useful graphical tools for Git (more about them later!)
* However, the GUIs make ***a lot*** more sense after you've understood the Git commands that those GUIs still execute under the hood
* There is no free lunch here
## Btw: Config
## Note: Config
* To configure your Git username for every project:
* After installation, you may configure your Git username for every project:
* Use `git config --global user.name "myUserName"`
* and `git config --global user.email "my.email.address@domain.com"`
* If you do not do this, Git will ask to do it anyway at some point
* 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)
<lidata-marpit-fragment="1">A Git repository can have multiple <em><strong>branches</strong></em></li>
<lidata-marpit-fragment="2">By default, a Git repository has only one branch
<ul>
<lidata-marpit-fragment="3">named either <code>master</code> or <code>main</code></li>
<lidata-marpit-fragment="3">named usually <code>main</code> or <code>master</code></li>
</ul>
</li>
<lidata-marpit-fragment="4">Using multiple branches makes it possible to work on new features step by step in their own <em><strong>feature branches</strong></em>
<ul>
<lidata-marpit-fragment="5">Meanwhile, the <code>master</code> branch is kept clean and in a working state</li>
<lidata-marpit-fragment="6">Only when the feature is completed, the branch is merged into the <code>master</code> branch!</li>
<lidata-marpit-fragment="5">Meanwhile, the <code>main</code> branch is kept clean and in a working state</li>
<lidata-marpit-fragment="6">Only when the feature is completed, the branch is merged into the <code>main</code> branch!</li>
<lidata-marpit-fragment="1">Even though your local repository can have multiple branches, only one of them is <em>active</em> at a given time</li>
<lidata-marpit-fragment="2"><code>git status</code> tells you firsthand which branch you are on: <code>On branch master</code></li>
<lidata-marpit-fragment="2"><code>git status</code> tells you firsthand which branch you are on:<preis="marp-pre"data-auto-scaling="downscale-only"><code>On branch main
<h3id="local-vs-remote-branches">Local vs. remote branches</h3>
<ul>
<lidata-marpit-fragment="1"><code>git branch <branchName></code> only creates a local branch</li>
<lidata-marpit-fragment="2">When you try to push changes from a new local branch, Git nags you that a matching remote branch doesn't yet exist
<lidata-marpit-fragment="1"><code>git branch <branchname></code> only creates a <em><strong>local</strong></em> branch</li>
<lidata-marpit-fragment="2">When you try to push changes from a new local branch for the first time, Git nags you that a matching remote branch doesn't yet exist
<ul>
<lidata-marpit-fragment="3">Git tells you how to create the remote branch:
<lidata-marpit-fragment="2">It's a shorthand for <code>git branch <branchName></code> + <code>git checkout <branchName></code></li>
<lidata-marpit-fragment="2">It's a shorthand for <code>git branch <branchname></code> + <code>git checkout <branchname></code></li>
</ul>
</li>
<lidata-marpit-fragment="3">Get a list of local branches with <code>git branch</code>
@ -86,102 +89,116 @@
<lidata-marpit-fragment="4">...and all branches (incl. the remote ones) with <code>git branch -a</code></li>
</ul>
</li>
<lidata-marpit-fragment="5">Delete a local branch with <code>git branch -d <branchName></code>
<lidata-marpit-fragment="5">Delete a local branch with <code>git branch -d <branchname></code>
<ul>
<lidata-marpit-fragment="6">Remote branch can be deleted in the GitHub/etc website</li>
<lidata-marpit-fragment="7">...or with <code>git push origin -d <branchName></code></li>
<lidata-marpit-fragment="6">Remote branch can be deleted in the GitLab/etc website
<ul>
<lidata-marpit-fragment="7">...or with <code>git push origin -d <branchname></code></li>
</ul>
</li>
<lidata-marpit-fragment="8"><em><strong>Note:</strong></em> If deleted remote branches still show up in <code>git branch -a</code>, you can use the command <code>git remote prune origin</code> to remove them from the list.</li>
<lidata-marpit-fragment="1">So you've been working on a feature branch. What next?</li>
<lidata-marpit-fragment="2">When the feature is done (and all the broken things fixed), you want to apply your changes back to <code>master</code></li>
<lidata-marpit-fragment="3">For this, we use <code>git merge <branchToMerge></code>
<ul>
<lidata-marpit-fragment="4">It applies changes from <code><branchToMerge></code> to the <em><strong>current active branch</strong></em></li>
</ul>
</li>
<lidata-marpit-fragment="5"><code>master</code> branch is usually (and should be) protected, so we can't merge our new code to <code>master</code> directly</li>
<lidata-marpit-fragment="6">Instead, we do the <em>inverse</em>.</li>
<lidata-marpit-fragment="1">When a feature is done (and all the broken things fixed), you want to apply, i.e., <em><strong>merge</strong></em> your changes from the feature branch to the <code>main</code> branch</li>
<lidata-marpit-fragment="3">Pull changes from GitHub/etc</li>
<lidata-marpit-fragment="4">Checkout the feature branch</li>
<lidata-marpit-fragment="5">Merge the contents of <code>master</code> to <code>featureBranch</code> with <code>git merge master</code></li>
<lidata-marpit-fragment="4">(Someone else might have done changes to it while you were working on your feature!)</li>
</ul>
<olstart="2">
<lidata-marpit-fragment="6">Then, create a <em><strong>pull request</strong></em> on GitHub/etc (In GitLab, it's called <em><strong>merge request</strong></em>!)</li>
</ol>
</li>
<lidata-marpit-fragment="5">Then, merge your local feature branch to your local main branch with<br/>
<code>git merge <featurebranch></code>
<ul>
<lidata-marpit-fragment="7">This creates a formal process for merging your <em>remote</em> feature branch to remote <code>master</code></li>
<lidata-marpit-fragment="8">This adds a layer of protection to the <code>master</code> branch: no direct merging!</li>
<lidata-marpit-fragment="6">It applies changes from <code><featurebranch></code> to the <em><strong>current active branch</strong></em></li>
<lidata-marpit-fragment="7">This is where <em><strong>conflicts</strong></em> might happen (more about them <ahref="#conflicts">later</a>)</li>
</ul>
</li>
<lidata-marpit-fragment="8">Then, push your changes to remote with <code>git push</code></li>
<h3 id="merging-with-a-pullmerge-request">Merging with a pull/merge request</h3>
<ul>
<lidata-marpit-fragment="1">UI of a new pull request (<em>Pull requests > New pull request</em>) can be confusing...
<lidata-marpit-fragment="1">The aforementioned procedure isn't what we usually do, though!</li>
<lidata-marpit-fragment="2"><code>main</code> branch should be <em><strong>protected</strong></em> so we can't merge our new code there directly
<ul>
<lidata-marpit-fragment="2"><em>base</em> is the branch you're merging, <em>compare</em> is the branch you're merging into!</li>
<lidata-marpit-fragment="3">Instead, we do the <em>inverse</em>.</li>
</ul>
</li>
</ul>
<ol>
<lidata-marpit-fragment="4">First, checkout the <code>main</code> branch with <code>git checkout main</code></li>
<lidata-marpit-fragment="5">Then, do a <code>git pull</code> so you have the newest version of the <code>main</code> branch</li>
<lidata-marpit-fragment="6">Then, <em><strong>checkout back to the feature branch</strong></em>.</li>
<lidata-marpit-fragment="7">Merge your local <code>main</code> branch to your local <code>featurebranch</code> with<br/>
<code>git merge main</code></li>
<lidata-marpit-fragment="8">Then, create a <em><strong>merge request</strong></em> on GitLab (it's <em><strong>pull request</strong></em> on GitHub—they're the same thing, just named from different points of view.)</li>
<lidata-marpit-fragment="1"><em><strong>Pro tip:</strong></em> If you're working on your feature branch, you can merge changes from the <code>main</code> branch without changing branches altogether.</li>
</ul>
<ol>
<lidata-marpit-fragment="1">Pull remote changes to your local <code>master</code>.
<lidata-marpit-fragment="2">Update your local main branch with <code>git fetch origin main:main</code></li>
<lidata-marpit-fragment="3">Merge your local <code>main</code> branch to your local <code>featurebranch</code> with<br/>
<code>git merge main</code></li>
<lidata-marpit-fragment="4">Then, create a merge request/pull request</li>
</ol>
<ul>
<lidata-marpit-fragment="5">Much easier this way!
<ul>
<lidata-marpit-fragment="2"><em><strong>Pro tip:</strong></em> If you're on your feature branch, you can do this quickly without changing branches with<br/>
<code>git fetch origin master:master</code></li>
<lidata-marpit-fragment="6">But what is the merge request, anyway?</li>
</ul>
</li>
<lidata-marpit-fragment="3">Merge changes from <code>master</code> to your local feature branch.</li>
<lidata-marpit-fragment="4">Fix the ensuing <em><strong>conflicts</strong></em> (see <ahref="#3-conflicts">next section</a>)</li>
<lidata-marpit-fragment="5">Push your new local branch to GitHub/etc</li>
<lidata-marpit-fragment="3">Someone else might have done changes to it while you were working on your feature!</li>
<lidata-marpit-fragment="1">Merge/pull request is a formal process for merging your <em>remote</em> feature branch straight to the remote <code>main</code> branch</li>
<lidata-marpit-fragment="2">This adds a layer of protection to the <code>main</code> branch: no direct merging to the <code>main</code> branch!</li>
<lidata-marpit-fragment="3">Additionally, a <em><strong>code review</strong></em> can happen at this stage:
<ul>
<lidata-marpit-fragment="4">If a code maintainer thinks your merge request needs some modifications, you can make changes to the feature branch accordingly</li>
<lidata-marpit-fragment="5">A merge request is branch-specific, so when you push your changes to your feature branch, the merge request is automatically updated as well.</li>
<lidata-marpit-fragment="6">If this procedure is followed strictly, no bad code should get into the main branch!</li>
</ul>
</li>
<lidata-marpit-fragment="4">Then, merge <code><featureBranch></code> to <code>master</code> with <code>git merge <featureBranch></code>
<lidata-marpit-fragment="1">Sometimes two people have made changes in the same lines of code!
<ul>
<lidata-marpit-fragment="2">This leads to a conflict.</li>
<lidata-marpit-fragment="2">This leads to a <em><strong>conflict</strong></em>.</li>
</ul>
</li>
<lidata-marpit-fragment="3">Let's assume we're trying to merge changes from featureBranch to master.</li>
<lidata-marpit-fragment="4">If a conflict happens, the merge does not conclude automatically. Instead, we need to <em><strong>fix all the conflicts</strong></em> by hand and then <em><strong>conclude the merge</strong></em> with some commands.</li>
<lidata-marpit-fragment="5">Conflicting lines of code are framed by some <code><<<<<<< garbage ======= symbols >>>>>>></code> we don't yet understand</li>
<lidata-marpit-fragment="6">Before we can conclude the merge, we need to get rid of the garbage.</li>
<lidata-marpit-fragment="3">Let's assume we're trying to merge changes from <code>featurebranch</code> to <code>main</code>.</li>
<lidata-marpit-fragment="4">If a conflict happens, the merge does not conclude automatically.</li>
<lidata-marpit-fragment="5">Instead, we need to <em><strong>fix all the conflicts</strong></em> by hand and then <em><strong>conclude the merge</strong></em> with some commands.</li>
<lidata-marpit-fragment="6">Conflicting lines of code are framed by some <code><<<< garbage ==== symbols >>>></code><br/>
we don't yet understand</li>
<lidata-marpit-fragment="7">Before we can conclude the merge, we need to get rid of the garbage.</li>
<lidata-marpit-fragment="1"><em><strong>Current change</strong></em> is between <code><<<<<<<</code> and <code>=======</code>: old code in <code>master</code></li>
<lidata-marpit-fragment="2"><em><strong>Incoming change</strong></em> is between <code>>>>>>>></code> and <code>=======</code>: new code from <code>featureBranch</code></li>
<lidata-marpit-fragment="3">Use your text editor to choose which (or some combination of both) you want to preserve</li>
<lidata-marpit-fragment="1"><em><strong>Current change</strong></em> is between <code><<<<<<<</code> and <code>=======</code>
<ul>
<lidata-marpit-fragment="2">old code that was already in <code>main</code></li>
</ul>
</li>
<lidata-marpit-fragment="3"><em><strong>Incoming change</strong></em> is between <code>>>>>>>></code> and <code>=======</code>
<ul>
<lidata-marpit-fragment="4">new code coming from <code>featurebranch</code></li>
</ul>
</li>
<lidata-marpit-fragment="5">Use your text editor to choose which (or some combination of both) you want to preserve</li>
<lidata-marpit-fragment="1">VS Code gives us tools to make conflict resolution a quick process</li>
<lidata-marpit-fragment="2">Click which lines of code you want to preserve:
<lidata-marpit-fragment="1">VS Code gives us tools to make conflict resolution a relatively quick process</li>
<lidata-marpit-fragment="2">Choose your preference:
<ul>
<lidata-marpit-fragment="3"><em><strong>Accept Current Change</strong></em> (old code is preserved, new code removed)</li>
<lidata-marpit-fragment="4"><em><strong>Accept Incoming Change</strong></em> (new code is preserved, old code removed)</li>
<lidata-marpit-fragment="5"><em><strong>Accept Both Changes</strong></em> (both are preserved)</li>
<lidata-marpit-fragment="3"><em><strong>Accept Current Change</strong></em><br/>
(old code is preserved,<br/>
new code is removed)</li>
<lidata-marpit-fragment="4"><em><strong>Accept Incoming Change</strong></em> (new code is preserved,<br/>
old code is removed)</li>
<lidata-marpit-fragment="5"><em><strong>Accept Both Changes</strong></em><br/>
(both are preserved)</li>
</ul>
</li>
</ul>
</section>
</foreignObject><foreignObjectwidth="1280"height="720"data-marpit-advanced-background="pseudo"><sectiondata-marpit-fragments="5"data-paginate="true"data-class="invert"data-heading-divider="3"data-theme="79cyd3oru1j29cg66ofi9uvfluhymakxwh6huu59m5" lang="en-US"class="invert"data-marpit-pagination="17" style=""data-marpit-pagination-total="27"data-marpit-advanced-background="pseudo"data-marpit-advanced-background-split="right"></section></foreignObject></svg><svgdata-marpit-svg=""viewBox="0 0 1280 720"><foreignObjectwidth="1280"height="720"><sectionid="18" data-marpit-fragments="4" data-paginate="true"data-class="invert"data-footer="If VS code is not configured properly as Git's text editor, and you encounter an error, run `git config core.editor code --wait`"data-heading-divider="3"data-theme="79cyd3oru1j29cg66ofi9uvfluhymakxwh6huu59m5" lang="en-US"class="invert"data-marpit-pagination="18" style="--paginate:true;--class:invert;--heading-divider:3;--theme:79cyd3oru1j29cg66ofi9uvfluhymakxwh6huu59m5;" data-marpit-pagination-total="27">
<h2id="after-resolving-the-conflict">After resolving the conflict</h2>
<h3id="after-resolving-the-conflict">After resolving the conflict</h3>
<ul>
<lidata-marpit-fragment="1">After resolving conflicting files, use <code>git add <filename></code> to add them to the commit</li>
<lidata-marpit-fragment="1">After resolving all conflicting files, use <code>git add <filename></code> to add them to the commit</li>
<lidata-marpit-fragment="2">Then use <code>git commit</code> to apply changes (without a message! no <code>-m</code>)
<ul>
<lidata-marpit-fragment="3">Close the automatically opened <code>COMMITMSG</code> file. This should finish the merge.</li>
<lidata-marpit-fragment="3">Close the automatically opened <code>COMMITMSG</code> file.</li>
<lidata-marpit-fragment="4">This finishes the merge.</li>
</ul>
</li>
<lidata-marpit-fragment="4">Then just <code>git push</code> to apply changes in the remote repository</li>
<lidata-marpit-fragment="5">Then just <code>git push</code> to apply changes in the remote repository</li>
<lidata-marpit-fragment="6"><em><strong>Note:</strong></em> If VS code is not configured properly as the Git's text editor, and you encounter an error, run <code>git config core.editor code --wait</code></li>
</ul>
<footer>If VS code is not configured properly as Git's text editor, and you encounter an error, run <code>git config core.editor code --wait</code></footer>
<lidata-marpit-fragment="1">Create a new branch in your local repository, but do not checkout it just yet.</li>
<lidata-marpit-fragment="2">First, we simulate your teammate's changes by making changes to the <code>master</code> branch directly: On the <code>master</code> branch, make some changes to <code>GitTest.md</code>, and <strong>add & commit</strong>.</li>
<lidata-marpit-fragment="2">On the <code>main</code> branch, make some changes to <code>GitTest.md</code>, and <strong>add & commit</strong>.</li>
<lidata-marpit-fragment="3">Then, checkout the new feature branch.</li>
<lidata-marpit-fragment="4">Then, make some other changes to GitTest.md to the same line as before, <strong>add & commit</strong>.</li>
<lidata-marpit-fragment="5">Then, merge the changes from the <code>master</code> branch to your feature branch by using <code>git merge</code></li>
<lidata-marpit-fragment="4">Make some <em><strong>other</strong></em> changes to GitTest.md to the same line as before, <strong>add & commit</strong>.</li>
<lidata-marpit-fragment="5">Then, merge the changes from the <code>main</code> branch to your feature branch by using <code>git merge</code></li>
<lidata-marpit-fragment="6">Fix the ensuing conflicts, add & commit & push.</li>
<lidata-marpit-fragment="7">Now you can create a pull request to merge your changes to the master branch.</li>
<h3 id="reverting-one-file-to-a-previous-state">Reverting one file to a previous state</h3>
<ul>
<lidata-marpit-fragment="1">Sometimes you want to revert just one file to its previous state</li>
<lidata-marpit-fragment="2">For that, you need to figure out the commit hash of the state you want to return to</li>
<lidata-marpit-fragment="3">Find that out in one of the following methods:
<lidata-marpit-fragment="2">You can use <code>git checkout <commit-hash> -- <filename></code> to time travel just that file to how it was in that commit</li>
<lidata-marpit-fragment="3">For this, you of course need to figure out the commit hash you want to return to</li>
<lidata-marpit-fragment="4">Find that out in one of the following methods:
<h2id="collaboration-in-unity">Collaboration in Unity</h2>
<ul>
<lidata-marpit-fragment="1"><em><strong>The zeroth rule:</strong></em> Make sure that everyone on team uses the same Unity and package versions.</li>
<lidata-marpit-fragment="2"><em><strong>The first rule:</strong></em> Don't ever work on the same thing simultaneously.</li>
<lidata-marpit-fragment="3"><em><strong>The second rule:</strong></em> When you do break rule #1, make necessary changes in communication so you won't break it again.</li>
<lidata-marpit-fragment="4">Be sure to communicate about <em><strong>scene ownership</strong></em>
<ul>
<lidata-marpit-fragment="5">Scenes are not code files, so you can't easily merge changes if two people have worked on them</li>
<lidata-marpit-fragment="6">Thus, the <em><strong>Scene Owner</strong></em> will be the only person on the team who should be working on a certain scene</li>
<lidata-marpit-fragment="7">If a scene needs GameObject contributions from others, they can create prefabs that the Scene Owners then add to their scene</li>
<h2id="exercise-3-branching-team-effort">Exercise 3. Branching team effort</h2>
<p>Work as a group for this assignment. Continue Exercise 2 from <ahref="1-git-basics">Git basics</a>.</p>
<ol>
<lidata-marpit-fragment="1">Every group member: create your own individual branch from the <code>main</code> branch</li>
<lidata-marpit-fragment="2">Then, make some changes to the <code>GitTest.md</code> file.
<ul>
<lidata-marpit-fragment="1">Work as a group for this assignment.</li>
<lidata-marpit-fragment="2">Continue Exercise 2 from <ahref="1-git-basics">Git basics</a>.</li>
<lidata-marpit-fragment="3">Every group member creates an individual branch from the master, and makes some changes to the <code>GitTest.md</code> file.</li>
<lidata-marpit-fragment="4">Add new files as well, at least one per group member.</li>
<lidata-marpit-fragment="5">Do not tell other group members what you're going to change! :D</li>
<lidata-marpit-fragment="6">Then, merge the changes back to the master branch. Fix ensuing conflicts, if any appear.</li>
<lidata-marpit-fragment="3">Do not tell other group members what you're going to change! :D</li>
</ul>
</li>
<lidata-marpit-fragment="4">Add new files as well, at least one file per group member.</li>
<lidata-marpit-fragment="5">Then, merge the changes back to the <code>main</code> branch. Fix ensuing conflicts, if any appear.</li>
<h2id="very-extra-interactive-git-rebase--i">Very extra: Interactive <code>git rebase -i</code></h2>
<ul>
<lidata-marpit-fragment="1"><code>git rebase</code> also has a hidden <em><strong>interactive</strong></em> mode used with <code>git rebase -i</code></li>
<lidata-marpit-fragment="2">This is a true swiss army knife of a Git tool for rewriting Git history</li>
<lidata-marpit-fragment="3">It can:
<ul>
<lidata-marpit-fragment="9"><em><strong>Note:</strong></em> A good link for <ahref="https://borbware.github.io/unity-basics-course/project-management/2-git-continued-slides.html">understanding rebase</a></li>
<lidata-marpit-fragment="4">Squash commits into one</li>
<lidata-marpit-fragment="5">Cherry-pick only certain commits</li>
* A Git repository can have multiple ***branches***
* By default, a Git repository has only one branch
* named either `master` or `main`
* named usually `main` or `master`
* Using multiple branches makes it possible to work on new features step by step in their own ***feature branches***
* Meanwhile, the `master` branch is kept clean and in a working state
* Only when the feature is completed, the branch is merged into the `master` branch!
* Meanwhile, the `main` branch is kept clean and in a working state
* Only when the feature is completed, the branch is merged into the `main` branch!
### Active branch
* Even though your local repository can have multiple branches, only one of them is *active* at a given time
* `git status` tells you firsthand which branch you are on: `On branch master`
* `git status` tells you firsthand which branch you are on:
```
On branch main
```
## `git branch`&`git checkout`
* You can create a new branch with `git branch <branchName>`
* You can create a new branch with `git branch <branchname>`
* The new branch is not empty: it contains a copy of the code of the branch you executed this command in
* ***Note:*** `git branch <branchName>` does not make the branch active!
* ***Note:*** `git branch <branchname>` does not make the branch active!
* To make the branch active, a.k.a "move" to the branch:
* `git checkout <branchName>`.
* For example, to move back to master use `git checkout master`
* `git checkout <branchname>`.
* For example, to move back to the main branch, use `git checkout main`
### Local vs. remote branches
* `git branch <branchName>` only creates a local branch
* When you try to push changes from a new local branch, Git nags you that a matching remote branch doesn't yet exist
* `git branch <branchname>` only creates a ***local*** branch
* When you try to push changes from a new local branch for the first time, Git nags you that a matching remote branch doesn't yet exist
* Git tells you how to create the remote branch:
* `git push --set-upstream origin <newBranch>`
* `git push --set-upstream origin <branchname>`
* Afterwards, `git push` pushes the changes to the matching remote branch
### Extra branch commands
<!-- _class: "extra invert" -->
* Handy command: `git checkout -b <branchName>`
* It's a shorthand for `git branch <branchName>` + `git checkout <branchName>`
* Handy command: `git checkout -b <branchname>`
* It's a shorthand for `git branch <branchname>` + `git checkout <branchname>`
* Get a list of local branches with `git branch`
* ...and all branches (incl. the remote ones) with `git branch -a`
* Delete a local branch with `git branch -d <branchName>`
* Remote branch can be deleted in the GitHub/etc website
* ...or with `git push origin -d <branchName>`
* Delete a local branch with `git branch -d <branchname>`
* Remote branch can be deleted in the GitLab/etc website
* ...or with `git push origin -d <branchname>`
* ***Note:*** If deleted remote branches still show up in `git branch -a`, you can use the command `git remote prune origin` to remove them from the list.
## `git merge`
* So you've been working on a feature branch. What next?
* When the feature is done (and all the broken things fixed), you want to apply your changes back to `master`
* For this, we use `git merge <branchToMerge>`
* It applies changes from `<branchToMerge>` to the ***current active branch***
* `master` branch is usually (and should be) protected, so we can't merge our new code to `master` directly
* Instead, we do the *inverse*.
* When a feature is done (and all the broken things fixed), you want to apply, i.e., ***merge*** your changes from the feature branch to the `main` branch
1) First, checkout the `main` branch with `git checkout main`
2) Then, do a `git pull` so you have the newest version of the `main` branch
* (Someone else might have done changes to it while you were working on your feature!)
3) Then, merge your local feature branch to your local main branch with
`git merge <featurebranch>`
* It applies changes from `<featurebranch>` to the ***current active branch***
* This is where ***conflicts*** might happen (more about them [later](#conflicts))
4) Then, push your changes to remote with `git push`
## Merging with a pull request
### Merging with a pull/merge request
1) Make sure you have the newest version of the `master` branch:
* Checkout `master` branch
* Pull changes from GitHub/etc
* Checkout the feature branch
* Merge the contents of `master` to `featureBranch` with `git merge master`
2) Then, create a ***pull request*** on GitHub/etc (In GitLab, it's called ***merge request***!)
* This creates a formal process for merging your *remote* feature branch to remote `master`
* This adds a layer of protection to the `master` branch: no direct merging!
* The aforementioned procedure isn't what we usually do, though!
* `main` branch should be ***protected*** so we can't merge our new code there directly
* Instead, we do the *inverse*.
1) First, checkout the `main` branch with `git checkout main`
2) Then, do a `git pull` so you have the newest version of the `main` branch
3) Then, ***checkout back to the feature branch***.
4) Merge your local `main` branch to your local `featurebranch` with
`git merge main`
5) Then, create a ***merge request*** on GitLab (it's ***pull request*** on GitHub—they're the same thing, just named from different points of view.)
---
### Simplifying merging further
* ***Pro tip:*** If you're working on your feature branch, you can merge changes from the `main` branch without changing branches altogether.
1) Update your local main branch with ```git fetch origin main:main```
2) Merge your local `main` branch to your local `featurebranch` with
`git merge main`
3) Then, create a merge request/pull request
* UI of a new pull request (*Pull requests > New pull request*) can be confusing...
* *base* is the branch you're merging, *compare* is the branch you're merging into!
* Much easier this way!
* But what is the merge request, anyway?
### If automatic merge fails...
### Merge request/pull request
1) Pull remote changes to your local `master`.
* ***Pro tip:*** If you're on your feature branch, you can do this quickly without changing branches with
```git fetch origin master:master```
2) Merge changes from `master` to your local feature branch.
3) Fix the ensuing ***conflicts*** (see [next section](#3-conflicts))
4) Push your new local branch to GitHub/etc
* Merge/pull request is a formal process for merging your *remote* feature branch straight to the remote `main` branch
* This adds a layer of protection to the `main` branch: no direct merging to the `main` branch!
* Additionally, a ***code review*** can happen at this stage:
* If a code maintainer thinks your merge request needs some modifications, you can make changes to the feature branch accordingly
* A merge request is branch-specific, so when you push your changes to your feature branch, the merge request is automatically updated as well.
* If this procedure is followed strictly, no bad code should get into the main branch!
## Extra: Merging without a pull request
<!-- _class: "extra invert" -->
### GitHub pull request UI
1) First, checkout the `master` branch with `git checkout master`
2) Then, do a `git pull` so you have the newest version of the `master` branch
* Someone else might have done changes to it while you were working on your feature!
3) Then, merge `<featureBranch>` to `master` with `git merge <featureBranch>`
* Fix conflicts
* UI of a new pull request (*Pull requests > New pull request*) can be confusing...
* *base* is the branch you're merging, *compare* is the branch you're merging into.
## Exercise 1. Pushing onwards
<!--_class: "exercise invert" -->
Continue the exercise from [Git Basics](1-git-basics) or create a new repository for these exercises.
* Create a new branch (with a name `new-feature`, for instance) in your local repository.
* Checkout the branch, make some changes to `GitTest.md` there, and push the changes to GitHub.
* Then, merge the changes from your `new-feature` branch to `master` branch by using
a) pull request in GitHub
b) `git merge` from command line
1) Create a new branch (with a name `new-feature`, for instance) in your local repository.
2) Checkout the branch, make some changes to `GitTest.md` there, and push the changes to GitLab.
3) Then, merge the changes from your `new-feature` branch to the `main` branch by using
a) `git merge` from command line
b) a merge request in GitLab
## GitLens
* To make the Git workflow easier, install the GitLens extension to VS code
* It helps in managing conflicts, comparing branches or commits
* Install it from the Extensions panel (access with ***CTRL+SHIFT+X***)
* Adds many new views to the source control tab:
* Adds many new views to the source control tab
<divclass='columns12'markdown='1'>
<divmarkdown='1'>
* For example:
* Commits
* Repositories
* File History
* Line History
* Branches
* Remotes
* etc...
# 3. Conflicts
</div>
<divmarkdown='1'>
</div>
</div>
## Conflicts
* Sometimes two people have made changes in the same lines of code!
* This leads to a conflict.
* Let's assume we're trying to merge changes from featureBranch to master.
* If a conflict happens, the merge does not conclude automatically. Instead, we need to ***fix all the conflicts*** by hand and then ***conclude the merge*** with some commands.
* Conflicting lines of code are framed by some `<<<<<<< garbage ======= symbols >>>>>>>` we don't yet understand
* This leads to a ***conflict***.
* Let's assume we're trying to merge changes from `featurebranch` to `main`.
* If a conflict happens, the merge does not conclude automatically.
* Instead, we need to ***fix all the conflicts*** by hand and then ***conclude the merge*** with some commands.
* Conflicting lines of code are framed by some `<<<< garbage ==== symbols >>>>`
we don't yet understand
* Before we can conclude the merge, we need to get rid of the garbage.
### Said garbage
### Garbage explained
```c#
<<<<<<<HEAD:Player.cs
@ -145,40 +166,51 @@ Continue the exercise from [Git Basics](1-git-basics) or create a new repository
return true;
>>>>>>> featureBranch:Player.cs
```
* ***Current change*** is between `<<<<<<<` and `=======`: old code in `master`
* ***Incoming change*** is between `>>>>>>>` and `=======`: new code from `featureBranch`
* ***Current change*** is between `<<<<<<<` and `=======`
* old code that was already in `main`
* ***Incoming change*** is between `>>>>>>>` and `=======`
* new code coming from `featurebranch`
* Use your text editor to choose which (or some combination of both) you want to preserve
### VS Code tools
* VS Code gives us tools to make conflict resolution a quick process
* Click which lines of code you want to preserve:
* ***Accept Current Change*** (old code is preserved, new code removed)
* ***Accept Incoming Change*** (new code is preserved, old code removed)
* ***Accept Both Changes*** (both are preserved)
* VS Code gives us tools to make conflict resolution a relatively quick process
* Choose your preference:
* ***Accept Current Change***
(old code is preserved,
new code is removed)
* ***Accept Incoming Change*** (new code is preserved,
old code is removed)
* ***Accept Both Changes***
(both are preserved)
## After resolving the conflict
* After resolving conflicting files, use `git add <filename>` to add them to the commit
### After resolving the conflict
* After resolving all conflicting files, use `git add <filename>` to add them to the commit
* Then use `git commit` to apply changes (without a message! no `-m`)
* Close the automatically opened `COMMITMSG` file. This should finish the merge.
* Close the automatically opened `COMMITMSG` file.
* This finishes the merge.
* Then just `git push` to apply changes in the remote repository
* ***Note:*** If VS code is not configured properly as the Git's text editor, and you encounter an error, run `git config core.editor code --wait`
### Example Git workflow with branches
<!-- _footer: "If VS code is not configured properly as Git's text editor, and you encounter an error, run `git config core.editor code --wait`" -->
## Exercise 2. Fixing conflicts
<!--_class: "exercise invert" -->
* Create a new branch in your local repository, but do not checkout it just yet.
* First, we simulate your teammate's changes by making changes to the `master` branch directly: On the `master` branch, make some changes to `GitTest.md`, and **add & commit**.
* Then, checkout the new feature branch.
* Then, make some other changes to GitTest.md to the same line as before, **add & commit**.
* Then, merge the changes from the `master` branch to your feature branch by using `git merge`
* Fix the ensuing conflicts, add & commit & push.
* Now you can create a pull request to merge your changes to the master branch.
Continue in the Exercise 1 repository.
## Git workflow 3: Undoing
1) Create a new branch in your local repository, but do not checkout it just yet.
2) On the `main` branch, make some changes to `GitTest.md`, and **add & commit**.
3) Then, checkout the new feature branch.
4) Make some ***other*** changes to GitTest.md to the same line as before, **add & commit**.
5) Then, merge the changes from the `main` branch to your feature branch by using `git merge`
6) Fix the ensuing conflicts, add & commit & push.
## Undoing
* Git doesn't have a general "undo" command
* If you make a mistake, it is very case-specific what you need to do to fix it
@ -195,37 +227,26 @@ Continue the exercise from [Git Basics](1-git-basics) or create a new repository
* Use `git checkout <hashcode>` to "time travel" into the commit
* ***Note:*** If you have GitLens, check the Commits view in the Source control tab to see the commit history.
## Revert one file to a previous state
*
### Reverting one file to a previous state
* Sometimes you want to revert just one file to its previous state
* For that, you need to figure out the commit hash of the state you want to return to
* You can use `git checkout <commit-hash> -- <filename>` to time travel just that file to how it was in that commit
* For this, you of course need to figure out the commit hash you want to return to
* Find that out in one of the following methods:
* `git log --oneline`
* VS Code: *Source control > File history*
* GitHub: check commits
* Then, run
* `git checkout <commit-hash> -- <filename>`
## Collaboration in Unity
* ***The zeroth rule:*** Make sure that everyone on team uses the same Unity and package versions.
* ***The first rule:*** Don't ever work on the same thing simultaneously.
* ***The second rule:*** When you do break rule #1, make necessary changes in communication so you won't break it again.
* Be sure to communicate about ***scene ownership***
* Scenes are not code files, so you can't easily merge changes if two people have worked on them
* Thus, the ***Scene Owner*** will be the only person on the team who should be working on a certain scene
* If a scene needs GameObject contributions from others, they can create prefabs that the Scene Owners then add to their scene
* Check commits from GitHub/GitLab
## Exercise 3. Branching team effort
<!--_class: "exercise invert" -->
* Work as a group for this assignment.
* Continue Exercise 2 from [Git basics](1-git-basics).
* Every group member creates an individual branch from the master, and makes some changes to the `GitTest.md` file.
* Add new files as well, at least one per group member.
* Do not tell other group members what you're going to change! :D
* Then, merge the changes back to the master branch. Fix ensuing conflicts, if any appear.
Work as a group for this assignment. Continue Exercise 2 from [Git basics](1-git-basics).
1) Every group member: create your own individual branch from the `main` branch
2) Then, make some changes to the `GitTest.md` file.
* Do not tell other group members what you're going to change! :D
3) Add new files as well, at least one file per group member.
4) Then, merge the changes back to the `main` branch. Fix ensuing conflicts, if any appear.
## Reading
@ -238,14 +259,25 @@ Continue the exercise from [Git Basics](1-git-basics) or create a new repository
* `git merge` creates a new commit for the merge process
* Sometimes that's undesirable, so an alternative is to use `git rebase`
* Unlike merge, rebase applies changes from the rebased branch ***one commit at a time***
* Unlike merge, rebase applies changes from the rebased branch
***one commit at a time***
* Whenever there's a conflict:
1) After fixing the conflict, add the conflicting file with `git add <filename>`
2) Then continue the rebase process with `git rebase --continue`
3) If you want to disregard a conflicting commit, use `git rebase --skip`
4) If you get cold feet, you can cancel the rebase with `git rebase --abort`
* ***Note:*** A good link for [understanding rebase](https://borbware.github.io/unity-basics-course/project-management/2-git-continued-slides.html)
## Very extra: Interactive `git rebase -i`
<!-- _class: "extra invert" -->
* `git rebase` also has a hidden ***interactive*** mode used with `git rebase -i`
* This is a true swiss army knife of a Git tool for rewriting Git history
* It can:
* Squash commits into one
* Cherry-pick only certain commits
* Reword commit messages
* And more!
* See [Hackernoon: Beginner’s Guide to Interactive Rebasing](https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d)
* [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)) is a framework for delivering products (usually software)
@ -21,22 +30,23 @@ theme: buutti
* Sprints are most commonly two weeks long (for us, shorter)
* Progress is tracked and re-planned in ***Dailies***, 15-minute time-boxed meetings
## Why Scrum for game development?
### Why Scrum?
* Through its practices and principles, Scrum creates ***conditions*** to achieve good results
* Scrum gives ***agency*** to team members: meeting the goal is a team effort
* Scrum creates ***transparency***: problems get addressed early
* Scrum isn't magic: you need to continuously enforce its practices in action
* Scrum facilitates communication, but doesn't solve any problems for you!
* Scrum facilitates communication, but doesn't solve any problems for you — you have to actively enforce its usage!
---
<!--
---
* ***Cross-discipline teams***: Enables teams to deliver features and mechanics that have clear value
* ***Self-management***: Enables teams to select the amount of work they can commit to every sprint and complete that work through whatever means they find appropriate
* ***Self-organization***: Enables teams to have a degree of authority and responsibility to select their membership
* ***True leadership***: Provides leadership focused on mentoring and facilitation to free the best performance possible from the team -->
<!--
* ***True leadership***: Provides leadership focused on mentoring and facilitation to free the best performance possible from the team
## Cross-discipline teams
* Team members share the same goal and therefore the same priorities
* To make sure ***no work goes to waste***, synchronization of the disciplines happens every sprint.
@ -58,12 +68,13 @@ theme: buutti
* Some sprints, like before release, might require a complete reorganization
-->
# Scrum basics
## Scrum people
## Scrum roles
Scrum Team consists of three roles: Product Owner, Scrum Master and the Dev team.
### Dev team
* Small team that aims to deliver a product
@ -71,48 +82,54 @@ theme: buutti
* Collaborates with Product owner
* Creates product increments in a series of sprints
### Scrum master
### Scrum Master
* Helps to facilitate usage of Scrum to the team
* Helps to facilitate usage of Scrum for the team
* Ensures the Scrum framework is followed
* Aims to improve team's workflow
* Basically an acting producer!
* Can be a part of the dev team (a "peer leader")
* ...but should not be the product owner
* ...but should not be the Product Owner
* Can be a different person every Sprint
* [Scrum.org](https://www.scrum.org/professional-scrum-certifications/professional-scrum-master-assessments) gives courses where you can get a Professional Scrum Master™ certification ($200)
### Product owner
### Product Owner
* Accountable for profit & loss
* Listens to the client's wishes
* Listens to the customer's wishes
* Manages the Product Backlog
* Representation of stakeholders and clients to the Dev Team
* Chooses what to release - and when
* Representation of stakeholders and customers to the Dev Team
* Chooses what to release — and when
<!-- _footer: "In this course, the teacher will act as this." -->
### Other Scrum-adjacent roles
### The rest
* These aren't part of the Scrum team, but can be important personnel in the product lifecycle:
* Stakeholders
* People outside the Scrum team who have an interest in the product
* Sales, marketing, end customers, etc
* Customers
* Communicates their needs and wishes to the Product Owner
* Is often more interested in the end result than technicalities
* Stakeholders (not actually part of the team)
* People outside the Scrum team who have an interest in the product
* Sales, marketing, end customers, etc
* Client
* Monitors product backlog
* Is responsible for the upkeep of the product backlog
## Project timeline
<!-- _footer: "In this course, the teacher will act as these." -->
### Starting a new project
* When a new project is started, a ***Product backlog*** is created based on the customer's needs and the available time
* The project timeline is split into *Sprints*, around which the whole Scrum process revolves around
* Sprints are usually from one week to a few weeks long
* A list of tasks to be completed during the Sprint
* Selected from the Product backlog
* A *forecast* of what is aimed to be done during the Sprint, not a promise!!!
* A *forecast* of what is aimed to be done during the Sprint, not a promise!!
* Often visualized as a [Kanban board](https://en.wikipedia.org/wiki/Kanban_board) in Trello, GitHub, GitLab, etc.
* In GitLab, Sprint backlogs can be created in the *Milestones* tab
---
### Definition of Done
### Definition of Done (DoD)
* When is a task considered done?
* This is decided by the Dev team in Sprint ***Retrospective*** ("Retro")
* Can change as project progresses
* This is decided by the Dev team in a Sprint Retrospective (more about it [soon](#sprint-retrospective-retro))
* DoD can change as project progresses
* "It works" -> "It passes tests"
<!--* "Fully completed" should refer to ***completely releasable*** -->
## Sprint Events
## Events
### Sprint events
* First day: Sprint Planning
* Every day: Daily Scrum
* Last day: Sprint Review & Sprint Retrospective
* In Scrum, Sprints are paced by ***events***, also known as [Scrum "ceremonies"](https://www.atlassian.com/agile/scrum/ceremonies)
* First day: *Sprint Planning*
* Every day: *Daily Scrum*
* Last day: *Sprint Review*& *Sprint Retrospective*
### Sprint planning
### Sprint Planning
* Starts a new Sprint
* *Sprint Planning* starts a new Sprint
* The whole Scrum team attends
* inspects the whole Product Backlog
* The whole Product Backlog is inspected
* A Sprint Goal is created and dissected into a new Sprint Backlog
* The Sprint Goal is ***immutable***
* The exact implementations are not discussed
* those are rather left for the Dev Team to decide
* Those are rather left for the Dev Team to decide!
* New tasks are given to the Dev Team
### Daily Scrum ("Daily")
* Only Dev Team attends, with these goals:
* Only the Dev Team attends the *Daily*, with these goals in mind:
* Inspect the progression towards the Sprint Goal
* Inspect how the Sprint Backlog is clearing out
* Create a plan for the next 24 hours
* Max. 15 min long!
* Keeps everyone on the same page
* $\Rightarrow$ Optimizes collaboration and performance of the Dev Team
* Sometimes held as a [stand-up meeting](https://en.wikipedia.org/wiki/Stand-up_meeting): Nobody sits down to enforce the sense of urgency and minimize time-wasting chit-chat
---
* Example topics to address in a Daily:
* Example topics to address in a *Daily*:
* What have you achieved since the last Daily?
* What problems have you faced?
* How does the team address problems?
* Is there need for (re)allocation of tasks?
### Sprint review
### Sprint Review
* Attended by the Scrum team and stakeholders
* The *Sprint Review* is attended by the Scrum team and stakeholders
* Goal: Offer feedback and open up discussions about the Sprint
* Starts off with a feature demonstration
* Product Owner presents the state of the Product Backlog
@ -185,25 +208,28 @@ theme: buutti
### Sprint retrospective ("Retro")
* After every Sprint Review
* Only the Scrum team attends
* worries and thoughts are brought up
* A*Retro* is held after every Sprint Review
* Only the Scrum Team attends
* Worries and thoughts are brought up
* Possible discussion topics
* What went right?
* What should be improved?
* Tools needed and used?
* The suitability of the Scrum process.
* The suitability of the Scrum process?
* What does Done mean, and should it be redefined?
## Scrum master tasks
## Scrum Master tasks
### Continuous tasks
* Continuously:
1. Make sure the task board on GitHub is up to date.
2. Make sure everyone is able to attend the dailies.
3. Make sure everyone is heard and contributes at dailies.
4. If someone needs help, you help them find assistance or assist them yourself.
* Before the dev meeting:
1. Make sure the task board on GitHub is up to date.
### Before the dev meeting
1. Make sure the task board on GitLab is up to date.
2. Make sure someone is ready to present the newest working version of the program, with all the new changes pushed
3. Write down the state of tasks listed in the Sprint backlog
4. Discuss what problems were encountered during the last Sprint, and how were they addressed.
borb
1 week ago
