Make sure to check all the changes made before committing with a fork
So, each issue should only address one problem
If you have to define a large framework, indicate it in tens
The next level of refinement for that issue is in hundreds
Similarly, if there are further divisions, use thousands
At this point, the refined issue must always refer to the previous unit issue
00: UI
000: UI - mainView
0000: UI - mainView - animation
Always organize debugging-related issues
Separate crash-related issues
Always check the red marks to find where the error is before fixing it and pushing
Remove all yellow marks before committing as they may cause confusion in the code
Usually, only submit 2-3 issues
One is for long-term (taking several weeks) and two are for short-term (simple issues).
branch:
ver: (folk - mouse right - Copy commit SHA)
screenshot
description:
Do the work locally
Enable fork
Create a new branch with the name
feature/issue number-issue keyword
After pressing local change, check which part has been modified in Unstaged
Double-click on the parts you want to push (to be delivered) and move them to staged.
Then push and go to the site
(If the location of origin/develop is different, rebase here and force push)
Go to Pull requests
When creating a pull request, use resolving#issue number or ref #issue number in the title.
The ref command is usually used when receiving other issues during work or when the issue in progress is related to the issue being changed by another person.
Example: Brief title (resolving #22)
If you receive feedback
Comments will be added like this, and they will disappear automatically when you reflect on the corresponding parts.
If the comments are not gone because other parts have been modified, inform the other person through a reply.
Each step includes the process before merging
If you want more details, refer to the referenced issue (why was it modified? how was it modified? - The process and reasons are included, so pay attention to them)
After submitting a pull request, check for comments and sync (check the base)
Commit the modifications again, and if there are still comments, reply to them so that you become the last author.
rebase - Clean because the history changes (so it should be pushed with force push)
merge - The history remains the same and the branch remains the same
In a state where the desired branch is checked out from the fork (a changeable state)
Perform rebase on the branch you want to rebase (right-click)
Q: Do I have to push and then request a pull request after submitting new(origin/feature/38-roompage) to the current location of my branch? After that, should I rebase to origin/develop and force push, and then merge and fix the conflicts? A: No, the order is reversed.
First, rebase to develop before making a pull request to develop.
It is correct to rebase to develop before making a pull request,
After making a pull request, if another branch is merged into develop, resolve the conflicts when rebasing to develop again.
Similar to merge, but used when you only want to combine one commit
Function to modify and recommit the previous commit immediately
The premise is that you fully understand the code...
The recommended way is to use merge, but it is recommended to use kdiff through merge in external merger
When going through kdiff, all the commented Korean text gets corrupted, so if you accidentally wrote in Korean,
Go to Settings - Configure - Regional Settings
And set File Encoding for A to utf8.