Open wsloth opened 8 years ago
Good question, let me check into this and I'll get back with you soon.
Upon research and talking with my developer friend, I agree that a new docs branch is the best strategy. I have created it and merged all changes from master into it. You can pull it, commit your changes to the documentation files, then submit the PR to merge back into master.
I recommend to not do a compile/build, that way it does not regenerate wwwroot
or aot-compiled
, so the only changes being merged will be the docs files you edit. That should make it easy to manage for both of us.
The only part that will be a bit cumbersome is that you'll have to make your change in barebones
branch, then copy and paste the same file change to docs
branch. You could make any proposed changes to master
inside the docs
branch, so its basically a dev
branch of master
, if that makes sense. We might consider naming it dev
instead, let me know your thoughts.
I worked on the barebones
branch today, adding a node based API server which returns a valid JWT after logging in.
username: admin, password: admin.
Do an npm install
again to get the new node_modules, then run the api server with npm run apiserver
- now you can login against it with default admin, or create new users, and login with new user id :-)
Also cleaned up the home component to show JWT details, and made it the default component after logging in.
Awesome! I'll check it out tomorrow and do the whole docs
razzle dazzle. Thanks for the effort!
You're welcome. I've been thinking about it and I want to use a new branch strategy. I'll rename the docs
branch to dev
and leave it unprotected - this way its more clear, and also so you can contribute to the master
branch as well (indirectly). I'll also start working in the new dev
branch, and leave master
as the production branch that only receive PR's from dev
.
So, master
and dev
will be the same codebase, but we will work in dev
for our commits, and once all is good and progress is made, either you or I can submit a PR to merge into master
, which will remain a protected branch.
barebones
will continue to remain a separate detached branch, and we'll just pick and choose things to merge to and from it. How's that sound?
That sounds good, a lot like GitFlow. I work that way too at my company, so it'll be natural for me.
Yes, exactly. Sweet, I'll do that now.
I've been working on very small doc updates on branch/barebones, but some things I will want to merge to master. Obviously, making a PR merges the whole branch into master, which is not wanted anymore since I already removed KendoUI and CKEdit.
How do we go about this? A separate docs branch?