Skip to content

Commit

Permalink
♻️ Clean up and make sdlc steps more clear
Browse files Browse the repository at this point in the history
  • Loading branch information
@znatty22
znatty22 committed Jul 11, 2024
1 parent 24246e9 commit 787dc45
Showing 1 changed file with 32 additions and 29 deletions.
61 changes: 32 additions & 29 deletions .github/contributing.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,36 +7,13 @@ for its software development lifecycle. Github workflow is a simple workflow
that works well for a small project with multiple developers needing to work
on the code and review each other's code before merging into the main branch.

### Process

1. **Developer A** wants to make a change to the code
2. On their local machine, developer A checkouts a branch to make that change
3. **Developer B** wants to make a change to a different part of the code
4. On their local machine, developer B checkouts a branch to make their change
5. **Developer A** makes the change and pushes the code to the remote repo on Github
6. **Developer A** opens a Pull Request (PR) so that others can review the change
7. Other developers approve the Pull Request
8. **Developer A** squashes their branch's commits and merges the Pull Request into the main branch
9. **Developer B** updates their local main branch with the changes that were just merged
10. **Developer B** squashes their branch's commits and merges the Pull Request into the main branch
11. **Developer B** opens a Pull Request (PR) so that others can review the change
12. Other developers approve the Pull Request
13. **Developer C** wants to make a release
14. **Developer C** uses the [D3b Release Maker](https://github.com/d3b-center/d3b-release-maker) to
create a release PR on Github
15. Other developers approve the Pull Request
16. **Developer C** merges the release PR which activates a Github workflow that tags the main branch with
the next version and creates the release on Github


Let's solidify this with an example.

## 👨🏻‍💻 Develop

This assumes you've already setup your development environment. If not,
follow the steps in [Setup Dev Environment](#setup-dev-environment)

### Create a branch
### 1. 🌴 Create a branch
```shell
# Checkout your local main branch
git checkout main
Expand All @@ -49,7 +26,7 @@ git pull
git checkout -b add-patient-birth-sex
```

### Commit the change
### 2. ✏️ Commit the change

After you've made the change you want on your local machine its time
to commit that change to the project repo.
Expand All @@ -72,7 +49,7 @@ $ git add <file path to the file you want to commit>
$ git commit -m ":sparkles: Add new birthSex extension to Patient"
```

### ⚠️ Important! - Rebase
### ⚠️ 3. Important! - Rebase
If another developer has merged their code (Pull Request) while you're working
on your change, you will need to update your branch with those changes before
you continue developing.
Expand All @@ -98,7 +75,7 @@ git push -f
If you do this often you will rarely have conflicts.


## 📝 Pull Request
## 📝 4. Pull Request

Once you're happy with your changes, its time to [open a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request?tool=webui)
so that others can review your code and upon their approval you can merge your branch
Expand All @@ -117,7 +94,7 @@ with a **"Motivation"** and **"Approach"** section. Please be sure to fill these
so that reviewers can quickly and easily understand the purpose of the PR and
the changes.

## Squash and Merge
## 5. 🔀 Squash and Merge
Once your PR has been approved you're ready to merge it. Before you merge it,
you'll want to "squash" all of your commits into 1 commit. This cleans up your
branch's commit history and makes the main branch much cleaner as feature
Expand Down Expand Up @@ -172,7 +149,7 @@ versions of the IG and tie those versions to snapshots of the project.
In this project we use [Semantic Versioning](https://semver.org/) to mint
version numbers for various types of changes. Please read more at semvar.org.

## 📦 Release
## 📦 6. Release
Releases on Github are snapshots of the project at a particular point in time,
stamped with a versionn number of some kind, in our case, semantic version number.
A release can be made at any time, although, it is typical to make a release after
Expand All @@ -197,4 +174,30 @@ repo, create the Github release and attach the snapsot to the release.

The Github workflow will also publish the IG to its domain.

## 👩‍💻 Example of Workflow

Let's solidify everything above with an example.

1. **Developer A** wants to make a change to the code
2. On their local machine, developer A checkouts a branch to make that change
3. **Developer B** wants to make a change to a different part of the code
4. On their local machine, developer B checkouts a branch to make their change
5. **Developer A** makes the change and pushes the code to the remote repo on Github
6. **Developer A** opens a Pull Request (PR) so that others can review the change
7. Other developers approve the Pull Request
8. **Developer A** squashes their branch's commits and merges the Pull Request into the main branch
9. **Developer B** updates their local main branch with the changes that were just merged
10. **Developer B** squashes their branch's commits and merges the Pull Request into the main branch
11. **Developer B** opens a Pull Request (PR) so that others can review the change
12. Other developers approve the Pull Request
13. **Developer C** wants to make a release
14. **Developer C** uses the [D3b Release Maker](https://github.com/d3b-center/d3b-release-maker) to
create a release PR on Github
15. Other developers approve the Pull Request
16. **Developer C** merges the release PR which activates a Github workflow that tags the main branch with
the next version and creates the release on Github





0 comments on commit 787dc45

Please sign in to comment.