New additions should be done as PRs

[Tapawingo]

To add more trackability to the repository I recommend that new loadouts and additions/changes are merged as a pull request rather than commits. Doing it like this will practically generate a changelog for use of added, removed and changed loadouts if we add them to milestones for releases. This will also make it easier to go back to a previous version without having to scan through commit hashes. And finally, for the sqf validation workflow to work automatically we have to use PRs (we can however run it manually from the Actions tab if you decide against using PRs).

The downsides to this off course is it adds some more work when editing or adding loadouts since you need to checkout a new branch before committing.

[Tapawingo]

For clarity; the commit workflow would look like the following if implemented:

1. Checkout a new branch from the master branch:
   git checkout -b <shortDescription> e.g. git checkout -b editVDVLoadout
2. Stage files and commit
   git add -A && git commit -m <description of change> e.g. "git add -A && git commit -m Added AK-74S to rifleman slot"
3. Push to GitHub
   git push origin <branch> e.g. git push origin editVDVLoadout
4. Create Pull Request
   Create a Pull request like you normally do through the GitHub webpage

[Tapawingo]

If you are using the vscode git extension the steps are even less. To checkout a new branch click the horizontal burger menu and select checkout to...:

Then commit the changes like you normally do:

[PervonHarke]

This sounds good.

Would this have to be done for each new loadout individually or can this be done as a batch of loadouts?

Would the same need to be done for updates and changes to an already existing loadout?

[Tapawingo]

Would this have to be done for each new loadout individually or can this be done as a batch of loadouts?

It can be done for a batch or individually, that's up to how you want to do it. For PR's you basically make a copy of your existing branch and make edits to it and then when you have done all the edits you can then merge it into the main branch overwriting the old files. This has the added benefit of allowing you to see what the changes will look like before merging by looking at the difference between the branches.

Would the same need to be done for updates and changes to an already existing loadout?

I'm not sure what you are asking here. If you are asking if you need to re-commit loadouts then the answer is no. If your question is if you need to do this when you make a change to a loadout then yes. Basically any write operation should be done this way.

Also I want to point out that the use of pull requests is optional. If you think that a change is so minor that creating an entire branch and PR for it is a waste you can just commit like normal.

[Tapawingo]

This was agreed on