Git: Beginner Guide ‐ Main Commands and Principles - Gr8-Tools/game-developer-roadmap-doc GitHub Wiki

Total time: 3 hours

Git is a widely used version control system that allows developers to track and manage changes in their codebase. Understanding the main commands and principles of Git is essential for any game developer to collaborate efficiently and effectively. In this article, we will explore the key subtopics and definitions related to Git.

Subtopics and Definitions

  1. Repository: A repository, often referred to as a repo, is a collection of files and directories that are tracked and managed by Git. It stores all the versions of the project's codebase and allows developers to collaborate on the same code.

  2. Commit: A commit is a record of a specific set of changes made to the repository. It represents a snapshot of the codebase at a given point in time. Each commit has a unique identifier called a commit hash.

  3. Branch: A branch is a separate line of development that allows developers to work on different parts of the codebase simultaneously. It allows for isolation and experimentation without affecting the main codebase. Creating a new branch helps in keeping the main branch (often called master or main) stable.

  4. Clone: Cloning a repository means creating a local copy of a remote repository. This allows developers to work on their own machines, make changes, and contribute back to the original project.

  5. Pull: Pulling is the process of updating the local repository with the latest changes from a remote repository. It incorporates the changes made by others into your working copy.

  6. Push: Pushing refers to sending your local commits to the remote repository. It updates the remote repository with your changes, making them visible to others working on the project.

  7. Merge: Merging combines changes from different branches into a single branch, typically the main branch. It is done to integrate the changes made in separate branches and ensure a consistent and up-to-date codebase.

  8. Conflict: A conflict occurs when Git is unable to automatically merge changes from different branches. It requires manual intervention to resolve conflicting changes and make the codebase consistent.

  9. Pull Request: A pull request (PR) is a way to propose changes to a repository. It allows others to review the changes, provide feedback, and eventually merge the changes into the main branch. It is a common workflow for collaboration and code reviews.

  10. Fork: Forking is the process of creating a personal copy of someone else's repository. It allows developers to freely experiment and make changes without affecting the original repository. Forked repositories can be used to propose changes through pull requests.

Understanding these subtopics and definitions will provide you with a solid foundation to start using Git for game development. Git empowers developers by ensuring version control, efficient collaboration, and easy management of code changes.

Additional materials

Articles

  1. External Git resources - external resources to study Git. Not obvious. For self deep study.

Video

  1. Git and GitHub Tutorial for Beginners

2 hours

Sources

  1. Tortoise Git - The best git client in my humble opinion.
  2. GitHub Desktop - Great for beginners but is not so powerful as previous client.

Best practices

  1. The main-branch serves as the production branch from which we build the product. The main branch should remain clean and tidy, which is why directly merging changes into it is prohibited.
  2. When implementing new functionality or fixing bugs in the existing code, a new branch should be created from the main branch with a name reflecting the nature of the changes. It is recommended to prefix the branch name with bug\ for bug fixes or feature\ for new features.
    • Use snake_case template for branches names, that contains from multiple words.
  3. Once the work on a specific change is completed, a pull request should be created to merge the branch into the main branch. I recommend you follow this flow working on a self project too.
  4. The stage branch acts as a testing platform for all changes. Here, we test how all the changes work together in the build. The stage branch is also considered to be a trash branch, so actions leading to the stage branch merging into the main branch are PROHIBITED, namely:
    • Merging stage into main (for those with sufficient permissions)
    • Merging stage into personal working branches (as it is assumed that the working branch will eventually be merged into the main branch)
  5. In case bugs are discovered during testing in the stage branch, the following steps should be taken:
    • Make the corresponding changes in your personal working branch (in cases where errors are related to other people's changes, inform the owners of those changes).
    • Merge your working branch again into the stage branch. Since the pull request is still open, changes from the working branch will be automatically pulled into the request.
  6. After successfully testing all the changes in the stage branch, the code Assigner can presses the big green merge button. By the time the merge button is pressed, there should be no conflicts. If conflicts arise, the following steps should be taken:
    • The performer takes their working branch and merges the master branch into it.
    • Resolve all conflicts, choosing the changes from the master branch as they are considered tested and baseline.
    • Double-check all the changes (step 5).

stage branch is useful in projects, developed by teams at least 3-5 peoples. If you work on your own project it can be useful but it takes some your resources to validate the state of this branch. If you work on your own project it's enough to adhere to the remaining rules in order to correctly conduct the project.

The various merging options on the scenes should be examined in practice to determine if any significant measures need to be taken.

Tasks

  1. Install git client (any you want). For each of your existing project (related to this study program) create own repository. Upload existing projects with client you've chosen. For each new project create new repository.
  2. For each task create new branch following the flow above.
    • Mostly your branches should be named with a template feature\$lesson_shortname
    • Every initial branch can be named feature\initialize_project

1 hour