Lecture 2 - Workflow | Games Engineering

# Lecture 2 - Workflow and Repo Management
### SET09121 - Games Engineering

Kevin Chalmers and Sam Serrels

School of Computing. Edinburgh Napier University

---

# Version Control

Version Control Used everywhere, by everyone.

This module expect to see best practises in use.

---

# Version Control

Why use Version control?

- Keep a log of changes to your code 
- An unlimited "undo" button. 
- Experiment with new features without trashing your working code 
- Work in teams  
- Mirror your codebase to multiple redundant locations 
- Integrate with continuous-integration, testing and deployment tools.

---

# Git

You can do a lot of things with git, and many of the rules of what
you *should* do are not so much technical limitations but are about
what works well when working together with other people.

VC / GIT is a very powerful set of tools, and that can not only be
overwhelming at first, it also means that you can often do the same (or
similar) things different ways, and they all "work."

Generally, the best way to learn git is probably to first only do very
basic things and not even look at some of the things you can do until
you are familiar and confident about the basics.

---

# Git Hosts

- Local - You don't *need* to push anywhere
- Run your own git server
- Github - The de facto for open-source code.
- Bitbucket - Meh
- Gitlab - when you need multiple repos and project management
- [gitgud.napier.ac.uk](gitgud.napier.ac.uk) - unlimited private repos, napier hosted.

---

# Git clients

- Command Line (Git bash on windows)
- github desktop - [desktop.github.com](desktop.github.com)
- sourcetree - [sourcetreeapp.com](sourcetreeapp.com)
- gitkraken - [gitkraken.com](gitkraken.com)

![image](assets/images/sourcetree.png)

---

# Version Control - Best Practices

---

# Commit Often

- Committing often keeps your commits small and, again, helps you commit only related changes. 
- Allows you to share your code more frequently with others. 
- Easier for everyone to integrate changes regularly and avoid merge conflicts. 
- Having few large commits and sharing them rarely, in contrast, makes it hard both to solve conflicts and to comprehend what happened. 
- Don't commit only at the end of the day.

---

# Commit Related Changes

- A commit should be a wrapper for related changes.
- For example: 
 - Fixing two different bugs should produce two separate commits. 
- Small commits make it easier for other team members to understand the changes and roll them back if something went wrong. 
- Use tools like the staging area and stage only parts of a file, to create very granular commits.

---

# Don't Commit Half-Done Work

- You should only commit code when it's completed.
- This doesn't mean you have to complete a whole, large feature before committing. 
- Split the feature's implementation into logical chunks and remember to commit early and often. 
- Consider using Git's "Stash" feature. 
- If you absolutely need to commit, commit to a separate branch.

---

# Test Before You Commit

Resist temptations to commit something that you *think* works.

- Test it thoroughly 
- make sure it really is completed ...
- ..and has no side effects (as far as one can tell).

### Don't Break The Build

---

# Write Good Commit Messages

Begin your message with a short summary of your changes.

(Up to 50 characters as a guideline).

Separate it from the following body by including a blank line.

The body of your message should provide detailed answers to the following questions:

 - What was the motivation for the change?
 - How does it differ from the previous implementation?

---

# Use Branches 
Branching is Git's most powerful feature.

The tool to help you avoid mixing up different lines of development.

![image](assets/images/gitflowworkflow.png)

---

# Agree on a Workflow

However you choose to work, just make sure to agree on a common workflow that everyone follows.

Following and enforcing other practices such as a code standard helps with merging.

</div>

---

# Version Control is not a Backup System

Commit selectively - don't just cram in files.

### Git is not for Binary files

## Keep The Repo Clean

---

# What goes into a code repository

- Source code files. (.cpp, .h, .java)
- README.md
- LICENSE
- .gitignore
- Buildscripts / makefiles (CMakeLists.txt)
- git submodules

---

# What does not go into a code repository

- Binary files (.wav, .mp3, .jpg, .pdf) [ok for small things] 
- Compiled Code (.exe, .dll, .lib, .so, .obj) 
- IDE project files (.vcxproj, .sln) 
- Junk and temp files (.log) 
- Old code in a separate 'old-code' folder.

__There are marks at stake here, do this right.__

---

# Why clean repos?

Evidence of good software engineering - only include what you need.

Therefore it follows that you *know* should what you need.

You should understand everything that is in your repo, and be able to justify it's place there.

If you can't; then it shows that you don't understand your own work.

---

# Version Control Best Practices

## Summary
- Commit Often
- Commit Related Changes
- **Don't Break the build**
- Use Branches
- Agree on a Workflow
- Write Good Commit Messages
- **Keep The Repo Clean**

---

# Version Control - Working in teams

---

# Merging

- Make sure you have the newest stuff
- **Always pull before starting working**

![image](assets/images/gitexample.png)

Advanced trick: You can do "Squash and Rebase" technique to make this
look neater.

---

# Merging 2

If there were changes on the branch you want to merge into:

- Merge them into your branch, before merging onto it.
- Ensures your work is compatible
![image](assets/images/gitexample2.png)

---

# Branches

For individual projects, 2 types of branches work fine.

- Master
- Feature Branches

When you scale up onto bigger projects you add more to suit the
development workflow.

There is one rule to rule them all: 
** Never break Master **

- **Development / Master**
    - Merge your feature branches into here
- **Testing**
    - Dev merges into here, get tested before merge to Release
- **Release**
    - Tagged and available for download to the public.
    - Also commonly called "Production" or "Live" branch

---

# Branches

![image](assets/images/gitflowworkflow.png)

---

# Branches

![image](assets/images/gitexample3.png)

---

# Pull Requests

**Not actually a native git feature, Github introduced this concept**

Pull requests are a mechanism for a developer to notify team members that they have completed a feature.

Once their feature branch is ready, the developer files a pull request via their Bitbucket/github account. 
This lets everybody involved know that they need to review the code and merge it into the master branch.

But, the pull request is more than just a notification.
It's a dedicated forum for discussing the proposed feature. 
If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits.
All of this activity is tracked directly inside of the pull request.

---

# Merge Conflicts

When git-dif doesn't know what you want to keep.

You can resolve them manually with a text editor

``` {language="c++"}
for(int i; i <3; ++i){
 <<<<<<< HEAD
 cout << "hello" <>>>>>> branch-a
}
```

Simply remove the bit you don't want, save the file, and commit.

Git GUIs can do most of this for you.

---

# Writing code for deployment

---

# Writing code for deployment 

You will be building programs that run as standalone executables.

The big difference here is we are not running from an IDE.

You must know how to **build, test, and deploy** your code.

To do this, you must have knowledge of the following things:

- Know what your program does
- What your program needs to build
- Where it builds
- How it builds
- What it need to run

Submitting a game that doesn't run, due to something like missing .DLLs will loose you serious marks.

---

# C++ Software Engineering methods

---

# C++ ecosystem

C++ is a low-level language.

It runs natively on the system, therefore must be compiled specifically for the system it is running on.

Unlike Java, there is no "C++ Virtual Machine" or universal cross-platform runtime.

This makes writing robust and portable applications difficult.

---

# Cross platform code

Standard c++ code that just does logic is basically cross-platform.

Where we get into trouble is when hardware and system calls.
- windowing
- input
- graphics
- sound
- threading
- time
- maths

Each operating system has it's own way of doing this. (See POSIX)

We have great libraries that do all this for us.
e.g SFML, GLFW, SDL.

---

# C++ Dependancy Hell
In the past you may have downloaded a precompiled .lib/.dll for external Libs.

We will be building our libraries from source, right from github.

Pros: 
- Newest code. Git Submodules keep it updated 
- Better performance - Compiler has more code to optimise. 
- Debugging - breakpoint and step though 3rd party code. 
- Repo size - no .dlls in repo 
- Portability - can build for different architectures. 
- Compatibility* - no need to have specific libs versions (x32/x64)

Cons:
- Getting it to work is hard
  - *Every library is different and may not have clear build guides.

---

# The solution

![image](assets/images/cmake.png)

---

# CMake 
An open-source, cross-platform tools for configuring, building, testing and packaging software.

Write **one**  CMakeLists.txt config file, dictating what your application needs to compile.

CMake processes this and generates solution files relevent to the platform you are working on.

Not all c++ projects use CMake or have a working config.

SFML and box2d do. So we are all set.

CMake is covered more in depth in the labs.