![]() ![]() Note: Contributing to open-source projects does not necessarily mean that you have to know how to code. I contributed to an open-source project for the first time using GitHub Desktop, and I'm going to walk you through step by step how to do the same. There are also various ways you can contribute to open-source projects although most developers prefer to contribute to GitHub projects using the commands in the terminal, which we'll discuss in part 2 of this article. In this article, we're going to talk about contributing to GitHub projects using GitHub Desktop. This way the forks and PR's of the forks need to be up to date before they can be merged into 'master' - this sounds like a much more saner option to enable rather than the coding change made in the desktop client which now breaks the creation of branches on forks.If you are wondering about how to contribute to open source as a beginner, don’t worry. I do get why you are wanting to do this, however if you are trying to 'fix' stale forks from developing on their own before merging into 'master' - then why not configure the following: So v2.4.0 of the GitHub Desktop client breaks the workflow of creating branches on forks. I downgraded to 2.3.1 which is the last version on the workstation, and when creating a branch - this works as expected: Now what seems to happen is - the 'branch' is looking at all changes from the 'skilion' as the base - which is 100% wrong - it should be checking this against my fork, as this is where I have created the branch from.īased on the user documentation as well in the Desktop client - the default 'master' branch is my folk - my 'master'. This would just bring in changes as needed. ![]() So - my work flow is this, in the previous version of client, I would just create a new branch against by folk, add in the code changes, then create a PR against my fork. So essentially, my 'fork' is the 'master', even though it is a 'fork' and not the original repository. I forked the original repo ( ) to fix the bugs, and maintain the client which I have been doing for the last 2+ years. As a result there is no way to transfer ownership to me or even merge any PR or code to it. Thanks so much, and again I apologize that this is causing problems for - the original 'repo' - is unmaintained, unmanaged and the user is 100% non contactable. It'd be helpful for us to understand how you're using your fork and how it differs from our assumptions and what we've seen elsewhere. Would you mind describing your workflow to help us understand your use case better? We've heard from others that in most cases for forks that are maintained independently of the upstream repo, they usually break off entirely as their own repo instead of remaining a fork because the fork relationship no longer adds any value and GitHub generally assumes that forks are used for contributing back to the parent. So the previous behavior often would mean people working from forks in Desktop were starting new branches way out of date from the latest commits, and this was intended to help people ensure they're up to date when starting on a new branch. This was an intentional change in #7762 based on the vast majority of forks being used to contribute to the upstream branch. Hi thanks for the issue and really sorry the update caused problems with your workflow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |