Last year I have been working on a project, that required gh-pages. Everything was totally fine and hosted on Github Pages. Today I started to work on another project, that will also require gh-pages. However when I started pushing local repo to github, I realized something. Somehow this newly created react app already had a remote origin with a link to that first last-year repo. How is it possible? Will my first repo stop working if I use gh-pages with this new project?
gh-pages pages is (or, rather, should be!) a branch not a repo. Your new new project should be in a new repo. Two repos can, of course, both have branches with the same name.
It sounds like you have set up the repos or the remotes for the repos incorrectly. Can you please edit your question to add the URLs of the two repos and the results of running git remote -v in the local checkouts of the two repos.
Related
I have GitHub site like example.github.io and want to load this site from the gh-pages branch!
how can I do?
now I can't change branch because my repository name is example.github.io
When you create yourusername.github.io you have to commit directly to master. It's meant as a website (unlike a repo that has a website that hosts to yourusername.github.io/reponame/*.
Since you already have a branch with the website, just merge it into the master branch. This can be done from the command line, the Github website or Github Desktop.
The logic
Example: You have a repo (username.github.io). You also have two repos set up with Github pages: repo-1 and repo-2.
username.github.io is the root. You're free to do pretty much anything you want with it. Creating directories will be relative to the root of the domain. When you connect to the domain, it finds the files from the master branch. If you go into the repo settings for username.github.io, you'll see this:
You're locked to the master branch. You can still use other branches for adding features, but what the actual website consists of is what's on the master branch.
The difference between the username.github.io repo and repo-1 or repo-2 is that username.github.io allows editing access to the directory root (e.g. http(s)://username.github.io/index.html) where as repo-1 and its connected pages would be at http(s)://username.github.io/reponame/index. Since the website is most likely wanted to stay out of the source itself, you can use an alternate branch to host it.
If you go into settings for repo-1 or repo-2, you'll see this:
Here you can pick. If you have multiple branches, you can select a different one to host the pages. You can also select the option to use the /docs folder for the website.
TL:DR; When using username.github.io, the master branch is the one that actually hosts the website. Think of it as the production branch. The others can't be accessed from the website
From the OP's comment:
So I can't use the gh-pages branch for Github site! yes?
Update Sept. 2020: yes, you now can.
You can use any branch you want.
"Build and deploy GitHub Pages from any branch"
Repositories that use GitHub Pages can now build and deploy from any branch.
Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source.
This functionality also removes the hardcoded dependency on user and organization pages having a master branch.
How can I make GitHub forget or disassociate that my repo was originally a fork of another project?
I forked a project in GitHub. I can now see "forked from whatever/whatever". The parent repository "whatever/whatever" is no longer maintained. I have been allowed to continue use of the code base of the original repository to create an independent repository.
Is there a way to detach my project from the original repository?
Update Jan 2022:
Use the GitHub chatbot-virtual-assistant at https://support.github.com/contact?tags=rr-forks&subject=Detach%20Fork&flow=detach_fork
First answer:
You can contact github support and ask them to switch your repository to "normal mode".
On this page, "Commit was made in a fork" paragraph, it is explained that one has to go through support to switch. Therefore, it is likely that there is no way to do that by yourself (unless you destroy and recreate your repo which is explained before... if you do so be careful if you have tickets or a wiki attached to your project as they will be deleted!).
You could duplicate the forked repository to a new repository (without the fork dependency) from the GitHub UI, then remove the original forked one:
Sign in to GitHub
Select the + sign in the top right corner and select Import repository.
Import your forked repository. The new repository won't have the fork dependency.
Delete the original, forked repository in the repository settings.
NOTE: This approach will not preserve issues and pull requests.
Make sure you have all the important branches and tags on your local repo, delete the github repo, recreate the repository through usual means (no forking) and push the local repository back with git push --all. Note that if you have local branches that you don't want to publish, might be worth to create a temporary clean local clone for the operation.
However, this will also get rid of wiki and issues. As the wiki is in fact it's own repository, it can be handled similarly by cloning it and then recreating and pushing. The repo address is on wiki's Git Access page (git#github.com:user/repo.wiki.git).
This leaves issues. They can be exported through the API, but as far as I know, you can only create issues and comments with your person, so importing them perfectly is impossible.
So, if you need issues to be preserved, you should go through github support as Thomas Moulard suggests.
I got the similar problem, and ended up using this github help page to solve it. I didn't mind about the wiki and issues tracker as it was for my blog using a theme kindly developed by another user.
To detach a forked repo and use it as your own after several commits without losing the whole history:
git clone --bare git#github.com:user/forked_repo.git
Create a new empty reposity new-repository on the github website.
And push a mirrored version:
cd user.github.com.git/
git push --mirror git#github.com:user/new-repository.git
One can rename on github, the forked_repository with another name to keep it as backup and check updates if needed. Or simply delete it.
Renaming the new-repository to the original name does the job. As a side effect, your commits now appear in your history.
Log in to GitHub with your credentials.
Go to https://support.github.com/contact?tags=rr-forks&subject=Detach%20Fork&flow=detach_fork.
Choose "Detach", then enter the URL or repo name of the fork as your-user-name/repository-name, and answer the other questions of the virtual assistant.
You will get an email with a ticket number where you can check the status of your request. You will also be notified per email once your repo has been deforked.
Most repository settings will stay unchanged, including user permissions, stargazers, issues, PRs, discussions, etc.
Using the info from aurelien and Clayton, I was able to do this with the following:
$ git clone --bare https://github.com/my/forked_repo.git
<delete forked_repo on GitHub>
<recreate repo on GitHub using same name>
$ cd forked_repo.git
$ git push --mirror
Here's the documentation for git clone --bare:
Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.
Here's the documentation for git push --mirror:
Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.
Note: like the other git based answers, this will not copy over issues that are not part of the git repo such as the wiki and issues. Per Tapio:
The wiki is a separate git repo and can be handled in a similar fashion per Tapio. The address is: git#github.com:user/repo.wiki.git.
Issues can be exported via the GitHub API but there are issues recreating them since they can only be created by your user, so imports will lose information.
This only applies to GitHub Enterprise, not on github.com
Logged in to an account that has admin privileges:
Go to the repository that you need to detach: https://<ghe url>/<org>/<repo>
Click on the “Site Admin” rocket on the top right corner
Click "Collaboration" on the top menu bar
Click on “Network” on the left pane
Click on “Make Root” in the Network Structure pane
Accept
This was tested on GitHub Enterprise 2.9
If you do not need any past commits (I didn't in my case), you can just:
fork the project
make a local copy of the fork (I used my IDE to do that)
delete the git folder from your local copy
commit the project as you normally would a new project.
You can just delete the fork from your github account after. Took me all of one minute and worked like a charm.
There are many suggestions that when you start a gh-pages branch, to start the branch as an orphan and remove the contents from git.
For example, here: http://robots.thoughtbot.com/its-for-the-orphans and on the official github: https://help.github.com/articles/creating-project-pages-manually/
However, would this apply if my master branch is my gh-pages branch? That is to say, my entire repo was created to be a Jekyll site. My assumption is that gh-pages branch and the master branch should be identical.
In the case where the repo is created solely as a Jekyll site, what is the best way to create and maintian the gh-pages branch for a project site? I've had troubles in the past keeping the master branch and gh-pages branches identical. One solution I've been suggested to delete the master branch and have only the gh-pages branch, is this considered bad or good practice and why?
I've also seen this suggestion of nesting repos: https://gist.github.com/chrisjacob/833223 However, it seems like I really do not need a master and a gh-pages, since my repo is only gh-pages.
However, I may also have a basic misunderstanding of this since I started using Jekyll a few days ago, please let me know if it is not correct that gh-pages would be the same as master branch for a Jekyll only project, and why.
Thanks!
master branch is eventually used for :
hosting a user/organisation site (http://github.com/username/username.github.io)
host your Jelyll code if you use a deploying strategy like with octopress (code in master, generated pages in gh-pages), mainly when you need to run plugins locally.
If you simply hosts a project site (http://github.com/username/projectName) that doesn't needs special plugins, you can safely delete master branch and use gh-pages as you main branch.
You can then make a new branch locally for testing purpose, then merge it in gh-pages before pushing to github.
The master branch is not special in any way other than being automatically created when you create a new repo. It can be safely ignored or even deleted if you don't need it.
You can delete it, that's what I do for the majority of my Jekyll sites as it means I don't push to the wrong branch!
In your repo settings just set gh-pages as the default branch and then you can safely delete Master.
If I fork a project that's hosted on github. Do I fork all the branches? How do I know which branch my fork is based on? In other words which branch will be downloaded to my PC?
Think of it this way:
The repo[sitory] corresponds to the collaborated work of the team across one or many branches. All contributors have their own copy of it.
Each fork of the main repo corresponds to a contributor's work. A fork is really a Github (not Git) construct to store a clone of the repo in your user account. As a clone, it will contain all the branches in the main repo at the time you made the fork.
Each branch within the fork and/or in the main repo can correspond to several kinds of things, depending on how you want to work. Each branch could refer to a version of the project but can also correspond to different channels of development, like hotfixes or experimental work.
The pull request (in the GitHub ecosystem) corresponds to the task. Every time I want to contribute an isolated finished task to the main repo, I create a pull request corresponding to the commits made in that task. These commits are pulled from either my fork or my branch to the main repo.
A commit is a set of changes to the code. This is one of the most interesting things about Git. You don't transfer files, you transfer logs of changes.
All branches on GitHub will be copied in a fork. (Obviously, this doesn’t include branches that were never pushed to GitHub in the first place.)
But a fork is a GitHub-to-GitHub operation; nothing is copied to your PC. It’s not quite the same as a Git clone. If you mean to ask “what’s copied when I clone a project?”, see the manual for git-clone(1).
Fork is a clone on the GitHub side (it clones everything).
When you are cloning a repo, you are getting the all history of said repo, with all its branches.
Even though you can in theory change the default branch of a remote repo, a clone from a GitHub repo mainly look for the master branch. Meaning to change the "default" branch a GitHub clone will get, you need to rename the master branch.
If you fork a project, you are making a copy of the whole project to your git hub account. you are not coping anything to your PC
To make a copy in your PC you have to clone it and pull all the stuff and you will got all branches & code of that project
This can be explained very well. You have a central repository at GitHub. Whenever you take a clone of it on your personal computer to do some changes, this local clone of the main repository is called a fork.
The branch is something different and is included in the fork/repo. Actually the branch is your work at different stage of development. They are created as and when required to save a set of functionalities, to give access to different users, to demonstrate the site to client, etc.
If you create a fork of a project from the Github website, you get all the branches from the upstream project.
If you clone from your newly minted fork to your local PC, you will have the origin remote on your PC pointing to the master branch of your fork on Github.
I would like to share a real life example of when we use Branches and when we use Forks
We have GitLab at our shop and sometimes we have to work on packages from a Laravel project. We normally create a branch and push changes to the branch that we have been testing in our local VM dev environment when working with the actual Laravel project.
Let's say our project is located at
https://github.com/yardpenalty/mainproject.git
Branch usage:
Lets say the branch is called It_doesnt_matter
Once we have our branch the way we want for production we then make our final push to this branch and create a merge request which then goes into UAT for testing.Once the test has went through QC the changes are merged into production.
The merge from the It_doesnt_matter branch is now pushed to the master project
at https://github.com/yardpenalty/mainproject.git
Let's say the package project is located at
https://github.com/yardpenalty/mypackage.git
Keep in mind the mainproject uses this package in production so we can't make changes by simply pushing them to this package (among other reasons). Let's say a web dev has to edit this package to make changes on production.
A simple branch wont work either because we can't see our changes without publishing the package etc.
Fork Usage:
Now is when we have to do a little bit of trickery with our package so we create a clone of the production package via a fork. The composer.json files can be updated to point to the fork which is now located at a User or Group path
So we will create a fork in https://github.com/yardpenalty/mypackage.git
and call it https://github.com/yardpenalty/yards/mypackage.git
Now we can update our composer.json file to point to this package in our "repositories":[ array like such such and away we go!
{
"type": "github",
"url": "https://github.com/yardpenalty/yard/mypackage.git"
}
]
Imagine situation like this:
You have a working repo in bitbucket - you were pulling revisions from another bitbucket repo in Windows 7 through TortioseHG.
Now the second project has moved to Github system and you can not pull from it anymore.
So my question is like this:
How can i somehow create new repo in bitbucket where I will pulling changes from github and from this repo i can easily pull in Tortiose HG to my working repo?
I do not want to use Github etc, so please do not advice it to me etc just help me with my question. Thank you.
The ideal solution consiste to keep local Mercurial repo, and work only with this local repo to the existing bitbucket Mercurial remote repo.
With a plugin like Hg-Git, you can at least push to and pull from a Git server repository from Mercurial, allowing you to pull from the GitHub repo to your local Mercurial repo.
From that local (Mercurial) repo, you can then work as usual with the bitbucket remote repo.
The OP adds:
It didn't work for me so i tried to transfer git repo to hg repo and from this repo pull to my working repo with changes - but it says that: abort: repository is unrelated - but I merged a lot from it. Any help here?
That makes senses, if both repos have been developed separately, you cannot push/pull 2 (mercurial) repos one into another.
This is confirmed at the bottom of the page "Understanding Mercurial", and detailed in the blog post: "What Mercurial Can't Do: Subtree Repos".
The more practical solution would be to make one extra repository (a "parent one") with your two repos declared in it as nested repository.
It would keep both repos independent, allowing to push back to the GitHub repo from your second mercurial repo.
If you don't have to push back to GitHub, but really want to have one repo in which you merge common files, then you can look in "Merge tip from an unrelated repository with Mercurial", but that is much more complex.
I would rather:
keep both repos separate
delete from the first one the common files you need to merge in the second one.
report and merge those common files in the second one.