Effective GitHub Repository Maintenance and Cleanup Strategies Quiz

Challenge your knowledge of best practices, tools, and strategies for maintaining and cleaning up repositories on GitHub. This quiz covers essential workflows, automation techniques, and organization tips for an efficient repository ecosystem.

1. Archiving Inactive Repositories

   What is the recommended action to take with a repository that is no longer actively maintained but may still be useful for reference?

   1. Archive the repository to make it read-only while preserving its content
   2. Delete the repository to remove all traces
   3. Rename the repository to indicate inactivity
   4. Transfer the repository to a personal account

   Explanation: Archiving a repository ensures that it becomes read-only, preventing new changes while keeping its content accessible for reference. Deleting would remove all its data, which isn't ideal if future reference is needed. Renaming may help indicate status but doesn’t prevent changes, while transferring shifts ownership rather than signaling inactivity.

2. Cleaning Up Stale Branches

   Which method is most effective for identifying and removing stale branches in an active repository with many contributors?

   1. Review branch activity and delete branches that have not seen updates for a significant period
   2. Delete all branches except the main branch annually
   3. Rename inactive branches with a prefix like 'old-'
   4. Ignore branch maintenance to avoid mistakes

   Explanation: Reviewing branch activity allows you to target branches that are truly stale and are no longer needed. This is preferable to deleting all but the main branch, which risks removing valuable features. Renaming doesn't solve clutter, and ignoring maintenance allows build-up of obsolete work, making collaboration harder.

3. Automating Issue Cleanup

   If a repository accumulates a large number of outdated or ignored issues, what is a practical way to automate their management?

   1. Use issue management tools to automatically close issues after a period of inactivity
   2. Manually check each issue every month
   3. Label old issues but keep them open indefinitely
   4. Assign all old issues to a single team member

   Explanation: Automated issue management tools can close issues after prolonged inactivity, keeping the issue tracker clean and relevant. Manually reviewing each issue can be time-consuming and impractical for large repositories. Simply labeling issues doesn't reduce clutter. Assigning all issues to one person can overwhelm them and is not an effective strategy.

4. Maintaining Repository Documentation

   Why is it important to regularly update a repository's documentation, such as the README file, after significant code changes?

   1. It helps all contributors and users understand the current state and usage of the project
   2. It prevents the repository from being archived automatically
   3. It increases the number of repository stars overnight
   4. It reduces the branch merge conflicts directly

   Explanation: Keeping documentation updated ensures accurate communication of project usage and changes to contributors and users. Documentation alone doesn’t prevent an archive, doesn’t directly affect popularity or stars, and does not resolve merge conflicts, which are source code issues.

5. Optimizing Repository Size

   A repository contains many large, outdated binary files. What is the most suitable approach to reduce its size without losing essential history?

   1. Use a history-rewriting tool to remove large files and advise contributors on best practices for file storage
   2. Manually delete the files in the latest commit
   3. Add a .gitignore entry for binary files and do nothing else
   4. Recreate the repository from scratch and copy only active files

   Explanation: History-rewriting tools specifically address removing files from the entire history, effectively reducing size. Manual deletion only affects the latest commit and won't reclaim past space. .gitignore prevents future additions but doesn’t change history. Recreating the repository loses valuable information unless done very carefully and is more disruptive.