You obviously can’t work directly on the main project files, so you first need to take a copy of them to your own GitHub account. Note that each of the steps will get their own articles in the future as parts of this series. Boxes are shown in blue when they are synchronised with the current official repo red means they have got out of sync green is used when the upstream repo has been changed. The diagram above will be used throughout this tutorial to illustrate the various exchanges. It is important to understand the interaction between the three players at all stages in this process. The objective of this tutorial is to show you how, using the GitHub Desktop, to contribute to an open source project by working on files from some remote repository and then submit them (make a pull request) so they can be merged into the “official” project. Local – the files on your local machine where you will be making your changes.Origin – your fork of the project files that live in your GitHub account, and.Upstream – the “official” project files that live on the main repo in GitHub,.The repo also stores each file’s revision history. Files get stored in a repository (repo for short) which is like a separate locker for each project. You could think of it as the umpire in a sort of complicated game of tennis involving three players, except they will be bouncing around files instead of tennis balls. GitHub Desktop is a graphical tool that helps you to use GitHub without having to deal with the command line (which, let’s face it, does tend to discourage a lot of people). This is the introductory part of a series of tutorials on GitHub Desktop. Select bugfix-2.1.An introductory guide to the GitHub Desktop We recommend you change the “Default Branch” in your fork to bugfix-2.1.x to make it easier to do Pull Requests later.Ĭlick on the branches tab to view all branches in your fork.Ĭlick on the Change default branch button.Ĭlick on the branch dropdown button. This takes you back to your fork’s main page, where the new name is displayed.Īt this time we’re using the bugfix-2.1.x branch to patch bugs for the next minor release, and we’ll create a new branch for the next major release as we develop a plan. Here are the instructions if you want to rename it.Ĭlick in the Repository name box, type the new name, and click Rename. It’s always best to leave the repository name as “Marlin” unless you plan to make your own custom version of Marlin for publication. If it still hasn’t finished after few minutes then GitHub might be hung up (not unusual). You may need to wait for the Fetching Latest Commit message to go away also. This takes about 10-20 seconds, so be patient. When GitHub is done copying files, a page will appear displaying your shiny new fork of Marlin. Please upload a unique icon or image so it will be easier to identify you on the project pages! You’ll also need to download and install the GitHub Desktop application.Īfter signing in to your GitHub account, go to the main Marlin repository at: and create a fork of Marlin by clicking the fork icon in the top right of the page. Set up GitHub, Fork, and Cloneīefore you can contribute to Marlin, you need to get a free account. Following our guidelines ensures that your changes will be accepted more quickly. GitHub adds helpful collaboration features that make it an ideal platform for maintaining the Marlin project.īefore submitting code and other content, please review Contributing to Marlin and Marlin Coding Standards. Git will be familiar if you’ve used other version control systems like CVS, Apache Subversion, or Mercurial. The power of GitHub comes from the Git version control system. GitHub is a great tool for collaboration, but it has a bit of a learning curve. Contributing Code with Pull Requests Introduction
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |