Right now, my fork of dev.to displays this message:
How do I update my fork so that it's the same as thepracticaldev:master?
cd
into the directory of the cloned repo
Running git remote -v
will display the current remotes
Add the parent repository as a new remote, specifying it as the upstream repository. In this example, we will run
git remote add upstream https://github.com/thepracticaldev/dev.to.git
Verify with git remote -v
Fetch the upstream repository with git fetch upstream
The commits that are different from my fork are now in separate branches in my local environment. Let's merge those. git merge upstream/master
Now my cloned repo looks just like the upstream repository.
NOTE: any changes made locally before the merge are preserved, so you don't have to worry about losing any of your work when you do this.
From now on, whenever I need to sync with the upstream repository, all I need to do is fetch and merge.
At this point, running git push
will update the forked repo and display this message:
Top comments (13)
Wow, after getting some links here, I was sure as hell expecting to have an automated solution, like a scheduled task to automate this, or a link to a github article on how to set up fork syncing.
... Disappointed.
What's a much better thing to do is directly track
upstream
instead oforigin
.Then just ignore your master branch fetched from origin. If you want to know how to set this up from the CLI:
You can even overwrite the origin
master
ref locally, so that it is always the same as the source:You'll need to match sure that you always
git fetch --all
, but that can be easily solved with a git alias.Also if you are using Gitlab, there is already a feature to automatically support this (from three years ago: about.gitlab.com/blog/2016/12/01/h...)
wow :O I have to try this, not grasped it ...
master branch fetched from origin
, why I'd fetch from origin?By default your local branch
master
is set to track changes fromorigin
. However what you really want ismaster
tracking changes fromupstream
. So I'm just suggesting to ignoreorigin/master
as a mindset shift, and then everything works out as you would expect. Sure your remoteorigin/master
is wrong, but who cares.Thank you for sharing that! I hadn’t seen that before, and it’s always nice to learn new techniques. I can definitely see the benefit of an automated solution as well. Food for thought 🤔
Another option is to create a script (for example:
scripts/pull-changes-from-upstream.sh
) to the repository for helping new contributors. Then people already have a helper available to keep them on track more easily. Better to have good defaults (whatever those are), and automate basics so people don't have to quess what is the development workflow of a project.How can I use git desktop bro
Hey! I’d love to help if I can, but I’m not sure what you’re asking. Are you asking how to use git in your local environment, or how to use GitHub Desktop?
Github desktop man am owky with git but for the desktop just freeks me out
I'm not familiar with GitHub Desktop since (as far as I know) it's not available for Linux, but I did see this post that might point you in the right direction:
The beginner's guide to contributing to projects with GitHub Desktop
Thea ・ Oct 13 '18 ・ 3 min read
It looks like a really good one. I hope it helps!
Hey, great article :)
I am curious: you have different commits in your master compared to upstream because not using branches for your changes or something else?
Are you referencing this line?
I don’t think I had any commits in master when I put this together, but you bring up a good point. I think it would have been clearer if I had mentioned to checkout master before merging. I was just trying to say that any local changes anyone might have won’t be overwritten in the merge, but now that I think about it more, perhaps it wasn’t totally necessary for me to make that point.
Great article
Thanks!