Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Branch Management
See original GitHub issue@psiinon @thc202 @kingthorin @jaywon. Jason suggested in #237 that we add a “development” branch and I think its time we start to shift to a more mature branch management model.
I propose that we do the typical master, development, release, hotfix-someHotfix, feature-newFeature, bug-someBug paradigm. (from the classic: https://nvie.com/posts/a-successful-git-branching-model/)
Also @psiinon will be moving the HUD repo to a new location when we open source it so that we can enforce all PRs have to come from forks?
Does anybody else have thoughts? I’d like to get this established an enacted ASAP so its clean for release.
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Based on contributions in other ZAP repos that should be just a guideline IMHO (to reduce frictions), it’s not rare to see PRs done from the default branch and directly from editions in the GitHub site (also some PRs are merged without merge commit which makes the branch name irrelevant).
Sounds good to me. I’d suggest just
develop(instead ofdevelopment) for consistency, that’s what we are using in other ZAP repos.