![]() You can still create a branch off it, it's just not automatic. However, at least using the command-line git tools, checking out a remote branch (whether it's "origin/3.x" or "upstream/3.x") is a temporary operation – it doesn't automatically create a local branch that you can work on, it only checks out a "detached" commit. to track someone else's development fork.) (This is more general than just "upstream", you can configure any number of remotes, e.g. Your desktop repo has full copies of all branches from the upstream repo (as of the last fetch) and you can check out their commits, create local branches off them, merge or cherry-pick individual commits into a local branch, etc. If the upstream repo has some commits ahead of my fork on the 3.x branch and I click on upstream/3.x, does my working directory somehow gain the changes from those upstream commits? For example, you might integrate the newest upstream changes by merging "upstream/3.x" into your local "3.x", then push to your GitHub fork's "origin/3.x". Git repositories aren't limited to having a single URL to push/pull from – it is very common to have two when working with forks, and to directly fetch commits and branches from both. (Neither the "origin/" branches nor "upstream/" ones are actually local to the repo that GH Desktop is showing they're only locally cached copies of remote branches.) The cloned repository that you have on your desktop is fully separate from the fork that you have on GitHub – it has its own branches and everything. You're not only working on a fork you're working on a fork of the fork. How is it possible that I could switch to a branch on the upstream repo if I'm working on a fork? Diverging is expected, so the branches downloaded from a remote repository are always namespaced with "reponame/", while Hg's docs imply that a diverged bookmark is supposed to be dealt with quickly.) Though it seems that Git branches aren't kept as strictly in sync with the remote repository as Hg bookmarks are. ![]() And similarly, when you create a new local branch off "master", it's just creating a second bookmark that points to the same commit as "master". branch) is updated to point to them, so now both the local and remote bookmarks independently point to the same commit. (In fact, that's what happens when you push to GitHub – first the commits are uploaded, and then the remote repository's "main" or "master" bookmark (i.e. They're not immutably attached to commits but act as flexible pointers to some commit ID (see Mercurial's Bookmarks docs), so it is entirely possible for several repositories to have their own bookmarks pointing to the same commit. ![]() Git branches work like Mercurial's bookmarks. Delete your feature branch using the GitHub website or, delete the local branch: git branch -d new_feature, and delete then the remote: git push origin -delete new_feature.(but bear in mind I come from a Mercurial background so maybe I'm not fully understanding Git's branches - I think they exist outside the version control somehow?).Change to master: git checkout master and pull: git pull upstream master. Once the pull request is accepted, you’ll want to pull those changes into your forked-version of the repository (so that it's up-to-date).Now you're ready to open a pull request on GitHub merging your changes with the upstream (original) repository. ![]() Go back to your development branch and merge in these changes (if any): git checkout new_feature, and then git merge master.When you're done with your changes and ready to push your changes to the upstream (original) repo, we should first pull any changes in the upstream (original) repo to our forked version by going back to the master branch: git checkout master, and then pulling changes: git pull upstream master.Push your local branch to your remote repository: git push origin new_feature.Make any changes you want in this branch and be sure to push changes to the remote as necessary.In your locally cloned repo, create a new development branch to work on (here called “new_feature”): git checkout -b new_feature.As the developers of the upstream (original) repo may be making changes as you work on your version of the repo, we need this upstream remote so that we can periodically pull any new changes. Add remote called “upstream” pointing to the original repository: git remote add upstream.Clone the repository locally: git clone.Fork the GitHub repository you want to work on by navigating to the repository on GitHub and clicking the "Fork" button.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |