OneDrive file upload vs GitHub Push

• Push to GitHub

  • version control

  • uploading the versions/changes

Collaboration using Pull Request

• push permission -> minimize admin/owner (not everyone can push)

• not as a collaborator (pull request is more important than push)

• to prevent some side effects such as deleting unwanted files/codes without permission of the owner

• then how other developers can push to the remote repo?

  • PULL REQUEST!

  • I want to change your remote repo, so could you pull my changes to the remote repo?

  • It is important to be familiar with the Pull Request

• After Pull Request -> Request Allowed -> Merge

• Conflict: several changes in the same part

How to Pull Request

1. Fork the original remote repo we want to contribute to my account

   1. Why? we are not allowed to push to the remote repo that we don't belong -> we copy the original remote repo to my repo

2. Clone the forked repo

   1. bring all contents in the remote repo to my local

3. Create a new branch, checkout the branch, and work on the branch

4. Push to the current branch we worked on

5. Send Pull Request

   1. before sending Pull Request, we always should double-check what we have done

   2. write the commit message (title + contents) - always good to write the contents long

6. Now, the owner of the original remote repo can view the Pull Request that we sent and decide to merge it to the original code.

   1. If there are multiple Pull Requests, there will be Conflicts (merge, revert, stash)

      1. Find where Conflicts occurred (marked with >>>>>>>, =======, and <<<<<<<)

      2. Re-commit

      3. Merge

   2. If others did Pull Request after I fork the original remote repo and I want to bring these changes to my repo, we can click "sync fork" on GitHub

      1. No conflicts on the sync fork, but if "pull", there could be conflicts

Commit Message Convention

Structure

type: Subject

[optional body]

[optional footer(s)]

Commit Type

tag: title

• feat: adding a new feature

• fix: fix the bug

• docs: fix document

• style: code formatting (only syntax changes, no code changed)

• refactor: code refactoring

• test: test code, adding refactoring test code

• chore: edit build task, edit package manager

Subject

• No period or special characters

• Verb (the first letter with uppercase) should be the first (no past tense verb)

  • fixed -> fix

• not the whole statement, make it a brief summary

Body

• Write the body as detailed as much

• Write the reason why the code is changed and what has been changed, not how I changed the code

Footer

• Type: #issueNum

• Optional & writing issue tracker ID

• For multiple issues, separated by ,

• Issue Tracker Types:

  • Fixes: under modification

  • Resolves: when an issue has been resolved

  • Ref: if there is an issue that needs to reference

  • Related to: issue number related to the commit (if not resolved yet)

• E.g) Fixes: #45 Related to: #34, #23

Example

Feat: "Sign Up Feature"

SMS, API to check email duplicates

Resolves: #123

Ref: #456

Related to: #48, #45