---
# System prepended metadata

title: DUNE DAQ Git workflow
tags: [docs, DUNE-DAQ, Software Management]

---

# 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
```