I am new to GitHub. I don't know the correct process to merge my changes with the upstream. I followed following steps using EGit (I like to use it because I find it simple). Please help me.
On GitHub I created a fork.
For my fork I cloned a repository in Eclipse and imported respective projects.
In remotes, I added one more for the main project say Upstream(from where I forked) on GitHub.
I added some changes into my local repository.
How can I do the following part? -
Now in the meantime other people added some changes to the upstream. Now I want to integrate my changes(in the fork I created) to the latest changes(upstream) using EGit and push it to my repository and send a pull request.
Please help me.
create another remote corresponding to your fork in Eclipse
publish (push) your changes into your fork repo on github
create a merge request from the web interface in the original github repo, pointing to your changes on github
There is the procedure, how I do it.
GitHub browser UI
delete your fork with too much mess, if exists - this is in your Settings -> Danger Zone, the button is in upper menu bar in the root of fork
fork for you a new one on the foreign page, where I have access
open newly created fork and copy URI to the clipboard
Git perspective in Eclipse
create clone of your fork in my GUI Eclipse
Create a new branch in local branches and activate it
Import project from working tree in Eclipse as general project from Git perspective to actual workspace
do changes, integrate your important files to the general project (add to index etc.)
commit, push
GitHub browser UI
create Pull request from your fork directly from actual branch (recommended) or after merge in master branch
Notice, that in the picture is merge branch selected. In our real case is better to use the name, which is more descriptive.
Related
I'm trying to create a pull request on GitHub for project "original/QWERTY" so I forked the repo to "Mark/QWERTY". In Eclipse, I already have a repository set up for "original/QWERTY" and that project is in my workspace, named QWERTY.
Now if I create a new repository pointing at "Mark/QWERTY", I'll have two projects with the same name and both Eclipse and me won't like it.
I thought that it should be possible to have a branch or another remote under a repository and switch between them instead of having two copies (I mean just store the diffs). The problem is that they are different projects on GitHub so I'm not sure how to do it.
What is the correct way to set up two GitHub projects to create a pull request from my fork to the original one in Eclipse with EGit?
The usual workflow for forked repositories is to have a single local repository with a single work directory that is configured to fetch and push from/to multiple remote repositories.
With this setup, you can switch between branches that originate from different remote repositories.
The Fork a repo documentation of GitHub explains this setup when using CLI Git. Most of it should also apply to repositories hosted elsewhere.
Using the EGit documentation, it should be possible to translate these instructions into the corresponding actions in EGit.
How to manage multiple remotes with EGit is documented here: https://wiki.eclipse.org/EGit/User_Guide#Remote_Repositories
Using the information from Rudiger's comment and answer and my trial and error with branches I made my own steps. This picture also helps with terminology.
First, do these 2 things in any order:
fork the original project in the github website so now you have the original and the fork. They have the same code and branches.
create a local repository pointing to the original repo on github. Let's say you decided to select only the master branch.
Remotes: you get a new remote I'll call origin (default). configure its fetch if it's not done for you, the default specification is +refs/heads/*:refs/remotes/origin/*. This ref spec maps all the repo branches to Remote Tracking branches with the same name. If you want to only fetch the master branch then use +refs/heads/master:refs/remotes/origin/master.
Branches: you get a "Remote Tracking" branch called origin/master and a local branch called master with configuration of "Remote: origin" and "Upstream Branch: refs/heads/master". You will be working under the local master as it's the only branch right now.
Now you want to be able to push to your fork so you can create PR. You can and already did pull from the original to keep getting updates from other people's work.
Right click on "Remotes" and create a new remote, I'll call it fork (call it whatever you need). Configure its push.
the URI points to your fork the same way the origin Remote URI points to the original.
The ref mapping maps the branches. Go to "Advanced" and click "Add All Branch Specs" if it isn't done for you. You should get the spec refs/heads/*:refs/heads/*. It's easy to work with this spec but you can change it to whatever you need.
Create a local branch (right click -> switch to -> new branch) whose source is the local branch named master and the branch name is whatever suits what it does. it can be the master branch or a new branch that let's say fixes a bug, so bug 123. You do not have a Remote Tracking branch because those are used for pulls. If you also pull from fork then you will need to configure that in the Remote fork and get a remote branch.
Now you are working on a local branch bug 123 (you can see a checkmark next to it). Fix the bug in your code and in the Git Staging view you should see the files changed and the title is <Repository name> [bug 123]. Make sure you are going to commit/push to the correct branch! Stage whatever you need and commit (adds the changes to the local branch bug123) and push (creates a branch on the github repo called bug 123 if you stayed with the default spec).
Now go to the GitHub repo page of either the original or the fork and the UI will tell you that you can create a PR. From there GitHub will guide you.
Once the PR is merged into the master branch of the original on GitHubm, you will want to fetch from the master.
Right click on the Remote origin or its fetch "subdir" and choose fetch. The will fetch any changes in all the remote branches because the fetch spec we used maps all the branches (we used the * character).
That's it. Continue to switch to a local branch which maps to your fork based on the updated master, fix bug, commit and push, create PR, wait for merge into the original, fetch and pull from the original.
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.
I have forked a github repo. Now my worked repo is out of sync with the original repo.
I understand that I need to do a merge, but how to do this with Eclipse git is a bit unclear to me.
Question: How do I update my fork to include changes made to the original repo made by the owner?
Edit 1: I've added another remote. But I don't see any Pull buttons on the context menu:
You do the merge on your local machine and then push the result from your local machine to your own github repo. There is no way to update your github repo directly on the server.
To do that, add that original github repo as a new remote. This is described in the egit user manual. Choose "configure for fetch" instead and give it the URI of the original repo. Afterwards you can simply use the context menu "Pull" on that new remote node to fetch and merge all the new stuff. After finishing the merge, you "Push to upstream", which is your own github repo.
Try the second url under upstream to push your changes. The first one ist just for fetching (see the green/red arrows ;-)
I am new with both Git and GitHub so please bear with me.
I have an empty repository on GitHub with an automatically created branch (gh-pages), which, I understand, is supposed to be used with GitHub's pages functionality.
Now what I would like to do is to create and eclipse project from which I could commit/push to this repository.
What is confusing me that I can't see any option to create a remote branch on github. I suppose pushing my source to gh-pages won't be a good idea. BTW, I also don't understand why the GitHub pages is feature is implemented as a branch? Aren't branches supposed to be merged with each other at some point. Clearly it wouldn't make any sense to merge github pages into my project. Wouldn't it be better to have a folder within my project for this purpose.
I googled and found this link but being a git noob I am not sure if that's what I want to do. I would like to use Eclipse as my primary interface to git and github only falling back to command line or other interfaces when there is no other option.
OK I think I have figured it out. Basically, what you need is to define a remote ref that need not exist before hand.
Create a project
Team->Share it to a local repository
In the repository view (Window->Show View-> Git -> Repositories) select the local repository and right click on remotes
Select new remote (configure push). Type origin in the remote name. Press OK
Change URL. Copy/paste the ssh uri from github. Select ssh protocol (make sure you have ssh key defined in eclipse SSH preferences, and uploaded to github)
Now the last part is to add Ref mapping. Click on Add.. in ref mapping section of screen. And enter refs/heads/master in both local and remote branches.
Or may be the refs/heads/master on both side isn't a good idea :)
I see, cloning a github repo that doesn't have gh-pages branch is simpler as it automatically creates this remote fetch spec
Remote Fetch Specification +refs/heads/*:refs/remotes/origin/*
Maybe this is what I need to enter in the step 6 above
Ok as it turned out the original idea of "refs/heads/master in both local and remote branch" was correct. Pushing with this configuration is showing my changes in git hub correctly. The second option on the other hand is failing silently.
Branches typically are used in the way you described, but nothing says they must be used that way. This is just the way github chose to let you manage your page content, and it works quite well. It's kind of similar to hosting multiple repos on one SVN server.
As for creating new repos, if you create a repo in github and then clone it, you'll have an empty repo locally that already points to github with a remote named "origin". This is a convenient way to start out, since you don't have to mess with adding a remote yourself. At this point, your repo has no commits and no branches in it. When you make the first commit, it will automatically establish a branch named "master". I don't know how eclipse is set up by default, but from the command line with default settings, you have to explicitly push new branches to a remote or else they won't get pushed at all. I.e. making the first commit and doing git push will just fail with a message like "No refs in common and none specified; doing nothing". Instead, you have to git push origin master to tell it to establish the "master" branch in remote "origin" (aka github). Thereafter, just a git push will work fine.
Hope that clears up some of your confusion.
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"
}
]