I want to contribute to a git repository. From the tutorials and other things what i found is i have to fork the repository to achieve this. So i forked the repository and then i cloned my copy of code in SourceTree.
Now in the repository property i changed the user name to the owner of that repository in the optional extended integration section.
Then i changed the code where needed and pushed to master branch. Currently its showing that i made contribution in my repository but i want those changes to reflect in the main repo.
Can anyone guide me how can i do this.
You need to issue a pull request then.
As long as the core developer (team) has not added you as a contributor and granted writing rights on the repository, there's no way you can contribute directly. Your only option then is to work on your own fork and hope the developers have and take the time to review and incorporate your pull requests.
Related
For a project with multiple developers where one developer controls what goes to production: This developer pushes from his own branch <his_branch>, and everyone has to incorporate their changes into his branch. His branch contains his changes and the changes other developers' changes. How do I make sure I pull down his most recent branch and work from it on my local. I have tried so many different commands and approaches, with the most recent being:
Git clone the repository (done when I started the project)
Fetch his branch
Create a working branch <my_branch> from <his_branch>
git checkout -b my_branch origin/his_branch
(I get errors)
Create my branch on remote
Fetch all including my new branch (but my new branch contains code from Master)
Access my branch locally, work on it, commit changes, create a pull request for him to review
(I don't have his latest code) and there are many conflicts to resolve
I am new to GitHub and can't find a fairly straightforward answer to this question. Typically people who answer this question, make sure they provide the most complicated solution to follow to try to impress with their GitHub acumen.
Can someone provide a straightforward answer without snark, condescension, or derision?
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
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 a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.
The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?
GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:
Clone the repository, git pull, and ensure your local copy is completely up to date.
Delete the repository on GitHub.
Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)
git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)
FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.
It is unfortunate that GitHub does not provide a way to configure the default PR target repo.
If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.
If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:
mark repo A as Private
mark repo A as Public again
After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.
Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(
Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work.
In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).
When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.
The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.
Yes, it's a bad situation...
The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.
But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.
On Github, most of the open source projects already have many existing commits. If I want to make my contribution to such a project, since I don't know which step the current project is, and I don't know what's needed to be done next, how should I start my contribution? Anyone who ever made some contributions, how did you start, I will really appreciate it if you can share some of you experiences.
On GitHub specifically, you
fork a repo you want to contribute to (that allows you to have your own copy on GitHub)
you clone that forked repo locally
you make a dedicated branch for your new commits (your contribution)
you push it back to your fork (after rebasing it on top of the latest commits from upstream, to make sure your work is applied on top of the most recent evolutions from the original repo)
you make a PR (pull request) from that branch.