How to make changes to an environment installed from a repo?

Hi, I need to utilise code that I am allowed to install from a particular repo. What are the correct steps to install it, make the necessary changes + additions, and then push it to my own github account ?

If I’ve understood correctly, you’re asking about GitHub’s “Fork and Pull Request” model, which is the workflow adopted by GitHub to collaborate to repositories created by others.

You might find a good introductory article at this link:

The article will provide you with a bird-eye view of the whole process, for the practical details of all the operations involved you’ll find topic-dedicated tutorials on GitHub Help:

If you’re new to Git and GitHub, you might consider working with GitHub Desktop, the free and open source GUI Git client based on the GitHub Workflow:

This tool will simplify the most common Git operations involved in code collaboration; and thanks to the graphic interface, it might also help gain better insight into repositories’s structures.

1 Like

Thanks! So if I have forked and cloned it eg to say Pycharm, and I want to make additions on the original code as a project of my own, do I need to a)create another repo on Github to which I push my changes b)Am I supposed to be working on a ‘branch’ of the original?
To clarify, once I get the code on which to build from the original repo, I dont need to utilize/contribute anything to the original authors; its now a project of my own.
previously when I have forked projects, it assumes I want to contribute to the original and it gives me an error, so I want to do it correctly this time; Thank you :slight_smile:

We’ll yes, but you’ve already done that when you forked the repository. Your fork is a copy of the upstream (i.e. original) repository, and to make a contribution (a pull request) you need to first push the changes to your fork, then from GitHub’s home page of your fork you can create the pull request to the upstream project.

Yes, this is very important! You should not apply (i.e. commit) changes directly to the master branch of your fork — because your fork depends on the upstream repo, you need to keep your master branch in synch with the master branch of the upstream, otherwise the two codebases will diverge and you won’t be able to integrate further updates from the upstream repo into your fork.

Also, some repositories will only accept pull requests on specific branches (e.g. a devel branch, or some other name). Even in this case, you must keep that branch clean (i.e. use it only to pull changes from the upstream) and apply your changes to a branch created from the branch which you’ll be creating the pull request to (often master branch, but not always).

1 Like

This depends on the license terms really. Most open source licenses allow you to do this, as long as you honor the license terms. But some projects might demand that you contribute changes to the upstream.

Most likely, you cloned locally the upstream repository directly, so when you tried to push your changes you were presented with an “access denied” error, for you don’t have write permission on the original repository. Which is why you need to first fork the repository, so you have your own copy to which you (and only you, initially) have write access.

Understand that pull requests are natively part of Git, is an added layer by services like GitHub to allow easier cross-collaboration with people who don’t know each other. I.e. a way to allow contributions also from those who don’t have write access to the project.

1 Like

As a last note, beware that when you fork a repository to you only get the origin remote, which is a pointer back to your forked repository. But in order to integrate updates from the original project you’ll also need to manually add the upstream remote, pointing to the original repository — neither Git nor GitHub do this automatically for you, you’ll have to do it manually.

Basically, when you start working on your changes you are doing so from a branch which you created from a given snapshot of the repository. In the meantime (let’s say you work on your feature for 5 days) the upstream repository might have been updated, so your branch is behind that of the original repo.

You’ll need to set the upstream remote in order to pull updates from the upstream into your local clone (of your fork) and then push the updates to your fork on GitHub, as well as to rebase your contribution branch, so that your PR will not be out of synch with the destination branch when you create the PR.

It might sound all a bit complicated, but it’s actually simpler than it sounds, and it will all click-in once you actually make a PR or need to integrate updates from the upstream. Just keep in mind that Git is a distributed version control system, so you’re free to pull (i.e. get) updates from multiple versions of the same project (the original upstream repo, your fork, other forks, etc.). Branches are what allow you to keep different versions of the same code base (but with common ancestry) in a single repository.

1 Like

Thank you, your answers have been invaluable! I appreciate the help!