Skip to content

Git Lesson

Jump to bottom
starmaid edited this page Sep 17, 2023 · 8 revisions

Git Lesson

Git is a SCM (source code management) or SVC (source version control) software that allows one or many developers to work together on projects.

GitHub is an online file storage system and set of tools for managing git repositories.

This lesson will focus primarily on the command line interface. Git ships with a GUI, there are third-party GUI solutions, and most IDEs will have an integration. Instead of covering one of those, if you learn the CLI you will automatically know how to use those other options. Also, you look cooler.

Install

History

  • why do we have VCS?
  • you modify a file, i modify a different file. easy!
  • what if we modify the same file.
  • its effort to host your own git remote: so github was created

Landmarks

  • the .git directory
  • README files (and markdown in general)
  • .gitignore files

Use

Getting set up

  • main branch is protected.
  • you only really have to clone it once
  • but nothing is stopping you from having multiple ones
// get the repo onto your system the first time
git clone <url> 

// list all branches
git branch -la

// checkout a remote branch locally
git checkout -b <remotebranchname> --track origin/<remotebranchname>

Feature Addition Workflow

  • you go to the issues tab. you pick an issue.

  • this issue is a feature request. Assign yourself to the issue. This is basically like 'claiming' the issue.

  • switch to the branch you want branch off from. This should usually be main.

    git checkout main

  • pull the latest version of the remote

    // integrate remote changes on the branch you are in into your current branch
git pull

  • create a branch locally for that feature.

    For our project, I will suggest that we follow the pattern:

    feature/<issue number>-<dash-separated description>

    for example, feature/14-create-water-level

    If things break later, we can do

    bugfix/<issue number>-<dash-separated description>

    for example, bugfix/23-stop-clipping-thru-walls

    // make a new branch and track it on remote
git status
git checkout -b <newbranch>
git push --set-upstream origin <newbranch>

  • make changes in your software of choice

  • add only the files you want to modify

    // show which files have been modified
git status

// show what you changed about a file
git diff <filepath>

// add a file to your commit
git add <filepath>

  • If you accidentally changed a file you didnt want to change (or changed it for testing purposes), revert them.

    // revert a single file to the current commit
git restore <path>

  • commit the changes.

    // commit
git commit -m "write a message about the commit here"

    You should be committing periodically. ideally you commit when you either reach a good intermediate point, finish for the day, or finish the feature. Remember, committing gives you a full save state you can return to later.

  • push your local changes up to the remote. ideally you do this at the end of your coding session, or if you need to showsomeone else your code.

    // push to remote
git push

Merging Back In

  • when you have completed a feature and have tested it to satisfaction, it needs to be merged into main.

  • in the web UI, create a pull request.

    • go to your branch
    • there will be a banner prompting you. if not, navigate to the branch page and click on it. Alt text

  • it is likely the main branch will have changes you do not have in your branch. you will have to merge these changes into YOUR branch.

  • then, you can merge the now clean changes into the main protected branch.

  • assign a reviewer. this person will look over the changes and say its ok. usually takes under a minute andis good to get other eyes on the changes

  • merge into main.

  • if there are conflicts, you will have to resolve them. if the web UI doesnt support it, you can always usevsc to manage locally

  • if the merge is really complex, we can have a merge party: a sudden, impromptu meeting where anyone who isavailible comes to backseat merge

  • finish the merge. remember to pull main afterward so you get a copy locally.

//merge
git fetch origin
git checkout 'destination_branch'
git merge --no-ff 'incoming_branch'

// if u wanna go back
git merge --abort

Other Cases

// clean all your files (restore changed ones, delete untracked)
git clean -f
git restore .


// delete a branch
// move off the branch first
git checkout branchyouwanttokeep
git branch --delete badbranch

// fetch remote data but don't merge into your branch
git fetch

Pipelines

  • i have set up a pipeline that auto-builds the main branch code on each commit. you can thus downloadplayable EXEs from the pipelines page.
  • on tags, a release will also be built. this will appear on the releases page.

Google Drive

  • i have created a parallel file structure inside the project.
  • Mimi and I have set up the sync.sh file to copy and auto-update the files. This is a somewhat involved process to set up, so just message one of us to run it if you need it.
  • google drive will be considered the master location. changes on the unity project will be overwritten.

Tags and Releases

When we are ready to do a release version, we can do a tag. Tags follow Semantic Versioning

git tag -a v0.0.3 -m "short message."

git push origin v0.0.3

This will cause workflows to run and a release to be built. These can then be manually uploaded to itch.io.

Releases on github can be made manually from tags. These include feature messages and should just be handled by hand, if we ever even decide to do such a thing.

Clone this wiki locally