GitHub Community
How to update the old of the repository to the latest ？ #23908
-
|
I cloned a repository a year ago, when the repository was in tags: v2.5.0, now the repository is updated to v2.7.0. Prompt “This comparison is big!” does not provide a merge button.
1111Image 1111 hosted in ImgBB Do I need to create new tags and branches in my clone repository in advance, and then request a merge? But I found that it seems impossible to create a new branch in the repository I cloned. Does github have written documentation on such issues? |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments
-
|
wajika:
No, don’t! The point is that Git doesn’t pull tags by default, you need to explicitly tell Git that you want them: after that you should now be able to see tags in your local clone too. Also, if your local repository is a clone of a third party repository (i.e. not your fork of a this party repository) then you won’t need to merge anything, instead just pull to get the latest updates to your local copy
wajika:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply. Is your method to pull the latest code locally and upload it to the storage address I cloned? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe there’s a bit of confusion about the terms clone and fork here, which we might want to clear out. In Git terminology, a clone usually refers to a local copy of a repository, whereas a fork usually refers to a derived copy of an original repository, in this case the fork would be hosted on GitHub. So, let’s say there’s repository X (on GitHub), and you want to contribute to it. In the GitHub Workflow the customary way to do this if to fork X to your account, then you clone locally your fork of X, not the original X repository — i.e. when you execute In your local copy of the repository you’ll have two remotes:
You’ll be pulling from Bear in mind that Git is a distributed version control system, so the fact that we consider the repository X on GitHub the “original” repository is more of a convention than a technical constraint. For the same reason, you don’t need to delete your current local clone to connect it to your new fork of X, because a repository is just a repository, and you can simply add and delete remotes as you please. A remote is a “pointer” to a source of data for that repository. Since you originally cloned X, making it now point also to your new fork won’t compromise its data, you’ll only have to hook it to point to the new remote and keep doing your usual Git operations. Even if you destroy a remote, the repository integrity is still there, and when you add a new remote Git has its own ways to check that the local repository and that present at the remote are indeed the same repositories. As for pull requests, indeed the GitHub Workflow requires you to apply your changes to a custom branch that is pushed on your fork, and then you open a PR on the target repository (i.e. the original X, or upstream). That is, unless you are a collaborator of the X repository, in which case you can push your changes directly on the original repository, and create a request therein, or even skip the pull request part and directly merge your changes into the You might want to learn more about the GitHub Workflow, which is the way collaboration works here on GitHub (and similarly in other Git hosting services too): https://guides.github.com/introduction/flow/ I hope this helped. |
Beta Was this translation helpful? Give feedback.
-
|
wajika:
I’m not sure about this, I always do all the work directly via Git. Maybe someone else can answer this better. What I know for sure is that you can edit the contents of your fork via the WebUI, but have no idea whether synchronizing repositories can be done via the WebUI. |
Beta Was this translation helpful? Give feedback.
-
|
Your answer is very detailed, thank you very much. |
Beta Was this translation helpful? Give feedback.
-
|
In the past, I always used github page ui to complete synchronization operations, but that was when there were few tags and branches in the original repository update. If everything can be done on the github page ui, I think it will be much simpler. |
Beta Was this translation helpful? Give feedback.
-
|
wajika:
I used to rely on WebUI quite a lot, especially when I had just joined GitHub and wasn’t very fond of Git yet. But now I prefer to do as much as possible via Git, locally. I mostly work with Sublime Merge, a commercial Git GUI frontend that integrates well with Sublime Text, my editor of choice right now (again, commercial and by the same company). The reason is that I just like to stick to my own tried and tested working method, using tools that I’m confident with. Also, Git GUIs really simplify life because they always provide a nice view of the repository graph, which allows me to see at all times branches status, both locally and remotely. It has nothing to do with being a “better” way, it’s just more convenient for myself and it works out well for me. I believe that the free and open source VSCode editor also offers great Git integration, out of the box, with many GitHub specific third party packages available to enhance the user experience, including being able to reply to Issues directly from the editor, and work with GH pull requests in a neat manner. I haven’t yet had the time to play around with it, but I believe that VSCode is a great choice when it comes to editors for working on GitHub hosted projects. So I’m planning to migrate from Sublime Text and Sublime Merge to VSCode, but it’s going to take some time because changing tools is not an easy task, especially if you need to keep fast production times (i.e. I’d have to readjust all my working habits, learn new tools, re-create custom extensions, etc., which is no light task when you’ve been working for so many years with some tools). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing your thoughts. |
Beta Was this translation helpful? Give feedback.
Maybe there’s a bit of confusion about the terms clone and fork here, which we might want to clear out. In Git terminology, a clone usually refers to a local copy of a repository, whereas a fork usually refers to a derived copy of an original repository, in this case the fork would be hosted on GitHub.
So, let’s say there’s repository X (on GitHub), and you want to contribute to it. In the GitHub Workflow the customary way to do this if to fork X to your account, then you clone locally your fork of X, not the original X repository — i.e. when you execute
git cloneyou provide the URL of your fork (e.g.wajika/x). The reason for this is that (unless you are invited as a collaborator to the…