Commit Protocol

There isn't anyone that will strictly enforce this rule. This is just a guideline, but it would be better to follow this procedure to keep everyone together.

Note that "version26" is just a placeholder for whatever the current branch is. If the software is at version 30, you would do version30 for all the branch names.

Pulling the latest software

It is recommended that before you make any changes, you pull the latest version of the code.

Usually the best place to go will be: https://github.com/orgs/kipr/projects/3

This is where versions are managed and you can see which version is the one currently in development.

There should be a branch with that version title, for example "version26". If there is no branch, then there has not been any additions past the latest version (master).

To get the new unstable version:

#Example using botui
git clone https://github.com/kipr/botui --branch version26


#If you already have an earlier point in the repository but want to get up to date.
git pull origin version26

---

Pushing Changes

Once you have made your changes, and you feel they are high enough quality to add to the project, you need to push them to a branch and start a pull request. If you are not a member of the organization, you will need to do this with your fork of the repo and then do the pull request from your fork.

#initialize the local repository (usually not necessary but good to do)
git init

#Open a new local branch for your code, preferably named for what change is being made
git checkout -b johnDoeFixBug

#Add the files and create a commit
git add .
git commit -m "insert a message here about your changes"

#Push the commit to the server
git push origin johnDoeFixBug

#You will then be prompted to enter your email and password (or give a token)

After it uploads you will go to the repository in your web browser to make a pull request.

Usually you will see this:

If you do not see this, go to the tab "Pull Requests" and open a new pull request.

Set "base" as the unstable version you want to push to (ie version26) and "compare" to your branch/fork.

Do NOT merge with master, merge with the unstable branch (ie version26)

Note:

If you are not in the organization, you must do these steps but with: https://github.com/(your username)/(project name)

Then for the pull request: https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

---

Branch Flow

To prevent bugs, there is a staging process for any new content added to the repository.

Step 1:

A developer will use the process described in "Pushing Changes" to open a pull request and merge their fork/branch with the current unstable branch (ie version26).

Step 2:

An employee of KIPR or an experienced contributor (who has been granted permission by KIPR) will check that the code is clean and well commented, if it has issues, the checker will leave a comment and request changes before merge. The code will also not be accepted if there are any unresolved merge conflicts that the checker cannot solve easily.

Step 3:

If it passes a visual check, the checker will then download the branch, make sure it compiles, and then test the relevant parts of the program to make sure the change did not break anything and does what it was intended to do. If any errors are encountered, the checker will leave that in a comment and request changes before merge.

Step 4:

If there are no issues with the changes made, the checker will approve and merge the developers fork/branch to the current unstable branch. The unstable branch will ideally be tested a significant amount, hopefully detecting any errors along the way.

Additionally, the master branch and the unstable branch will be built and tested with every merge. If the auto-build fails or Bob the Builder (Continuous Integration Bot) is down, there will be a red X marking the branch as "failed" or in some cases will show a gray box instead of a green checkmark.

Step 5:

Once the unstable branch has all of it's goals reached and has been tested. It will get merged with the master branch and a new version release will be made.

For information on version naming, see https://github.com/kipr/botui/wiki/Version-Control