Skip to content

Git Flow

There's only one rule: anything in the master branch is always deployable.

  1. Everyone starts from master, and targets master.
  2. Use feature branches, no direct commits on master
    Example: <JIRAKEY-##>/[feat|fix|chore|docs]/set-page-title-from-admin
    When done for the day/issue:
    • merge origin master into your branch
    • do git commit using commit template
    • and git push origin JIRAKE-##/feat/set-page-title-from-admin to origin
  3. Perform code reviews before merges into master, not afterwards.
    • if MR is not ready yes prepend WIP: to it. (example: WIP: feat(JIRAKEY-123): set page title from admin)
    • After MR is approved and tested the reviewer can merge the branch into master if there are no conflicts.
    • In case of conflicts the assigne needs to do a git pull origin master on his feature branch from the MR and resolve them
  4. Builds are automatic, based on branches or tags
    Wordpress stage/…, dev/… and tag vX.Y.Z are used to create a distribution ready theme or plugin.
    • stage/… creates REPO-URI-stage named theme/plugin
    • dev/… creates REPO-URI-dev named theme/plugin
    • vX.Y.Z creates a theme/plugin without sufix but has this tags version set in style.css or REPO-URI.php plugin file
  5. Tags are set by the project maintainer, not by CI.
  6. Releases are based on tags.
  7. Pushed commits are never rebased.
  8. Fix bugs in master first and release branches second.

Repository

  • repo should have a description if it's a child theme and should be tagged with child, PARENT-THEME-SLUG
  • repo slug should be the same as the theme / plugin slug
  • plugin default file should be named like THEME-PLUGIN-SLUG.php
  • no user generated files (uploads or any other form of file generation by users)
  • no config files (only templates for them)
  • no private keys or other security tokens

Legend:
<JIRAKEY> is used if you got your task from jira
<type> = feat|fix|chore|docs
MR = merge request

Commit

<type>(<JIRAKEY>): <subject>

- add title field to post type

  • Test Before You Commit

    Resist the temptation to commit something that you "think" is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more importantwhen it comes to pushing / sharing your code with others.

  • Commit Related Changes and Commit Often

    A commit should be a wrapper for related changes.
    example: fixing two different bugs should produce two separate commits
    Small commits make it easier for other team members to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

  • Don’t Commit Half-Done Work

    You should only commit code when it's completed. This doesn't mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature's implementation into logical chunks and remember to commit early and often. But don't commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s "Stash" feature instead.

  • Commit messages reflect intent.

    Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:
    what you did,
    why you did it
    explanation why like this over any other options
    Use the imperative, present tense ("change", not "changed" or "changes")

  • Revert a commit.

    If the commit Reverts a previous commit, it should begin with revert followed by (<JIRAKEY-##>): <subject> of the reverted commit
    example: revert(<JIRAKEY-##>) option to set page title from admin

Merge

<type>: option to set page title in wp admin
<JIRAKEY>
- [x] add title field to post type
- [x] show field in page.php template

<JIRAKEY>
- [ ] some part of the ISSUE which is not completed and short explanation why

---
Closes <JIRAKEY>,<JIRAKEY>|#<ISSUEID>,#<ISSUEID>

If there are more types of chores that were done create a separate list for each diferent type but keep only one footer for issues that were closed
example: 

feat: option to set page title in wp admin
<JIRAKEY>
- [x] add title field to post type
- [x] show field in page.php template

<JIRAKEY>
- [ ] some part of the ISSUE which is not completed and short explanation why

fix: show dropdown menu over content
<JIRAKEY>
- [x] add title field to post type
---
Closes <JIRAKEY>,<JIRAKEY>

Example

Clone repo, checkout development branch, switch to new feature branch

git clone [email protected]:qloud/bookick/Bookick-Website.git
git checkout development
git checkout -b feat/YOUR_FEATURE_BRANCH_NAME

Start the app to review it localy

cd Bookick-Website
npm install
PORT=7000 PORT_API=7000 node server.js

Start working on changes / fixes

…

Add changes / fixes to branch, commit and push

git add -u # adds only changed files
git add path/to/new/file-folder # use this to add new files or folders if needed
git commit -m"feat: [Commit messages reflect intent](#commit-messages-reflect-intent)"
git push origin feat/YOUR_FEATURE_BRANCH_NAME

Create MR

Use merge template