-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: add contributing, git, and styleguide docs #56
Conversation
e63565d
to
2d21083
Compare
docs/contributing.md
Outdated
|
||
- **Fork the Repository:** Fork the repository or create a new branch in the | ||
repository if you have write access. Prefix the branch name with your | ||
username. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it really necessary to prefix branch with username?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, it's too much. Later, it will be easier to gc dead branches etc
- **Fork the Repository:** Fork the repository or create a new branch in the | ||
repository if you have write access. Prefix the branch name with your | ||
username. | ||
- **Commit Structure:** We review each commit separately, and we do not use the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice idea, but not applicable for current development stage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're at a stage where structuring commits is not feasible, you can always squash them into a single commit before submitting your PR. It will make the life of a reviewer a bit easier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's be honest, we do not review every single commit. We review the whole code
|
||
## No-Merge Policy | ||
|
||
The broxus/tycho repo uses what is known as a "rebase workflow." This means |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed previously merges are fine. Did things change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- create branch
- make changes
- if master or upstream branch was updated - rebase on top if it. Don't merge it
- after review pr will be merged
intial state:
A - B - C (master)
\
D - E (feature)
Rebase onto master:
A - B - C - D' - E' (master, feature)
Merge master into branch:
A - B - C (master)
\ \
D - E - M (feature)
2d21083
to
a9332fc
Compare
a9332fc
to
a1af099
Compare
No description provided.