# DUNE DAQ Git workflow ###### tags: `DUNE-DAQ` `Software Management` `docs` ## Development workflow (feature branches) Developer is recommended to follow the following development workflow regardless of the amount of committed code change, e.g. either making a quick bugfix or adding a major feature. The workflow contains the following steps: 1. Create a GitHub issue in the repo describe the bugfix or proposed feature; [optional for non-significant bugfixes] 2. Create a topic branch; (`git checkout develop; git checkout -b dingpf/issue_12_feature_dev_demo`) 3. Make code development, commit, and push the topic branch to GitHub; (`git push -u origin dingpf/issue_12_feature_dev_demo`) 4. Create pull request to `develop` branch when the topic branch is ready to be reviewed and merged, link the issue created in step 1 to the pull request; 5. The pull request gets reviewed by other developers who can: * comment on the commits in the PR; * request changes; * approve pull requests and merge to `develop`; * delete the pull request branch once it's merged (optional), and close the linked issue. 💡 If the targeted branch of the pull request has advanced, please do the following to bring the feature branch in sync before merging the PR: 1. Switch to the targeted branch, and do a `git pull` to make sure it stays in sync with the remote; 2. Switch back to the feature branch of the PR, merge the targeted branch into it, e.g. `git merge --no--ff <targeted branch name>`; 3. Push the merge to remote, and continue with the PR review/merge process. :red_circle: Please don't use `git rebase` or `git push --force`. It will likely bring unexpected consequences. ## Tagging and releasing workflow (release branches) in the current `docs` Package maintainers are the primary developers who make version tags of a package. The following workflow should be used when doing so. 1. Check the state of the `develop` branch: verify all pull requests related to the planed release have been reviewed and merged; 2. Create a release branch; (`git checkout -b release-v2.2.0 develop`) 3. Make necessary changes such as version bumps in `CMakeLists.txt` in the release branch, commit and push; 4. Optional: (mandatory if protection rules are in place for the `master` branch) create a pull request of the release branch against the `master` branch; 5. If not using pull request in step 4, merge the release branch to `master` (`git checkout master; git merge --no-ff release-v2.2.0 # always use the --no-ff option`), otherwise review and merge the pull requests (preferably done by other developers, protection rules can be set to enforce reviewing rules); 6. Tag the master branch; (`git tag -a v2.2.0 # use annotated tag`) 7. Merge the release branch to `develop` (`git checkout develop; git merge --no-ff release-v2.2.0`). If protection rules are in place for the `develop` branch, restore the release branch if it's deleted by the previous PR against `master` and create a pull request against the `develop` branch, review and merge the PR 8. Delete the release branch if the merges are not done through PRs. ## Tagging and releasing workflow (proposed) Package maintainers are the primary developers who make version tags of a package. The following workflow should be used when doing so. 1. Check the state of the `develop` branch: verify all pull requests related to the planed release have been reviewed and merged; 2. ~~Optional: (mandatory if protection rules are in place for the `develop` branch preventing direct pushes)~~ create a release branch (`git checkout -b release-v2.2.0 develop`); 3. Make necessary changes such as version bumps in `CMakeLists.txt` in the release branch, commit and push; 4. ~~Optional: (mandatory if protection rules are in place for the `develop` branch)~~ create a pull request of the release branch against the `develop` branch; review and merge the PR; 5. Tag the `develop` head and push the tag (`git tag -a -m "Candidate version for release <release_version" <package_version>`); 4. ~~Optional: (mandatory if protection rules are in place for the `develop` branch)~~ create a pull request of the release branch against the `develop` branch; review and merge the PR; 5. Tag the `develop` head and push the tag (`git tag -a -m "Candidate version for release <release_version" <package_version>`); ### common release case ### Patching release case ## Kurt's steps ```bash= git clone https://github.com/DUNE-DAQ/<repo_name>.git -b develop cd <repo_name> edit CMakeLists.txt to update the version number git commit -m "Updated version" CMakeLists.txt git tag -a -m "Candidate version for release <release_version" <package_version> git push ; git push --tags ```