This is the template for Project 3 repositories. It includes all the assignment instructions and documentation to help you use GitHub.
This is a group project. As such, you're expected to equally contribute to all parts of the project. To ensure everyone is contributing, we have moved this project entirely to GitHub and will use GitHub logs to understand your contributions. To fully leverage the features that GitHub offers, you have to be familiar with what they are and how to use them.
The goal of this project is to get you familiar with the creative process of software development for a general purpose use and how to use data structures or algorithms for those applications. To go with the professional development that the project offers in terms of general use application, you will also get more familiar with version control and GitHub platform to facilitate the collaborative work with extensive planning and organization abilities.
This step-by-step process is linked in this video if you aren't familiar with GitHub:
The following video has instructions on local development using Git and GitHub:
To illustrate the development process, we've also made a demo video to show how the GitHub flow looks like on an example:
Here are the instructions on how to Collaborate for Project 3 which are similar to what was covered in the Introduction to GitHub video. You may skip reading these if you have watched that video:
This is a template repository. If you want to know more about those, feel free to follow this link to the GitHub documenation about templates and how to create them. You've used templates before for projects 1 and 2, and you will use it now, too.
The first step of your project is to make your own repository for your own project that will host your source code and documentation. Only one member of the team needs to create a repo and everyone else copies that repo using git clone.
Choose a descriptive name for your repository. This is part of some good practices about your GitHub repos. For this project, make sure to also make your repository public. The project is fully yours and you have all of the creative freedom, so feel free to use it as a part of your professional portfolio.
Since this is a group project, you are all expected to evenly contribute to the repository. Regardless of if you're working on the code, the documentation, or the video, you all have to have access to the repository since that is the only submission for this part of the project.
To add collaborators to you repository, navigate to the main page of the repository and click Settings.
More information about collaborators.
During the development of your software, you will have to perform several tasks. In project 3a, you agreed on how you will distribute these tasks. GitHub has several features that can help you keep track of these, so please make sure to use them.
Issues in GitHub is one of the most useful features when it comes to progress tracking. The platform allows you to set Milestones, which have due dates (very useful if you want to have weekly progress meter). Each Milestone can have several tasks called Issues in GitHub, which have the descriptions on what needs to be done.
Issues offer several organizational options that you should use:
Once you have the initial tasks distributed as issues in your repo, your development should involve separate branches based on the tasks you do. Making a branch means that you have a safe copy of the code to work on in a sandbox style environment. This ensures that if you do something on your branch that messes up the already working code in the main branch, your mistake would not affect the main code and you can start over to ensure you don't encounter the same problem.
To make a branch, you open the main page of the repository (Code).
To delete a branch, open the tab with all branches and click on the bin () symbol at the end of the line with the branch you want to delete.
Commits are a way to update the repository with the changes you made. Each commit has information about who made the change, what changes were made, when the change was made, and a message that describes the changes (and/or if it refers to an Issue).
Commits are very important part of collaboration and should follow an agreed on convention for the team. Each commit also offers a way to organize the changes because it shows a very short concise description of the change made. As such, make sure to commit frequently and that each commit solves only one issue. As with Issues, your commits should be atomic (contains only one change, e.g. Feat: implement user input parsing for calculator to split string into tokens (Issue #1)).
"A pull request is a proposal to merge a set of changes from one branch into another. In a pull request, collaborators can review and discuss the proposed set of changes before they integrate the changes into the main codebase. Pull requests display the differences, or diffs, between the content in the source branch and the content in the target branch." About Pull Requests in GitHub
Once you've made commits and are done working on the feature your branch was for, you should make a pull request. A pull request is meant to allow your teammates to review your changes, give you feedback, and the merge all the functional code into one central location (main branch).
If you've made a mistake (happens to the best of us) in the changes you've made and committed, pushed, or merged, you can undo the majority of those changes using Git CLI. This guide allows you to interactively navigate through the resources based on the actions you've taken to find the solution for your problem.
README files are formatted using Markdown in GitHub. If you're not familiar with Markdown, or if you need some syntax information, you can find syntax and tips in Markdown resource file. In addition to README files being formatted using Markdown, you can use the same syntax in your commit messages, your issues, and milestones to format any text.
These sites are specifically referred to in the rest of the documentation provided.