I am newbie in GitHub. I wonder why the option "Fork" is there when I have the option of cloning others' project and make my own repository on GitHub to extend it?
I guess the best answer I can think of is you might want to bring the fork back into the original branch, hence keeping it in the same repository.
I believe Forks were designed for playing with ideas or for suggesting changes to the owner of the repository, heres a link about it:
Github Forks
Yes, you are right, you can clone another repo and do any desired stuff.
But after that you need merge your updates into original repo (share your improvements with whole world) - and exactly for this purposes you need fork.
As far as I know, only this is the most flexible way manage your updates with original repo. And only this way can avoid undesired commit into original repo (repo owner able manage all propositions about any changes).
Related
What is the best way to record the current state of a GitHub repository so that I can reproduce results later? Never mind branches. I only care about main.
you could create a new branch based on the current one, and then go back to main and work on it, but in github itself it is possible to check the history, so it is possible to revert the changes if you want, is that more or less what you are looking for?
We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I've assumed maintainership for a given project on github. I've done so by cloning the repository of the original authors and pushing my own changes and developments. This was done in accord with the original authors, so they do not expect to work on this in the future. Nevertheless, my repository is marked as a fork of theirs, which makes it appear less official. Is there some way to denote a given repository as official? To swap the relation between my repository and that of the original developers?
I guess I could delete my repository, then ask the original devs to transfer theirs to mine, then let the original devs fork from that, then push my own changes from my local repo. But somehow this feels wrong. It would rely on my local copy. Migration of e.g. the pages branch might be causing extra trouble. I hope there is a cleaner solution.
There doesn't seem to be a clean way to do this.
It seems your best option is to ask GitHub support to convert your repository to "normal mode" as opposed to "forked from" mode.
Another solution is to delete and recreate the repository. However, this can be dangerous, as the wiki and issues data will also be deleted in this process.
If you have further questions about this then let me know in comments and I can amend my answer.
I don't want to fork a project, but I would like to submit patches for inclusion; should I do this on the issue queue?
You should fork the project. In Github, this is very cheap. This way, you can push your changes how you want to your repository, and then make a pull request to have them included in the official repository.
You can then delete your fork after that.
If you don’t fork a project, that means:
you clone the original repo directly;
you cannot push directly back to it (because you are not declared as a contributor).
Then you can indeed use the issue queue to reference a patch.
If said patch isn’t too big, you can directly copy/paste its textual form.
If not, you can copy it to some pastebin site and link it from your issue ticket.