7/28/2023 0 Comments Rebase git$ git checkout masterĢ files changed, 7 insertions(+), 9 deletions(-) This will bring that branch into sync with the upstream, without losing our local changes. Now that we have fetched the upstream repository, we want to merge its changes into our local branch. Remotes/upstream/master 5fdff0f Some upstream commit Remotes/origin/master a422352 My local commit # List all local and remote-tracking branches We now have the upstream's master branch stored in a local branch, upstream/master $ git branch -va Remote: Total 62 (delta 27), reused 44 (delta 9) Remote: Compressing objects: 100% (53/53), done. These are stored in your local repository under special branches. Fetchingįetching from the remote repository will bring in its branches and their respective commits. There are two steps required to sync your repository with the upstream: first you must fetch from the remote, then you must merge the desired branch into your local branch. Tip: Syncing your fork only updates your local copy of the repository it does not update your repository on GitHub. You may have done this when you originally forked. Here is GitHub's official document on Syncing a fork: Syncing a fork The Setupīefore you can sync, you need to add a remote that points to the upstream repository. Stick to the command line instead - it's easy. So yes, you can keep your repo updated with its upstream using the GitHub web UI, but doing so will sully your commit history. If you click Rebase and merge, all commits will be made "with" you, the original PRs will link to your PR, and GitHub will display This branch is X commits ahead, Y commits behind.This is most often something you don't want. If you click the dropdown and choose "Squash and merge", all intervening commits will be squashed into one.The default will create an ugly merge commit.Now you have three options, but each will lead to a less-than-clean commit history. Scroll down to Merge pull request, but don't click anything yet.Create pull request and assign a predictable name to your pull request (e.g., Update from original).Now GitHub will compare your fork with the original, and you should see all the latest changes. Otherwise, manually set the base fork drop down to your fork, and the head fork to the upstream. Click switching the base if you see that link.By default, GitHub will compare the original with your fork, and there shouldn't be anything to compare if you didn't make any changes. This still works as of September 2017, BUT it will lead to a dirty commit history. Starting in May 2014, it is possible to update a fork directly from GitHub. You only need to use the -f the first time after you've rebased. You'd do that with: git push -f origin master If you've rebased your branch onto upstream/master you may need to force the push in order to push it to your own forked repository on GitHub. However, for making further pull requests that are as clean as possible, it's probably better to rebase. If you don't want to rewrite the history of your master branch, (for example because other people may have cloned it) then you should replace the last command with git merge upstream/master. # aren't already in upstream/master are replayed on top of that # Rewrite your master branch so that any commits of yours that # Make sure that you're on your master branch: # Fetch all the branches of that remote into remote-tracking branches In terms of commands that might look like: # Add the remote, call it "upstream": ("Remotes" are like nicknames for the URLs of repositories - origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In your local clone of your forked repository, you can add the original GitHub repository as a "remote".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |