[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-seo-573854-105":3,"detail-sidebar-cat-1-en-105":74,"doc-detail-573854-en":120},{"code":4,"msg":5,"data":6},0,"ok",{"site_id":7,"language":8,"slug":9,"title":10,"keywords":11,"description":12,"schema_data":13,"social_meta":67,"head_meta":69,"extra_data":71,"updated_unix":73},105,"en","code-publishing-cheat-sheet-project-git-workflow","Code Publishing Cheat Sheet - Project - Git Workflow","","Code Publishing Cheat Sheet provides guidance for publishing and collaborating on software projects with a focus on consistent Git workflows, disciplined branch strategies (main/develop/feature/*), and standardized commit message conventions. It outlines general coding principles such as avoiding code/design smells, using separation of concerns, applying REST principles for APIs, and following clear naming and style guides across languages. It also covers project structuring, documentation expectations (docstrings, Sphinx/Read the Docs, JSDoc), dependency management, and release-related practices like changelogs and contributor onboarding.",{"@graph":14,"@context":66},[15,34,49],{"@type":16,"itemListElement":17},"BreadcrumbList",[18,23,27,31],{"item":19,"name":20,"@type":21,"position":22},"https://docshare.wps.com","Home","ListItem",1,{"item":24,"name":25,"@type":21,"position":26},"https://docshare.wps.com/template/","Template",2,{"item":28,"name":29,"@type":21,"position":30},"https://docshare.wps.com/template/presentations/","Presentations",3,{"item":32,"name":10,"@type":21,"position":33},"https://docshare.wps.com/template/code-publishing-cheat-sheet-project-git-workflow/573854/",4,{"url":32,"name":10,"@type":35,"author":36,"headline":10,"publisher":39,"fileFormat":42,"inLanguage":8,"description":12,"dateModified":43,"datePublished":43,"encodingFormat":42,"isAccessibleForFree":44,"interactionStatistic":45},"DigitalDocument",{"name":37,"@type":38},"dhado","Person",{"url":19,"name":40,"@type":41},"DocShare","Organization","application/pdf","2026-10-14",true,{"@type":46,"interactionType":47,"userInteractionCount":4},"InteractionCounter",{"@type":48},"ViewAction",{"@type":50,"mainEntity":51},"FAQPage",[52,58,62],{"name":53,"@type":54,"acceptedAnswer":55},"What Git workflow practices does the cheat sheet recommend?","Question",{"text":56,"@type":57},"It recommends being consistent across contributors and using a structured branching model: main for the latest release, develop for integration/working, and feature/* for isolated development.","Answer",{"name":59,"@type":54,"acceptedAnswer":60},"How should Git commit messages be formatted?",{"text":61,"@type":57},"Use a blank line to separate subject from body, keep the subject within 50 characters, capitalize it, avoid a trailing period, use imperative mood, and wrap the body at 72 characters while following the provided [what/how/why] structure.",{"name":63,"@type":54,"acceptedAnswer":64},"What general coding principles are emphasized?",{"text":65,"@type":57},"Avoid code smell and design smell, do not repeat yourself (DRY), separate concerns (code and data, follow patterns like MVC/MVVM), apply REST principles for APIs, and prioritize meaningful names and readable code over unnecessary or misleading comments.","https://schema.org",{"og:url":32,"og:type":68,"og:title":10,"og:site_name":40,"og:description":12},"article",{"robots":70,"canonical":32},"index,follow",{"doc_id":72,"site_id":7},573854,1791949188,{"code":4,"msg":75,"data":76},"success",[77,81,86,91,96,101,106,111,116],{"id":78,"doc_module":22,"doc_module_name":25,"category_name":29,"show_sort_weight":79,"slug":80},11,90,"presentations",{"id":82,"doc_module":22,"doc_module_name":25,"category_name":83,"show_sort_weight":84,"slug":85},12,"Resumes",80,"resumes",{"id":87,"doc_module":22,"doc_module_name":25,"category_name":88,"show_sort_weight":89,"slug":90},14,"Invoices",70,"invoices",{"id":92,"doc_module":22,"doc_module_name":25,"category_name":93,"show_sort_weight":94,"slug":95},15,"Posters",60,"posters",{"id":97,"doc_module":22,"doc_module_name":25,"category_name":98,"show_sort_weight":99,"slug":100},16,"Social Media",50,"social-media",{"id":102,"doc_module":22,"doc_module_name":25,"category_name":103,"show_sort_weight":104,"slug":105},17,"Forms",40,"forms",{"id":107,"doc_module":22,"doc_module_name":25,"category_name":108,"show_sort_weight":109,"slug":110},18,"Letters",30,"letters",{"id":112,"doc_module":22,"doc_module_name":25,"category_name":113,"show_sort_weight":114,"slug":115},21,"Paper Templates",5,"papers-templates",{"id":117,"doc_module":22,"doc_module_name":25,"category_name":118,"show_sort_weight":4,"slug":119},158,"General","general-158",{"code":4,"msg":75,"data":121},{"doc_id":72,"user_id":122,"nickname":37,"user_avatar":123,"doc_module":22,"category_id":78,"category_name":29,"doc_title":10,"doc_description":12,"doc_content":124,"file_id":125,"file_url":126,"file_type":127,"file_size":128,"view_count":4,"is_deleted":4,"is_public":22,"is_downloadable":22,"audit_status":22,"page_count":22,"language":129,"language_code":8,"site_id":7,"html_lang":8,"table_of_contents":130,"faqs":131,"seo_title":132,"seo_description":12,"update_tm":73,"read_time":4},5909893218464,"https://ap-avatar.wpscdn.com/davatar_085a072bc5b1113ac321206ff7593b45","Code Publishing Cheat Sheet  \nProject  \nMust: Share the source code  \nGit workflow  \nWHY? Be consistent to facilitate work between contributors  \nA Git workflow will help you to structure how you use Git (branches, pull/merge requests,   ), you can adapt it for your use case, the point is to be consistent between all contributors.  \nTOOLS: Git Workflows: Gitflow / Gitlab flow / Github flow  \nTypical branch structure:  \n➔ main: always points to the latest release / version ➔ develop: integration/working branch ➔ feature/*: work on separate feature branches  \nGit commit message  \nWHY? Having a consistent message format enable a better collaboration  \n❏ Separate subject from body with a blank line ❏ Limit the subject line to 50 characters ❏ Capitalize the subject line  \n❏ Do not end the subject line with a period ❏ Use the imperative mood in the subject line ❏ Wrap the body at 72 characters  \n❏ Use the [body to explain](body to explain what and why vs. how)[ what](body to explain what and why vs. how)[ and](body to explain what and why vs. how)[ why](body to explain what and why vs. how)[ vs.](body to explain what and why vs. how)[ how](body to explain what and why vs. how)  \n[TOOLS](TOOLS:)[:](TOOLS:)  \n➔ gitmoji  \n➔ conventional-commit  \n➔ commit-lint  \n\n| Project structure\u003Cbr>Following the language and/or framework scaffolder by using a project initializer:\u003Cbr>WHY? Allow the app to scale: grow, stay maintainable, extendable; Easier for new contributors since it will follow existing patterns.\u003Cbr>TOOLS:\u003Cbr>● JavaScript/TypeScript\u003Cbr>○ Vue CLI (have a look to existing project like\u003Cbr>vuetify/quasar/element-ui)\u003Cbr>○ Angular CLI\u003Cbr>● Python: there is no “official”project layout, but a general one would look like the following on the right | my_app/  │\u003Cbr> ├── my_app/  │ ├── __[init__.py](init__.py)\u003Cbr> │ ├── [core.py](core.py)\u003Cbr> │ └── [helpers.py](helpers.py)[ ](helpers.py) │\u003Cbr> ├── tests/  │ ├── [test_basic.py](test_basic.py)[ ](test_basic.py) ├── docs/  │ ├── [conf.py](conf.py)[ ](conf.py) │ ├── index. rst  └── [setup.py](setup.py)[ ](setup.py) ├── .gitignore\u003Cbr> ├── LICENSE  ├── [README.md](README.md)[ ](README.md) ├── requirements.txt |\n| --- | --- |\n\n[pierre.guilbert@epfl.ch](pierre.guilbert@epfl.ch /)[ /](pierre.guilbert@epfl.ch /)[ ](pierre.guilbert@epfl.ch /)[21.06.2022 / enac-it4r](21.06.2022 / enac-it4r)  \nCode  \nGeneral principles  \n● Avoid code smell & design smell (cf wikipedia)  \n● Don’t Repeat Yourself (DRY/AHA)  \n● Separation of concerns  \n○ Separate Code and Data  \n○ Follow design patterns like mvc or mvvm.  \n○ css/js/html  \n● REST Principles (for APIs)  \n○ Statelessness  \n○ Cacheability  \n○ Uniform interface  \nGeneral advices  \n● Meaningful names for variables, functions et c  \n● Avoid acronyms and abbreviations: prefer readability  \n● Avoid the obvious comment: best practices for writing code comments  \n● Better no comment than a faulty comment!  \n● Be consistent  \n● Refactor Early and Often  \n● No dead code: WHY? It’s unnecessary to keep code that is unused or commented. That’s what the versioning is for.  \n● No magic numbers: WHY? More readable to name constant, more maintainable (one place)  \n● Limit lines per files : If it’s too big you’ll spent time looking for the part of the code, use modules  \n● limit characters per line : WHY? you don’t want to scroll horizontally, it’s more readable for the brain (usually max 120/160 char, 80 char recommended) . E.g Books  \nCoding style  \nSelect a code style for each language and enforce them in the whole project WHY? consistency is key for maintainability/readability/contributors TOOLS:  \n\n| Language | Style Guide | Enforcement tool |\n| --- | --- | --- |\n| Python | PEP 8 | Flake8 |\n| JavaScript/TypeScript | Prettier | ESLint |\n| C++ | Google C++ Style Guide | Cpplint |\n| VueJs | eslint vue | eslint-plugin-vue |\n\n12 Factor  (link to an illustrated version)  \n1. One codebase tracked in revision control, many deploys/environemnent(prod/test/dev)  \n2. Explicitly declare","cbCaibZoPqXftkgA","https://ap.wps.com/l/cbCaibZoPqXftkgA","pdf",332856,"English","# Project\n## Git workflow\n## Git commit message\n## Project structure\n## General principles\n## Coding style\n## 12 Factor\n## Documentation Dev Tools\n## Packaging & Dependency Management","[{\"question\":\"What Git workflow practices does the cheat sheet recommend?\",\"answer\":\"It recommends being consistent across contributors and using a structured branching model: main for the latest release, develop for integration/working, and feature/* for isolated development.\"},{\"question\":\"How should Git commit messages be formatted?\",\"answer\":\"Use a blank line to separate subject from body, keep the subject within 50 characters, capitalize it, avoid a trailing period, use imperative mood, and wrap the body at 72 characters while following the provided [what/how/why] structure.\"},{\"question\":\"What general coding principles are emphasized?\",\"answer\":\"Avoid code smell and design smell, do not repeat yourself (DRY), separate concerns (code and data, follow patterns like MVC/MVVM), apply REST principles for APIs, and prioritize meaningful names and readable code over unnecessary or misleading comments.\"}]","Code Publishing Cheat Sheet - Project - Git Workflow | PDF"]