Table of Contents
Introducing GitHub
...
The body of the commit should contain a reference to issue that is addressed (closes and/or fixes). Example:
- git commit -s -m "fix(core-data): fixed some big error description" -m "fixes: #123"
- git commit -s -m "fix(core-data): fixed some big error description" -m "closes: #123"
EdgeX GitHub Getting Started
...
2. Create a local clone of your fork.
$ git clone git@github.com:$MYACCOUNT/$REPO |
|---|
3. Configure Git to sync your fork with the original repository.
4. Add a remote reference so that Git can sync your fork with the master project repository.
$ cd $REPO $ git remote add upstream git@github.com:$UPSTREAM/$REPO |
|---|
A detailed example illustrating these steps is provided here.
...
1. Start new work on a new feature branch.
$ git checkout -b new-feature |
|---|
2. Update your code and commit. You can either:
a. explicitly add individual file changes in your working directory to you index.
$ git add file1.txt # or to add all files $ git add . # review changes $ git diff –cached $ git commit -s |
|---|
b. use the git commit -a to automatically stage all tracked, modified files before the commit If you think the git add stage of the workflow is too cumbersome. This basically tells Git to run git add on any file that is "tracked" - that is, any file that was in your last commit and has been modified. Please use caution when using this approach as it's easy to accidently commit files unintentionally (eg. build artifacts, temp files from editors, ...).
| git commit -as |
|---|
The -s option used for both alternatives causes a committer signed-off-by line to be appended to the end of the commit message body. It certifies that committer has the rights to submit this work under the same license and agrees to our Developer Certificate of Origin (see Contributor's Guide for more details about our DCO). E.g.
signed-off by: John Doe johndoe@example.com |
|---|
In order to use the -s option, you need to make sure you configure your git name (user.name) and email address (user.email):
$ git config --global user.name “John Doe” $ git config --global user.email johndoe@example.com
# To check $ git config --list |
|---|
3. Add a commit message: See Commit Messages section below.
4. Push work to your repository as a new branch.
$ git push origin new-feature |
|---|
5. Create a Pull Request. This is a formal request for the project's maintainers to review the diff and approve/merge, or possibly request that changes be made.
6. While that is happening you can work on something else! Sync your fork of the repository to keep it up-to-date with the upstream repository. Fetch the branches and their respective commits from the upstream repository.
$ git fetch upstream |
|---|
7. Check out your fork's local master branch.
$ git checkout master |
|---|
8. Rebase the changes from upstream/master into your local master branch. This brings your fork's master branch into sync with the upstream repository, without losing your local changes.
| $ git pull --rebase upstream master |
|---|
9. Push the updated master back to your fork.
$ git push origin master |
|---|
Note: it was suggested to use git checkout master, then git pull origin master in preference to above (to be discussed).
10. Start new feature.
$ git checkout -b new-feature2 |
|---|
11. Repeat the steps above as appropriate
12. If a change was requested on the new-feature PR then simply rebase your working branch from upstream:
$ git pull --rebase upstream master |
|---|
13. Make changes.
14. Update the PR killing off the older changes.
| $ git commit -as --amend |
|---|
15. Force push the updated PR back up.
$ git push origin new-feature2 –-force |
|---|
By using the --amend and --force options means that any of the commits that you produce should be clean, non-breaking changes at all times that get merged in, instead of having a set of patches in a PR that may have one or two 'fixup' changes.all times that get merged in, instead of having a set of patches in a PR that may have one or two 'fixup' changes.
GitHub Issue and Pull Requests
(added with approval of the TSC 9/21/21)
A GitHub issue should normally be filed for any bug discovered in EdgeX services, code or documentation flaw (with the exception of those situations noted below) and prior to any PR to fix the bug is submitted. When submitting a PR to fix the bug, the issue should be referenced as a "fix:" (the Conventional Commit fix type) for the bug in the commit comments (see Commit Message guidelines).
When submitting a GitHub issue for a bug, the submitter is requested to provide the "steps to reproduce or see" the bug. When the steps are not provided, the issue should provide some explanation as to why steps to reproduce or how to see the bug are not provided.
No bug issue is required for:
- CI/CD (or other DevOp) needs that typically must be accomplished quickly and across many repositories and are not germane to the EdgeX application/service development
- Immediate / emergency bug fix PRs. In this case, the PR must document both the bug and the fix.
Issue creation for new features is suggested, but not required. Issue creation for features or enhancements is at the discretion of the contributor and typically done in consultation with the affected work group chairperson(s). Issues can be a good way to
- track progress, reference associated features, and seek comments and agreement on scope of work for a feature
- discuss potential features or improvements that have not yet been approved by the community for implementation
- document needs (features or enhancements) that will not be implemented in the near term but are desired in the distant future (providing a record of the need for longer term preservation)
GitHub Flow
The EdgeX project has adopted the GitHub Flow workflow, a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
...
- Choose short and descriptive names
# good $ git checkout -b oauth-migration # bad - too vague $ git checkout -b login-fix |
|---|
Identifiers from corresponding tickets in an external service (e.g. a GitHub issue) are also good candidates for use in branch names. For example:
# GitHub issue #15 $ git checkout -b issue-15 |
|---|
Use hyphens to separate words.
- When naming Feature branches common practice is to use the naming convention feature/my-feature. This allows feature specific branches to be easily identified in the repository.
- When several people are working on the same feature, it might be convenient to have personal feature branches and a team-wide feature branch. Use of a team-wide branch will require the co-operation of the project’s Maintainers/Committers to setup the branch in the main repository. Use the following naming convention:
$ git checkout -b feature/master # team-wide branch $ git checkout -b feature/maria # Maria's personal branch $ git checkout -b feature/nick # Nick's personal branch |
|---|
Merge at will the personal branches to the team-wide branch. Eventually, the team-wide branch will be merged to master.
...
- If a commit A depends on commit B, the dependency should be stated in the message of commit A.
- Similarly, if commit A solves a bug introduced by commit B, it should also be stated in the message of commit A.
- If a commit is going to be squashed to another commit use the --squash and --fixup flags respectively, in order to make the intention clear.
$ git commit --squash f387cab2 |
|---|
Merging
- Always prefer a rebase to a merge (see above)
- Do not rewrite published history. The repository's history is valuable in its own right and it is very important to be able to tell what actually happened. Altering published history is a common source of problems for anyone working on the project.
- However, there are cases where rewriting history is legitimate. These are when:
- You are the only one working on the branch and it is not being reviewed.
...
- If your branch includes more than one commit, do not merge with a fast-forward
# good - ensures that a merge commit is created $ git merge --no-ff my-branch # bad $ git merge my-branch |
|---|
Keep Commit History during the PR Review
(per Monthly Architect's Meeting of 3/15/21)
When committing during the process of PR reviews, try to keep the commit history to make it easier for reviewers to see and follow the prior feedback conversations. This means that, in general (subject to discusssions between committers and reviewers), don't squash the commit history until the PR is approved. Also, don't force push the updates during the review/feedback process. Instead, when making commits during the review process, follow the following commit process:
- Make commits with your new commit comments: git commit -s -m "your review comment with appropriate semantic version type/scope tags"
- Commit without a force: git push origin yourbranch (vs git push -f origin yourbranch)
- On the last commit when the review has been completed , do a force push in order to rebase(or whenever the PR needs to be rebased during the review cycle), a force push is ok if the PR is only being rebased: git push -f origin yourbranch
...