This is a Doom-like raycaster game engine, coded in C as a team work with @552020. This project is designed to recreate the classic 3D effect found in early first-person shooters using raycasting technology. This engine offers a glimpse into the workings of a pioneering technology in the gaming industry.
Many Readmes document the implementation of the code and the math behind, therefore we thought that if something has to be shared, it is comething else : This Readme document our workflow findings for team project and organizing your work. If you are starting out with git and github as a tool to work in a team, this is for you.
Git.graph.representation.of.branches.and.commits.mov
This project is not just about the end product; it's also a journey of learning and collaboration. Throughout the development process, we enhanced our skills and knowledge in several key areas:
- Version Control: Learn how to use Git for effective version control, enabling collaborative development and tracking changes over time.
- GitHub Workflow: Explore GitHub as a platform for hosting repositories, managing issues, and collaborating on projects.
- Issue Tracking: Utilize GitHub Issues for project management, keeping track of tasks, enhancements, and bugs.
- Assigning: Learn how to assign tasks to team members, distributing responsibilities efficiently.
- Milestones: Organize work into milestones, setting achievable goals and deadlines for project phases.
- Collaborative Coding: Emphasize collaboration by reviewing and providing feedback on each other's code.
- Branching Model: Understand the importance of branching in collaborative development and choose an appropriate branching strategy.
- Feature Branches: Develop features and enhancements in isolated branches before merging into the main codebase.
Git branches enable developers to work on features or fixes in isolation.
-
Local branches are branches in your local Git repository. Work here before you're ready to share or merge changes.
- Create a new branch:
git branch <branch-name>
- Switch to a branch:
git checkout <branch-name>
- Create a new branch:
-
Remote branches are references to the state of branches in a remote repository. They track the shared work.
- Track a remote branch:
git checkout --track origin/<branch-name>
- Push local branch to remote:
git push -u origin <branch-name>
- Track a remote branch:
Local changes don't affect remote branches until pushed, facilitating isolated development and review.
Tracking a remote means your local branch will keep up with changes in the remote repository, automatically syncing your work with the latest updates from others. This is crucial for collaboration and ensuring your changes are compatible with the project's current state.
This guide outlines best practices for collaborative development using Git and GitHub. Effective collaboration involves clear communication, issue tracking, and a streamlined pull request (PR) process.
1. Issue Creation: Open an issue for a new task or bug.
Opening Issues
Frequent Issue Creation: Open an issue for each small feature, bug, or task. This helps in better tracking (collaborators know what is going on) and organization.
Tags: Use relevant tags to categorize and label issues (e.g., bug, feature, documentation, etc.).
Assignees: Assign issues to team members responsible for their resolution.
Conversation: Use the conversation part of the issue to explain a problem, ask questions and stay up to date you can @people and #issue or #commit or #pullrequest
Branch Naming: We found practical to create the branch right from the issue tab in Github
2. Branching: Create a new branch for the issue.
- We found practical to create the branch right from the issue tab in Github
Commits:3. Make frequent, small commits (you can reference the issue number in the commit message)
- following the CI/CD principles - the code is easier to debug, there are less conflicts - it is a real collaboration, not just splitting the work, as each person is aware of update in its teammate code
4. Pull Request: Open a pull request once the work is complete.
A PR is when a developer pushes changes to a branch in a fork of a repository and then submits a request to the original repository to merge those changes to main PR Opening: Open a pull request once changes are ready for review. (the main repo page on Github will offer you the option after a "fresh push")
PR Review: Collaborators can comment on the PR.
Review:5. Collaborators review the code, add comments, and suggest changes if necessary.
Content
Approval:6. Once approved, the PR is merged into `main`,
Content
7. the issue is closed and the branch deleted
Protection of Main Branch
Main Protection: While we've decided not to protect the main branch, it is crucial to follow the rule of never pushing directly to it.
Remember, effective communication is key to successful collaboration. Happy coding!
basic git commands | Description |
---|---|
git branch |
List, create, or delete branches. |
git fetch --all |
Fetch all branches from the remote repository. |
git checkout my_branch |
Switch to the specified branch. |
git stash |
Save changes that are not ready to be committed. |
git stash pop |
Apply stashed changes and remove them from the stash. |
git log |
Display commit logs. |
git branch <branch-name> |
Create a new branch. |
git push --set-upstream origin <branch-name> |
Push the branch to the remote repository and set it to track the remote branch. |
Additionnal git log commands | Description |
---|---|
git log --oneline |
Display abbreviated commit hashes and messages. |
git log --graph |
Display a text-based graph of the commit history. |
git log -n 5 |
Show the last 5 commits. |
git log -p |
Show changes introduced in each commit. |
A Valgrind suppression file is a mechanism to filter out known and acceptable memory leaks or errors during the execution of a program. This guide outlines the process of creating a Valgrind suppression file, including both manual and automatic methods.
-
Identify Leaks:
- Run your program with Valgrind to detect memory leaks or errors.
valgrind --leak-check=full ./your_program
- Run your program with Valgrind to detect memory leaks or errors.
-
Extract Suppression Information:
- Review Valgrind's output and identify errors or leaks that you want to suppress.
- Extract relevant information such as function names, library references, and leak types.
-
Create Suppression File: Suppression File Syntax:
- Start with a pair of curly braces
{}
enclosing the suppression details. - The first line inside the braces is a name for the suppression, chosen by you for easy identification.
- The second line specifies the type of Valgrind tool the suppression applies to, such as
Memcheck:Leak
for memory leaks. - The third line,
match-leak-kinds
, is optional and specifies the kinds of leaks to match: definite, possible, indirect, still-reachable, etc. - Subsequent lines use patterns like
fun:function_name
to match the function names in the call stack of the detected error orobj:library_name
for matching specific libraries. - The suppression entry ends when the closing brace
}
is reached.
Example:
{
ignore_lodepng_decode_leak
Memcheck:Leak
match-leak-kinds: possible
fun:malloc
fun:lodepng_decode
fun:lodepng_decode_memory
fun:lodepng_decode_file
fun:mlx_load_png
fun:load_textures
fun:main
}
{
ignore_mlx_leak_general
Memcheck:Leak
match-leak-kinds: possible
fun:malloc
...
obj:*libmlx42*
}
{
ignore_glfw_leak_general
Memcheck:Leak
match-leak-kinds: possible
fun:malloc
...
obj:*glfw*
}
- Apply Suppression File:
- Run your program with the created suppression file.
valgrind --leak-check=full --suppressions=your_suppressions.supp ./your_program
- Run your program with the created suppression file.
-
Generate Valgrind Log:
- Run your program with Valgrind and generate a log file with suppression information.
valgrind --leak-check=full --gen-suppressions=all --log-file=valgrind_log.txt ./your_program
- Run your program with Valgrind and generate a log file with suppression information.
-
Use Suppressions Script:
- Utilize a script to parse the Valgrind log and create a suppression file automatically.
- Example script: Parse_valgrind_suppressions.sh
-
Refine Suppression File:
- Review the generated suppression file and refine it by removing unnecessary entries or adjusting patterns.
- Focus on keeping suppressions relevant to your program's specific issues.
-
Apply Suppression File:
- Run your program with the refined suppression file.
valgrind --leak-check=full --suppressions=your_refined_suppressions.supp ./your_program
- Run your program with the refined suppression file.