Skip to content

Latest commit

 

History

History
76 lines (58 loc) · 4.12 KB

README.md

File metadata and controls

76 lines (58 loc) · 4.12 KB
Raw

portfolio_view

GeneratER

version license

About

GeneratER (Generate-ER) is a VSCode extension for generating Entity Relationship Diagrams for your databases on the fly! ✈️
Often times developers require a quick visualisation of their databases, and our extension provides an out of the box solution for the same 🚀

Table of Contents

Demo

Usage

Quick Start

1. Fork the project and then clone it into desired directory.

git clone https://github.com/YOUR_USERNAME/GeneratER.git

File Structure

Contribution Guidelines

Refer to Quick Start 🚀 section to set up the development environment!

How to contribute?

  1. Reporting Bugs
    • When you are creating a bug report, please include as many details as possible.
    • Fill out the required template, the information it asks for helps us resolve issues faster.
  2. Suggesting Enhancements
    • When you are creating an enhancement suggestion, please include as many details as possible.
    • Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Commit Messages

  1. Commit messages are communication and documentation. They're a log of more than just what happened, they're about why it was done.
  2. The longer a project is active, the more people involved, the larger the codebase, the more important it is to have good commit messages.
  3. Make sure every change that you make is well documented and is included in your commit message.
  4. One commit should have only one change. (A change may include multiple file changes that are essential to solving the issue/change).
  5. All commit messages should be in the imperative-present tense. After all, you are telling us what you have already done.

Pull Request Guidelines

  1. Make a branch
    • Please create a separate branch for each issue that you're working on. Do not make changes to the default branch (e.g. master, develop) of your fork.
  2. Describe Your Pull Request
    • Use the template provided here
    • Use the format specified in pull request template for the repository. Populate the stencil completely for maximum verbosity.
      • Tag the actual issue number by replacing #[issue_number] e.g. #42. This closes the issue when your PR is merged.
      • Tag the actual issue author by replacing @[author] e.g. @issue_author. This brings the reporter of the issue into the conversation.
      • Mark the tasks off your checklist by adding an x in the [ ] e.g. [x]. This checks off the boxes in your to-do list. The more boxes you check, the better.
    • Describe your change in detail. Too much detail is better than too little.
    • Describe how you tested your change.
    • Check the Preview tab to make sure the Markdown is correctly rendered and that all tags and references are linked. If not, go back and edit the Markdown.
  3. Request Review
    • If a specific reviewer is not assigned automatically, please request a review from the project maintainer and any other interested parties manually.
  4. Incorporating feedback
    • If your PR gets a 'Changes requested' review, you will need to address the feedback and update your PR by pushing to the same branch. You don't need to close the PR and open a new one.
    • Be sure to re-request review once you have made changes after a code review. Asking for a re-review makes it clear that you addressed the changes that were requested and that it's waiting on the maintainers instead of the other way round.

Community

Social Media

Instagram: https://www.instagram.com/devsocbitsgoa

Devsoc's Website: https://devsoc.club/