GitHub Disasters and ArchTitus

Summary

The speaker reflects on their experience with a project called 'architis,' which they had to archive due to poor management and accepting too many commits without understanding them. They emphasize the importance of following Linus Torvalds' golden rule of GitHub: not accepting commits you don't understand. The speaker shares their strategy for managing contributions in their 'win utility' project, which involves setting rules, using a test branch, and reviewing pull requests to maintain quality and avoid merging poor code.

Takeaways

• 📚 The speaker learned a lot from the Architis project but eventually archived it due to poor management.
• 🚫 They accepted too many commits without fully understanding them, violating Linus Torvalds' golden rule of GitHub.
• 🛠 The speaker emphasizes the importance of understanding each commit before accepting it.
• 📈 They found joy in contributing to projects but struggled with managing the influx of contributions.
• 📝 For the Win Utility project, the speaker set specific rules to manage contributions effectively.
• 📅 They established a three-month time limit for the test branch to encourage regular updates.
• 🔒 All pull requests to the main branch are immediately closed, ensuring that changes are tested first.
• ❌ The speaker uses the test branch as a filter to automatically weed out poor-quality contributions.
• 🔄 In cases of bad commits, they either fix the issue or rewind the commit if necessary.
• 🤝 They've experienced instances where subsequent PRs fix earlier ones, demonstrating community collaboration.
• 🌟 The speaker highly recommends understanding the GitHub branch system for effective collaboration.

Q & A

Why did the speaker stop using 'architis'?

The speaker stopped using 'architis' because it became unwieldy due to accepting too many commits and managing it poorly.

What did the speaker learn from the 'architis' project?

The speaker learned a lot of bash scripting from the 'architis' project.

What is the 'Golden Rule' of GitHub mentioned by the speaker?

The 'Golden Rule' of GitHub mentioned by the speaker is that if you don't understand a commit, you shouldn't accept it.

Why did the speaker archive the 'architis' project?

The speaker archived the 'architis' project because it became too unwieldy and they were not strict enough with their git repo.

What is the speaker's approach to handling pull requests for their project 'win utility'?

For 'win utility', the speaker sets specific rules, such as requiring all contributions to be on a test branch and reviewing every pull request.

What is the test branch policy for the 'win utility' project?

The test branch for the 'win utility' project usually lasts for three months, after which the speaker expects to make a commit or pull request.

How does the speaker handle pull requests directed to the main branch?

The speaker immediately closes and denies pull requests directed to the main branch, insisting that all contributions should be on the test branch for testing.

What happens to bad commits or pull requests according to the speaker's experience?

Bad commits or pull requests typically get cleaned out by themselves as people who make such commits often don't know how to switch branches and resubmit their PR.

How does the speaker deal with pull requests that are not perfect but almost there?

The speaker may accept a commit that is not perfect and is about 90% there, expecting someone else to step in and make another PR to fix it.

What is the speaker's advice regarding the GitHub branch system?

The speaker highly recommends understanding the branch system in GitHub as it is a lifesaver for collaboration.

How does the speaker feel about rejecting someone's work on a pull request?

The speaker feels it is hard to reject someone's work on a pull request because they are happy about the contribution but sometimes have to due to the necessity of maintaining project quality.