Student lab learning guide for using GitHub to manage an agile technology project.

1. Introduction to Agile and GitHub

Agile Principles: Introduce the 12 principles based on the Agile Manifesto.
What is GitHub?: Explain GitHub’s role as a platform for version control and collaboration.
GitHub and Agile: Discuss how GitHub supports Agile practices with features like Issues, Milestones, and Projects.

Introduction to Agile and GitHub

Agile Principles

The Agile Manifesto, established in 2001, revolutionized software development with its focus on flexibility, collaboration, and customer satisfaction. The following 12 principles provide the foundation for any Agile methodology:
Customer Satisfaction Through Early and Continuous Delivery: Deliver value to customers frequently, prioritizing their needs and incorporating feedback.
Welcome Changing Requirements: Embrace change even late in the development process for the customer's competitive advantage.
Frequent Delivery of Working Software: Produce and release quality software at regular intervals, ranging from a few weeks to a few months.
Collaboration Between Business Stakeholders and Developers: Promote daily cooperation between business specialists and developers throughout the project.
Motivated Individuals: Form teams around self-motivated individuals, provide them with the necessary support, and trust them to accomplish the objectives.
Face-to-Face Conversation: Facilitate direct and efficient communication, considered the most effective method to share information.
Working Software as the Primary Measure of Progress: Evaluate advancement through functional software rather than just documentation or meetings.
Sustainable Development: Advocate for a sustainable work pace that teams can maintain indefinitely, avoiding burnout.
Technical Excellence and Good Design: Pay continuous attention to technical prowess and design to enhance agility.
Simplicity: Maximize the amount of work not done; focus on simplicity and eliminate unnecessary work.
Self-Organizing Teams: Foster environments where self-organizing teams can create the best designs, architectures, and meet requirements.
Regular Reflection and Adjustment: Encourage teams to reflect on their effectiveness periodically and adjust behaviors and processes to improve efficiency.

What is GitHub?

GitHub is an extremely popular web-based platform that utilizes Git, a version control system that allows multiple people to work on a project simultaneously without stepping on each other's toes. It acts as a repository host, providing a backup of the work synced to a remote location. GitHub amplifies collaborative features of Git and provides a user-friendly interface along with its own additional features such as:
Repositories: Online directories where project files live.
Forks: Personal copies of other users' repositories, allowing you to freely experiment without affecting the original project.
Branches: Features within repositories for developers to isolate work on particular tasks.
Pull Requests: A means to notify team members about changes one has pushed to a branch in the repository.
Issues: A way to track tasks, enhancements, and bugs for work on GitHub.

GitHub and Agile

Agile’s emphasis on collaboration, iteration, and responsiveness aligns well with the features offered by GitHub. Agile teams can utilize multiple GitHub features to support their methodology.
Issues: Issues in GitHub can represent user stories or tasks. They can be tagged, commented on, and assigned to team members, making it easy to keep track of progress on various fronts.
Milestones: Agile sprints can be represented as Milestones in GitHub. They help in tracking the progress of tasks linked to a particular phase or iteration of the project.
Projects: GitHub Projects can act as Agile boards (Kanban/Scrum boards) where you can create columns that represent stages of development. Issues can be added as cards that move across the board, providing a visual flow of the project's current status.
Pull Requests: Allow for code reviews and merge tracking. These are invaluable for continuous integration and continuous development (CI/CD) practices within Agile.
GitHub Actions: Teams can automate their workflows which is beneficial for CI/CD approaches—commit code, run tests, deploy to production environments, and more.
GitHub effectively fosters Agile principles by synchronizing development workflows, enabling continuous feedback loops, and facilitating high-bandwidth communication among distributed teams. This combination empowers teams to deliver quality software swiftly and efficaciously.

2. Initial Setup on GitHub

Creating a GitHub Account: Guide through the account creation process.
Creating a New Repository: Steps on creating a repository for the project.
Initializing with README: Demonstrate the importance of a README file.

3. Collaborating on GitHub

Inviting Collaborators: Teach how to add team members to the project.
Cloning the Repository: Explain how to clone the repository locally using git clone.
Branching: Teach branching strategies suitable for agile development.

Branching in the context of agile development is a strategy used to manage the codebase as new features, fixes, and experiments are developed. It allows multiple developers to work on the project simultaneously without interfering with each other's progress, and it helps in maintaining the stability of the code. Below are some of the prominent branching strategies suitable for agile development:


Overview: A robust branching model designed for managing releases which are focused on the project's release cycle.
master: Stores the official release history.
develop: Serves as an integration branch for features.
feature: Used by developers to create new features without disturbing the develop branch.
release: Prepared for the next production release, allowing for minor bug fixes and preparing metadata for a release.
hotfix: Used to quickly patch production releases.
Developers create feature branches from develop for new features.
Once features are complete, they are merged back into develop.
When enough features have been added for a release, a release branch is created from develop.
release branches get deployed to staging for testing. Fixes can be made directly on the release branch.
The release branch is merged into master and tagged with a release number.
Additionally, release is also merged back into develop to ensure that any fixes are integrated.
Any critical issues affecting production are dealt with in hotfix branches, which upon completion merge into both master and develop.

GitHub Flow

Overview: A simpler alternative to Git-Flow, optimized for continuous delivery and less concerned with release schedules.
master: Always reflects a production-ready state.
feature: Short-lived branches made off of master for every new feature.
Anything in the master branch is deployable.
To work on a feature or fix, create a descriptively named branch off of master.
Create a pull request to initiate discussion around the code.
Make pull requests to merge feature branches into master frequently, after code review.
Once merged and passed all tests, deploy immediately.

Trunk-Based Development

Overview: Focuses on very small and frequent commits to a single branch (trunk), encouraging collaboration and minimizing merge conflicts.
trunk/master: Main development line that's always ready to be released.
short-lived feature: These branches are kept very brief and merged often.
Most development is done directly on the trunk/master.
feature branches are created but must be short-lived (usually less than a day).
Frequent merges and continuous integration with the mainline ensure issues are identified and resolved quickly.
Branches for features or fixes are promptly reviewed and merged into trunk/master.
Releases are typically done by tagging specific commits on trunk/master.

Feature Toggle

Overview: Instead of using branches, features are controlled via configuration options known as feature toggles or feature flags.
Developers commit code to the mainline with the feature's active state controlled by a toggle.
New features can be merged into the mainline but kept inactive until they're ready.
Toggles allow for continuous integration and delivery.
Features can be turned on or off without additional code deployment, supporting A/B testing and gradual rollouts.
Each strategy has its merits and can be adapted based on the unique processes and release cycles of the agile team. However, they all promote continuous integration, fast feedback loops, and collaboration, which are core aspects of agile.

4. Agile Framework Implementation

Implementing an Agile framework within GitHub involves using the platform's built-in features to manage and track the progress of software development sprints. Here's a step-by-step breakdown of setting up your Agile workflow in GitHub:

Setting Up a Project Board

Accessing GitHub Projects: Navigate to the 'Projects' tab in your repository or organization's page and click 'New project'.
Create a New Project Board: Choose a board name, a template (you can select Kanban for an Agile project), and provide a description if desired.
Customize Columns: By default, Kanban boards come with "To do", "In progress", and "Done" columns. You can rename these columns or add new ones to reflect your sprint workflow (e.g., "Backlog", "Review", "QA").
Move Issues: Drag and drop issues to different columns as they progress through different stages of development.
Automation: Use automation to streamline workflows. For example, issues can automatically move to a "Done" column when they are closed.

User Stories as Issues

Creating an Issue for Each User Story: From the “Issues” tab in your GitHub repository, click "New issue" to create an individual issue for each user story.
Writing User Stories: In the issue, detail the user story following the typical "As a [type of user], I want [an action] so that [a benefit/outcome]" format.
Labeling and Tagging: Apply relevant labels to each issue for easy categorization (e.g., "feature", "bug", "enhancement"). This helps in organizing the backlog and prioritizing work.

Sprints with Milestones

Creating Milestones: Navigate to "Issues" and then to "Milestones" within your GitHub repository and create a new milestone for each sprint.
Setting Sprint Duration: Assign start and end dates to your milestones to define the sprint's timeframe.
Linking Issues to Milestones: Associate each user story issue to a milestone to track what work is planned for which sprint.
Tracking Progress: Utilize the milestone page to track the progress toward sprint goals, checking off completed user stories and monitoring open ones.

Task Assignments

Assigning Issues: When you create or edit an issue, you can assign one or more team members responsible for the work. Use the "Assignees" section on the right-hand side of the issue page.
Dividing the Work: Ensure that tasks are evenly distributed among team members, and no one is overloaded. This is done by comparing assignments across issues in the sprint.
Notifying Assignees: When you assign a team member to an issue, they receive a notification, allowing them to start working on the task immediately, if needed.
Team Collaboration: Encourage assignees to collaborate within the issue itself, using comments for updates, questions, and discussions related to the user story.
By following these steps to set up your Agile framework on GitHub, the platform becomes not just a code repository, but a powerful tool for managing your software development process with visibility and clarity into your team's workflow.

5. Working with GitHub Issues

Creating and Labeling Issues

Issue Creation for New Features, Bugs, and Chores:
Creating an Issue:
Navigate to the respective GitHub repository.
Click on the 'Issues' tab at the top of the repo.
Select the 'New issue' button.
Fill in a descriptive title and a detailed comment explaining the feature, bug, or task.
Labeling Issues:
On the right side of the issue creation or edit screen, locate the "Labels" section.
Click on the 'Labels' dropdown to reveal existing labels.
Select applicable labels for the issue. Common labels include 'bug', 'feature', 'enhancement', and 'help wanted'.
To create a new label, click on "Labels" in the repository's "Issues" tab, then select 'New label', define its name and color, and save it.
Using Labels for Prioritization:
Create priority labels such as 'priority: high', 'priority: medium', and 'priority: low'.
Apply these labels to issues based on their importance and urgency relative to the project's goals.
Ordering the Issues:
Reorder the issues in the 'Issues' tab or within a project board to prioritize.
Use milestones or due dates to set timeframes for when particular issues should be addressed.

Creating Issue Templates

Purpose of Issue Templates: To streamline the process of issue reporting, ensuring that all necessary information is provided and to standardize the format for different types of issues.
Creating Templates:
Accessing the Template Directory:
Navigate to the settings of the GitHub repository.
Go to 'Options' and scroll down to the 'Features' section.
Check if 'Issues' is active and then click on 'Set up templates'.
Adding a Template:
Choose from GitHub's predefined templates or click on 'Add a custom template'.
Provide a template name, and fill in the title, description, and placeholder content that outlines the required information for the issue.
You can specify labels that should be automatically applied to issues when using this template.
Configuring the Template File:
Create or edit markdown (.md) files within the .github/ISSUE_TEMPLATE/ directory in the repository to custom define or modify templates.
Use YAML frontmatter to define the name, about info, title, and default labels for the template.
Example Template File:
name: Bug Report about: Create a report to help us improve title: 'Bug: ' labels: bug, priority: high assignees: ''
--- ## Describe the bug A clear and concise description of what the bug is.
## To Reproduce Steps to reproduce the behavior:
## Expected behavior A clear and concise description of what you expected to happen.
## Screenshots If applicable, add screenshots to help explain your problem.
## Additional context Add any other context about the problem here.
By leveraging issue templates and labels, teams can more effectively manage their workload and focus their attention where it’s needed most. Issue templates enhance consistency and clarity in issue reporting, while labels facilitate efficient categorization and prioritization.

6. Managing Branches and Pull Requests

Managing branches and pull requests are key aspects of workflow in Git and platforms like GitHub. Here's a comprehensive explanation and workflow for managing these facets effectively:

Feature Branch Workflow

The Feature Branch Workflow is a powerful way to add new features or tasks. It keeps the main branch (e.g., main or master) stable while development work is done in separate branches.
Create Feature Branch:
Check out the main branch and pull the latest changes: git checkout main && git pull.
Create a new branch: git checkout -b feature_branch_name.
Push the branch to GitHub: git push -u origin feature_branch_name.
Perform regular commits to the feature branch with clear, descriptive messages.
Push the commits to the remote feature branch: git push origin feature_branch_name.
Keep Feature Branch Updated:
Periodically merge changes from the main branch into your feature branch to reduce merge conflicts later: git merge main.

Pull Requests

Pull Requests (PRs) are a way to propose changes and facilitate code reviews before changes are merged into the main branch.
Open Pull Requests:
Go to the repository on GitHub.
Click on 'Pull requests' then 'New pull request'.
Select the base branch (where changes should go) and compare branch (the feature branch).
Provide a comprehensive description of what the PR covers.
If the feature branch is behind the main branch, GitHub may provide an option to update it.
Review Process:
Reviewers can be assigned to the PR.
Automated checks like CI/CD (Continuous Integration/Continuous Deployment) runs.
If automated merger setting configured: 'Auto-merge' can be set up if all status checks pass.

Code Reviews

Code Reviews are crucial for maintaining code quality and are typically done within the pull request on GitHub.
Conduct Code Reviews:
Project members provide comments, ask questions, and suggest improvements in the 'Files changed' tab of a PR.
Respond to feedback or make additional commits to address the reviews.
Use GitHub's 'Request changes' or 'Approve' features to formally review the PR.
Collaborate on Pull Requests:
Conversations can be resolved once they're addressed.
Changes are pushed to the same feature branch, automatically updating the PR.


Once a PR has been approved and all status checks pass, it can be merged into the main branch.
Merge Pull Request:
Click on 'Merge pull request' on GitHub once all reviews are favorable and status checks are green.
Choose the merge strategy (e.g., merge commit, squash, or rebase).
Confirm the merge.
GitHub may provide the option to delete the feature branch post-merge to keep the repository clean.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.