![]() ![]() Of course there's probably an improvement that could be done here as well.įor example make npm run dist do all of this, but my personal preference is to do these steps manually. Now you'd deploy not from a folder, but from a branch, which holds the latest compiled version of your site in GitHub pages. , and only the files needed for deployment, will be on this branch, which is really convenient, because it keeps the src history seperate from the deployment history. Here your src files will be untouched, along with their own history in main, or cd. This is unlike git checkout dist, which would append the dist directory, with the auto generated build files to your working tree, intermingling your main and deployment histories, which is inconvenient. The folder dist now has a separate branch, with it's own, unrelated history to main,Īnd all you have to do to switch is cd dist to access that branch ( gh-pages). So what's happened here is quite interesting. and run git status again, the response will be On branch main.Īnd git log will show all of your original commits to main. If you run git status it will reply On branch gh-pages.īut when you cd. ![]() # Add all generated files to staging area git commit -m "v0.0.3" # Update the version history of the gh-pages branch git push # Push changes to gh-branch If you are using Jekyll, github provides a documentation of how to run that yourself.Npm run dist # Build website with new changes Removes dist and re-creates it cd dist # Move to gh-pages branch by switching into a directory (cool huh) git add. nginx or Apache) running on your local machine. If your site is just static you could test it using a webserver (e.g. I'm not sure why you need to watch your site via github pages. To do so proceed as described above for the master branch. However in that case you always need to push your changes to the branch gh-pages. If you can't mess with the master branch of the repository b, an alternative might be to create a separate repository for viewing your changes and create a project site as described here: As long as you are only pushing different local branches to b/master, this will always show the local branch you have pushed the last time. This shows you all branches (remote or local) which contain that commit. ![]() To do that you could do something along with this:įirst make sure to fetch all changes from the b remote and show the last commit of the master branch: git fetch bįrom that commit pick the commit hash and then check if it is contained in any other branches: git branch -a -contains However be very careful doing this and make sure the remote does not contain any commits which will be lost doing so. In that case you can enforce the push using the -f option. ![]() Please be aware that this will fail if the remote master contains commits which are not in you local branch. You can push any other branch to the master branch of b and then view it at b.github.io like this (assuming b is added as a remote to your local repository): git push b somebranch:master If the only point of the b repository is to test your changes, just stop to keep the two master branches in sync and put your changes to be pulled in the master branch to view it on b.github.io. However there might be options to view the site which would be shown if another branch were your master branch. First of all I think there is no way to just view another branch on github pages. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |