How to update the old of the repository to the latest ?

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.
Now I want to get all the updated parts.

Prompt “This comparison is big!” does not provide a merge button.

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.
I don’t know anything about it.

Does github have written documentation on such issues?

No, don’t! The point is that Git doesn’t pull tags by default, you need to explicitly tell Git that you want them:

git fetch --tags

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

git pull

https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/keeping-your-local-repository-in-sync-with-github/syncing-your-branch#pulling-to-your-local-branch-from-the-remote

Thank you for your reply. Is your method to pull the latest code locally and upload it to the storage address I cloned?
Is there a way to update my cloned repository on github web ui?

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 clone you 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 X repository) you won’t have write access to the repository, so you need to create your own copy (your fork) under your account, which of course gives you write access privileges to it.

In your local copy of the repository you’ll have two remotes:

  1. origin — pointing to your fork of X, under your account.
  2. upstream — pointing to the original X repository on GitHub.

You’ll be pulling from upstream in order to integrate updates and changes from the original repository into your local clone, and then push them to origin to keep your fork updated on GitHub.

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 main branch (if this is how you agreed to work with the owner of the repository).

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.

1 Like

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.

Your answer is very detailed, thank you very much.

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.

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).

1 Like

Thanks for sharing your thoughts.