Source Code Management

Source Code Management

Project Folder Structure

├── emf
│   ├── task_generator
│   ├── loadflow_tool
│   │   ├── model_validator
│   │   ├── model_merger
│   │   └── model_scaler
│   ├── model_publisher
│   ├── report_publisher
│   ├── model_retriever (OPDM -> ELK/MINIO)
│   ├── schedule_retriever (EDX -> ELK/MINIO)
│   └── common
│       ├── schemas
│       ├── settings_module
│       ├── logging_module
│       ├── xslt_engine
│       ├── converters
│       └── integrations
│           ├── opdm
│           ├── edx
│           ├── qas
│           ├── minio
│           └── elastic
├── examples
│   └── test_data
├── docker
│   ├── task_genrator
│   ├── igm_worker (load and validate) 
│   ├── cgm_worker (load/merge and scale)
│   ├── model_publisher
│   ├── report_publisher
│   ├── model_retriever (OPDM -> ELK/MINIO)
│   └── schedule_retriever (EDX -> ELK/MINIO)
├── config
│   ├── task_genrator
│   ├── igm_worker (load and validate) 
│   ├── cgm_worker (load/merge and scale)
│   ├── model_publisher
│   ├── report_publisher
│   ├── model_retriever (OPDM -> ELK/MINIO)
│   └── schedule_retriever (EDX -> ELK/MINIO)
├── Pipfile
├── Pipfile.lock
├── readme.md
└── .gitignore

Commit Guidelines

• Pull code regularly: Before starting work and adding commits, make sure that codebase is up to date.

• Keep commits atomic: Each commit should represent a single logical change or feature. Avoid mixing unrelated changes in a single commit.

• Summarize the change in the first line: The first line of the commit message should provide a concise summary of the change. It should be meaningful on its own and give a high-level overview of the modification.

• Reference relevant issues or tickets: If your project uses an issue tracking system or ticketing system, consider referencing the relevant issue or ticket number in the commit message. This helps with traceability and provides context.

• Avoid committing incomplete work: Try to avoid committing incomplete or work-in-progress changes. It's best to ensure that your code is in a functional and tested state before creating a commit.

Branching Guidelines

Gitflow is an alternative Git branching model that involves the use of feature branches and multiple primary branches. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete.

Branch types

• Regular branches:
  • main/master - branch stores the official release history (convenient tag all commits with version number).
  • dev - branch serves as an integration branch for features.
• Temporary branches:
  • Feature - feature branches use dev as their parent branch. When a feature is complete, it gets merged back into dev. feature branches are generally created off to the latest dev branch.
  • Release - Once dev has acquired enough features for a release, you fork a release branch off of dev. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Then branch is merged to main and back to dev.
  • Hotfix - branches are used to quickly patch production releases. They are based on main branch. As soon as the fix is complete, it should be merged into both main and dev.
  • Or any other ad-hoc purpose branch.

Branch naming convention

• Start branch name with group word like bug or WIP (work-in-progress); e.g. bug-logo-alignment-issue
• Use Unique ID in branch names if issue tracking system is used; e.g. wip-8712-add-testing-module
• Use Hyphen (-) separators that will increases the readability and helps to avoid confusion
• Use author name if necessary; e.g. rajeev.bera_feature_new-experimental-changes
• Avoid using all naming convention simultaneously
• Avoid long descriptive names for long-lived branches