One place for hosting & domains

      Hacktoberfest: How to Submit Your First Pull Request on Github


      Introduction

      Hacktoberfest is a month-long celebration of open source software, run by DigitalOcean and open to everyone in our global community. To participate, you’ll need to submit four quality pull requests to public GitHub repositories in the month of October. Upon completing the challenge, you’ll earn special prizes, including an exclusive Hacktoberfest t-shirt.

      You can sign up anytime between October 1 and October 31, and we encourage you to connect with other developers and Hacktoberfest enthusiasts for virtual events and information sessions, starting in September.

      In this tutorial we’ll introduce you to Git, the version control system that you’ll use to submit your pull request, and Github, the repository hosting service that we’ll be using to track your progress. By the end of this tutorial, you’ll be ready to submit your first pull request and will be well on your way to participating in Hacktoberfest!

      Version Control

      Before we begin with Git and Github, let’s talk about version control. When developers work on a project together, oftentimes they’ll need to work on the same code base. While they’re working, each developer needs to know about what changes the other developer made, so as not to duplicate work or write code over what has already been done.

      A version control system serves as a saving program for code, where it assigns a version to a project and tracks changes made over time to each file in the project. In this way, developers can work together on a project by checking in with the latest version, to see the changes made before working on their portion of the project’s code.

      Git and Github

      Git, a version control system used to manage developer projects of all sizes, was created in 2005 by Linus Torvalds, the creator of Linux, to help developers contribute code and share code revisions in a way that was fast, efficient, and inexpensive. Git enables developers to edit, share, and publish code, facilitating collaboration and teamwork.

      Github is a cloud-based git repository hosting service that allows developers to take code that they’ve written on their local machines and share it with the world. It provides a way to share the version-tracked projects on your local computer publicly through repositories, or central file storage locations, and depending on the project’s availability (it can be either a public or private repository), other developers can download the project to edit the code, provide insight, and more.

      To get started with Github, you can create an account at Github. For more details on how to do that, please refer to the Hacktoberfest resources page.

      Cloning a Repository

      We’ll now clone and edit our first Github repository. First, let’s navigate to the repository that we’d like to clone. For the sake of this tutorial, we’ll use the Cloud Haiku repository.
      Before you clone this repository, that is, take a copy of the code on Github onto your local machine, you’ll need to take a copy of the whole repository into your own Github account. This is called a fork of the repository, and it allows you to develop your code without affecting the main code base.

      To fork a repository, click the Fork button at the top right in the repository. To clone, click the code button, take a copy of the link provided, then watch as Github takes this repository and adds it as a copy to your account. Your name should now appear as the creator of this repository, which is a ‘fork’ of the main haiku repository.

      Clone the repository

      Next, navigate to your command line interface to clone the project on your local machine.You can do that with the git clone command, which will clone, or copy, the fork that I just created from the haiku repository down to my local machine. This will enable you to make changes to the codebase locally (on your own machine).

      • cd ~
      • git clone https://github.com/sammy/cloud_haiku

      Editing Code Content

      You now have a copy of the Cloud Haiku repository on your local machine, so you’re ready to prepare your contribution. Using the command line interface, navigate to the folder of your cloned repository. If you followed along, you should have a cloud_haiku folder inside your home directory:

      There’s a number of text editors and Integrated Development Environments (IDEs) that you can use to edit your code. IDEs are typically segmented by programming language and include a series of helpful features to streamline the process of developing an application in that language. If you don’t have an IDE currently set up within your work machine, consider checking out Hacktoberfest’s resources page for advice on how to choose an IDE.

      It’s important to take the time to read and understand how the project is organized and the contribution guidelines, and find parts of the code that you can work on. Read any associated documentation provided before making changes. Next, let’s submit a haiku!

      Browse the Codebase

      Adding Content to the Remote Repository

      Now that we have a change made to the haiku repository, we’ll need to track and save that change. The first step in tracking your change is to add it to the version you’re working on. To do that, we’ll execute the command git add . :

      Writing the command in this way allows you to add all changes made to the repository, across files. If you need to only submit changes to an individual file, use git add filename:

      After running the add command, you’ll get no confirmation. To see if your changes have been included in the list of files that is ready to be committed, you can execute the command git status:

      This allows you to check on the status of your tracked changes — you’ll see that your file has been added, but not committed as a change. Git provides this step in the event that you need to amend a change before officially tracking it as new or edited code.

      Git Add

      Next, let’s commit our change. Execute the command git commit, and add a message so that other developers who are collaborating on this project will know about the changes you’ve made:

      • git commit -m "added sammy haiku"

      Writing your commit with a message allows developers to be informed of changes that are made — this message is tracked along with a commit ID and your username.

      Git Commit

      After committing, we’ll need to push changes from our local machine to the remote repository on Github. To do this, let’s execute the command git push:

      Here, we can designate an origin for the push — in this instance, we want our contributions to go to our forked version of DigitalOcean’s haiku repository.

      Git Push

      To recap, so far we’ve identified a repository that we’d like to edit, and took a copy of the repository into our Github account and local machine using fork and clone. We made a change, and submitted our change with git add. We then solidified our change by running git commit, which committed the change. git push pushed our change from our local machines to the remote repository on Github. If we look on Github, we’ll see that the change we made is reflected in the files in our copy of the haiku repository.

      Creating a Pull Request

      We’re now ready to let the maintainers of the project know that we have a change to the repository that we’re confident about and ready to submit. To do this, we’ll click the pull request button to the right.

      Submit a PR

      After the pull request button is clicked, a new page will open with a form that explains what change we made, and shows if the changes made will in any way conflict with the existing content. We’ll add in an appropriate title that details the change, and in the description add an explanation of what changes were made and why. What you add here can vary depending on the project – take a look at the project’s collaboration guidelines to make sure your pull request is formatted correctly.

      After adding in a title and description of the changes made, we’ll scan the pull request page to make sure that our committed change does not conflict with existing changes made to the code repository. If everything checks out, we’ll get a green submit pull request button at the bottom that escalates our request to make a change to the original haiku poem codebase, a contribution that will be live for anyone viewing that main branch. Be patient — it may take maintainers some time to review your request. Amendments and comments can be added on the pull request page, and new commits made to the same affected files will appear in the request’s history.

      Congratulations- we’ve successfully submitted our first pull request!

      In this tutorial, you learned about Git and Github, and successfully identified and submitted a change to a public repository. For Hacktoberfest, you’ll need to submit 4 meaningful pull requests, so again, find the project that resonates with you and have fun hacking!

      To see this tutorial in action, here’s a helpful video that walks you through the process of submitting your first pull request:

      Video: How to Submit Your First PR

      For more information about Hacktoberfest, visit our main page.
      To learn more about Git, visit How to Use Git: A Reference Guide.
      For additional information about Github, visit Github.



      Source link

      Hacktoberfest Workshop Kit: How to Submit Your First Pull Request on Github


      How To Submit Your First Pull Request on GitHub Workshop Kit Materials

      This workshop kit is designed to help an instructor guide an audience without a background in version control or contributing to open source projects through the steps of submitting a pull request from start to finish in roughly thirty minutes. Attendees will finish the workshop with an understanding of version control, open source, Git, and GitHub.

      No prior coding experience is assumed on the part of the audience. Instructors without experience in open source, Git, or GitHub should be able to teach the course after reviewing the material first.

      The aim of this workshop kit is to provide a complete set of resources for a speaker to host a workshop about version control and contributing to open source projects. It includes:

      • Slides and speaker notes that lead participants through setting up their website project, hands-on exercises, and conceptual explanations.
      • A video with a live coding walkthrough of submitting a pull request, tips, and conceptual information about version control and contributing to open source projects.
      • A demonstration repo to allow participants to contribute to an open source project as they follow along in the workshop.

      This workshop kit page is intended to help instructors prepare for the workshop and provide a starting point for learners. Instructors should point learners to this page so they can have access to the slides (which contain useful links).

      If desired, learners can prepare for the workshop by reading the introduction below and making sure that they have the prerequisites ready before the workshop starts.

      If you are interested in participating in this year’s Hacktoberfest, this workshop is a great place to start! This project-based workshop will introduce you to open source, version control, Git, and GitHub using the Cloud Haiku repository as a model. Once you learn the fundamentals, you will know how to contribute to open source projects and submit a pull request on GitHub. No prior coding experience is necessary to follow along in the workshop.

      When software developers work on a project together, oftentimes they’ll need to work on the same code base. While they’re working, each developer needs to know about what changes the others made to the code, so as not to duplicate work or write code over what has already been done. Git, a version control system used to manage developer projects of all sizes, was created in 2005 by Linus Torvalds, the creator of Linux, to help developers contribute to code and share code revisions in a way that was fast, efficient, and inexpensive. Git creates code repositories to help developers edit, share, and publish code for all. GitHub is a cloud-based Git repository hosting service that allows developers to take code that they’ve written on their local machines and share it with the world.

      With Git and GitHub, developers from all over the world collaborate on all sorts of projects — many of the websites you visit regularly are maintained using GitHub. Knowing how to use Git and GitHub, and learning how to contribute to open source projects will provide new developers with a strong start in gaining the skills they need to join the software engineering community at large.

      In this workshop, we’ll introduce you to Git and GitHub, the version control system that Hacktoberfest uses to track your progress, and the repository hosting service that shares projects to collaborate on. By the end of this tutorial, you’ll be ready to submit your first pull request and will be well on your way to participating in Hacktoberfest!

      To participate as a workshop leader or learner, you will need the following:

      • A code editor. In this workshop, we’ll be using Visual Studio Code, which you can download for free for Mac, Windows, or Linux.
      • A web browser. In this workshop, we’ll be using Google Chrome as our default browser, which you can also download for free for Mac, Windows, or Linux.
      • A GitHub account. In this workshop, we’ll make a contribution to an open source repo on GitHub. You can sign up for a free account using your default browser.

      Once you have your prerequisites ready, you will be ready to begin the workshop. Refer to the speaker slides for helpful links after the workshop or watch the How to Submit Your First Pull Request video on the Hacktoberfest resources page to review.



      Source link

      Como Criar um Pull Request no GitHub


      Introdução

      Livre e open-source, o Git é um sistema de controle de versão distribuído que torna os projetos de software colaborativo mais gerenciáveis. Muitos projetos mantém seus arquivos em um repositório Git, e sites como o Github tornaram o compartilhamento e a contribuição para o código simples e efetiva.

      Projetos open-source que são hospedados em repositórios públicos beneficiam-se de contribuições feitas pela ampla comunidade de desenvolvedores através de pull requests, que solicitam que um projeto aceite as alterações feitas em seu repositório de código.

      Este tutorial vai guiá-lo no processo de realizar um pull request para um repositório Git através da linha de comando para que você possa contibuir com projetos de software open-source.

      Pré-requisitos

      Você deve ter o Git instalado em sua máquina local. Você pode verificar se o Git está instalado em seu computador e passar pelo processo de instalação para o seu sistema operacional, seguindo este guia.

      Você também precisará ter ou criar uma conta no GitHub. Você pode fazer isso através do website do GitHub, github.com, e pode ou efetuar login ou criar sua conta.

      Finalmente, você deve identificar um projeto de software open-source para contribuir. Você pode se familiarizar mais com os projetos open-source lendo essa introdução.

      Crie uma Cópia do Repositório

      Um repositório, ou repo para abreviar, é essencialmente a pasta principal do projeto. O repositório contém todos os arquivos relevantes do projeto, incluindo documentação, e também armazena o histórico de revisão para cada arquivo. No GitHub, os repositórios podem ter vários colaboradores e podem ser públicos ou privados.

      Para trabalhar em um projeto open-source, primeiro você precisará criar sua própria cópia do repositório. Para fazer isso, você deve fazer um fork do repositório e então fazer a clonagem dele para que você tenha uma cópia de trabalho local.

      Faça o Fork do Repositório

      Você pode fazer um fork de um repositório navegando até a URL GitHub do projeto open-source que você gostaria de contribuir.

      As URLs de repositórios GitHub irão referenciar o nome do usuário associado com o proprietário do repositório, bem como o nome do repositório. Por exemplo, DigitalOcean Community é o proprietário do repositório do projeto cloud_haiku, assim a URL GitHub para esse projeto é:

      https://github.com/do-community/cloud_haiku
      

      No exemplo acima, do-community é o nome do usuário e cloud_haiku é o nome do repositório.

      Um vez que você identificou o projeto que você gostaria de contribuir, você pode navegar até a URL, que estará formatada da seguinte forma:

      https://github.com/nome-do-usuário/repositório
      

      Ou você pode procurar o projeto usando a barra de pesquisa do GitHub.

      Quando você estiver na página principal do repositório, você verá um botão “Fork” no seu lado superior direito da página, abaixo do seu ícone de usuário:

      Clique no botão fork para iniciar o processo de fork. Dentro da janela do seu navegador, você receberá um feedback assim:

      Quando o processo estiver concluído, o seu navegador irá para uma tela semelhante à imagem do repositório acima, exceto que no topo você verá seu nome de usuário antes do nome do repositório, e na URL ela também mostrará seu nome de usuário antes do nome do repositório.

      Então, no exemplo acima, em vez de do-community / cloud_haiku na parte superior da página, você verá seu-nome-de-usuário / cloud_haiku, e a nova URL será parecida com isto:

      https://github.com/seu-nome-de-usuário/cloud_haiku
      

      Com o fork do repositório realizado, você está pronto para cloná-lo para que você tenha uma cópia de trabalho local da base de código.

      Clone o Repositório

      Para criar sua própria cópia local do repositório com o qual você gostaria de contribuir, primeiro vamos abrir uma janela de terminal.

      Vamos utilizar o comando git clone juntamente com a URL que aponta para o seu fork do repositório.

      Esta URL será semelhante à URL acima, exceto que agora ela irá terminar com .git. No exemplo do cloud_haiku acima, a URL ficará assim:

      https://github.com/seu-nome-de-usuário/cloud_haiku.git
      

      Você pode, alternativamente, copiar a URL usando o botão verde “Clone or download” da página do seu repositório que você acabou de fazer fork. Depois de clicar no botão, você poderá copiar a URL clicando no botão do fichário ao lado da URL:

      Uma vez que tenhamos a URL, estamos prontos para clonar o repositório. Para fazer isto, vamos combinar o comando git clone com a URL do repositório a partir da linha de comando em uma janela de terminal:

      • git clone https://github.com/seu-nome-de-usuário/repositório.git

      Agora que você tem uma cópia local do código, podemos passar para a criação de uma nova branch ou ramificação na qual iremos trabalhar com o código.

      Crie uma Nova Branch

      Sempre que você trabalha em um projeto colaborativo, você e outros programadores que contribuem para o repositório terão ideias diferentes para novos recursos ou correções de uma só vez. Alguns desses novos recursos não levarão tempo significativo para serem implementados, mas alguns deles estarão em andamento. Por isso, é importante ramificar o repositório para que você possa gerenciar o fluxo de trabalho, isolar seu código e controlar quais recursos serão retornados à branch principal do repositório do projeto.

      A branch principal padrão de um repositório de projeto é geralmente chamada de master branch. Uma prática comum recomendada é considerar qualquer coisa na branch master como sendo passível de se fazer o deploy para outras pessoas usarem a qualquer momento.

      Ao criar uma nova branch, é muito importante que você a crie fora da branch master. Você também deve se certificar de que o nome da sua branch é descritivo. Em vez de chamá-la de minha-branch, você deve usar frontend-hook-migration ou Corrigir erros de digitação na documentação.

      Para criar nossa branch, na nossa janela de terminal, vamos mudar nosso diretório para que estejamos trabalhando no diretório do repositório. Certifique-se de usar o nome real do repositório (como cloud_haiku) para mudar para esse diretório.

      Agora, vamos criar nossa nova branch com o comando git branch. Certifique-se de nomeá-la de maneira descritiva para que outras pessoas trabalhando no projeto entendam no que você está trabalhando.

      Agora que nossa nova branch está criada, podemos mudar para nos certificar de que estamos trabalhando nessa branch usando o comando git checkout:

      Depois de inserir o comando git checkout, você receberá a seguinte saída:

      Output

      Switched to branch nova-branch

      Alternativamente, você pode condensar os dois comandos acima, criando e mudando para a nova branch, com o seguinte comando e com a flag -b:

      • git checkout -b nova-branch

      Se você quiser mudar de volta para o master, você irá usar o comando checkout com o nome da branch master:

      O comando checkout vai lhe permitir alternar entre várias branches, para que você possa trabalhar em vários recursos de uma só vez.

      Neste ponto, agora você pode modificar arquivos existentes ou adicionar novos arquivos ao projeto em sua própria branch.

      Faça Alterações Localmente

      Depois de modificar os arquivos existentes ou adicionar novos arquivos ao projeto, você pode adicioná-los ao seu repositório local, o que podemos fazer com o comando git add. Vamos adicionar a flag -A para adicionar todas as alterações que fizemos:

      Em seguida, queremos registrar as alterações que fizemos no repositório com o comando git commit.

      A mensagem de commit é um aspecto importante da sua contribuição de código; ela ajuda os outros contribuidores a entenderem completamente a mudança que você fez, por que você fez e o quanto é importante. Adicionalmente, as mensagens de commit fornecem um registro histórico das mudanças para o projeto em geral, ajudando os futuros contribuidores ao longo do caminho.

      Se tivermos uma mensagem muito curta, podemos gravar isso com a flag -m e a mensagem entre aspas:

      • git commit -m "Corrigidos erros de digitação na documentação"

      Mas, a menos que seja uma mudança muito pequena, é bem provável que incluiremos uma mensagem de confirmação mais longa para que nossos colaboradores estejam totalmente atualizados com nossa contribuição. Para gravar esta mensagem maior, vamos executar o comando git commit que abrirá o editor de texto padrão:

      Se você gostaria de configurar seu editor de texto padrão, você pode fazê-lo com o comando git config e definir o nano como editor padrão, por exemplo:

      git config --global core.editor "nano"
      

      Ou o vim:

      • git config --global core.editor "vim"

      Depois de executar o comando git commit, dependendo do editor de texto padrão que você está usando, sua janela de terminal deve exibir um documento pronto para edição que será semelhante a este:

      GNU nano 2.0.6 File: …username/repository/.git/COMMIT_EDITMSG

      
      # Please enter the commit message for your changes. Lines starting
      # with '#' will be ignored, and an empty message aborts the commit.
      # On branch nova-branch
      # Your branch is up-to-date with 'origin/new-branch'.
      #
      # Changes to be committed:
      #       modified:   novo-recurso.py
      #
      

      Abaixo dos comentários introdutórios, você deve adicionar a mensagem de commit ao arquivo de texto.

      Para escrever uma mensagem útil no commit, você deve incluir um sumário na primeira linha com cerca de 50 caracteres. Abaixo disso, e dividido em seções de fácil entendimento, você deve incluir uma descrição que indique o motivo pelo qual você fez essa alteração, como o código funciona, e informações adicionais que irão contextualizar e esclarecer o código para que outras pessoas revisem o trabalho ao mesclá-lo. Tente ser o mais útil e proativo possível para garantir que os responsáveis pela manutenção do projeto possam entender totalmente sua contribuição.

      Depois de salvar e sair do arquivo de texto da mensagem de commit, você poderá verificar o commit que o git estará fazendo com o seguinte comando:

      Dependendo das alterações que você fez, você receberá uma saída parecida com esta:

      Output

      On branch nova-branch Your branch is ahead of 'origin/nova-branch' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working directory clean

      Nesse ponto você pode usar o comando git push para fazer o push das alterações para a branch atual do repositório que você fez o fork:

      • git push --set-upstream origin nova-branch

      O comando irá lhe fornecer uma saída para que você saiba do progresso e será semelhante ao seguinte:

      Output

      Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/seu-nome-de-usuário /repositório .git a1f29a6..79c0e80 nova-branch -> <^>nova-branch< Branch nova-branch set up to track remote branch nova-branch from origin.

      Agora você pode navegar até o repositório que você fez o fork na sua página web do GitHub e alternar para a branch que você acabou de fazer push para ver as alterações que você fez diretamente no navegador.

      Nesse ponto, é possível fazer um pull request para o repositório original, mas se ainda não o fez, certifique-se de que seu repositório local esteja atualizado com o repositório upstream.

      Atualize o Repositório Local

      Enquanto você estiver trabalhando em um projeto ao lado de outros colaboradores, é importante que você mantenha seu repositório local atualizado com o projeto, pois você não deseja fazer um pull request de um código que cause conflitos. Para manter sua cópia local da base de código atualizada, você precisará sincronizar as alterações.

      Primeiro vamos passar pela configuração de um repositório remoto para o fork, e então, sincronizar o fork.

      Configure um Repositório Remoto para o Fork

      Repositórios remotos permitem que você colabore com outras pessoas em um projeto Git. Cada repositório remoto é uma versão do projeto que está hospedada na Internet ou em uma rede à qual você tem acesso. Cada repositório remoto deve ser acessível a você como somente leitura ou como leitura-gravação, dependendo dos seus privilégios de usuário.

      Para poder sincronizar as alterações feitas em um fork com o repositório original com o qual você está trabalhando, você precisa configurar um repositório remoto que faça referência ao repositório upstream. Você deve configurar o repositório remoto para o repositório upstream apenas uma vez.

      Primeiro, vamos verificar quais servidores remotos você configurou. O comando git remote listará qualquer repositório remoto que você já tenha especificado, então se você clonou seu repositório como fizemos acima, você verá pelo menos o repositório origin, que é o nome padrão fornecido pelo Git para o diretório clonado.

      A partir do diretório do repositório em nossa janela de terminal, vamos usar o comando git remote juntamente com a flag -v para exibir as URLs que o Git armazenou junto com os nomes curtos dos repositórios remotos relevantes (como em "origin"):

      Como clonamos um repositório, nossa saída deve ser semelhante a isso:

      Output

      origin https://github.com/seu-nome-de-usuário/repositório-forked.git (fetch) origin https://github.com/seu-nome-de-usuário/repositório-forked.git (push)

      Se você configurou anteriormente mais de um repositório remoto, o comando git remote -v fornecerá uma lista de todos eles.

      Em seguida, vamos especificar um novo repositório remoto upstream para sincronizarmos com o fork. Este será o repositório original do qual fizemos o fork. Faremos isso com o comando git remote add.

      • git remote add upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git

      Nesse exemplo, upstream é o nome abreviado que fornecemos para o repositório remoto, já que em termos do Git, “Upstream” refere-se ao repositório do qual nós clonamos. Se quisermos adicionar um ponteiro remoto ao repositório de um colaborador, podemos fornecer o nome de usuário desse colaborador ou um apelido abreviado para o nome abreviado.

      Podemos verificar que nosso ponteiro remoto para o repositório upstream foi adicionado corretamente usando o comando git remote -v novamente a partir do diretório do repositório:

      Output

      origin https://github.com/seu-nome-de-usuário/repositório-forked.git (fetch) origin https://github.com/seu-nome-de-usuário/repositório-forked.git (push) upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git (fetch) upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git (push)

      Agora você pode se referir ao upstream na linha de comando em vez de escrever a URL inteira, e você está pronto para sincronizar seu fork com o repositório original.

      Sincronizando o Fork

      Depois de configurarmos um repositório remoto que faça referência ao upstream e ao repositório original no GitHub, estamos prontos para sincronizar nosso fork do repositório para mantê-lo atualizado.

      Para sincronizar nosso fork, a partir do diretório do nosso repositório local em uma janela de terminal, vamos utilizar o comando git fetch para buscar as branches juntamente com seus respectivos commits do repositório upstream. Como usamos o nome abreviado "upstream" para nos referirmos ao repositório upstream, passaremos o mesmo para o comando:

      Dependendo de quantas alterações foram feitas desde que fizemos o fork do repositório, sua saída pode ser diferente, e pode incluir algumas linhas de contagem, compactação e descompactação de objetos. Sua saída terminará de forma semelhante às seguintes linhas, mas pode variar dependendo de quantas branches fazem parte do projeto:

      Output

      From https://github.com/nome-de-usuário-do-proprietário-original/repositório-original * [new branch] master -> upstream/master

      Agora, os commits para o branch master serão armazenados em uma branch local chamada upstream/master.

      Vamos mudar para a branch master local do nosso repositório:

      Output

      Switched to branch 'master'

      Agora mesclaremos todas as alterações feitas na branch master do repositório original, que vamos acessar através de nossa branch upstream/master local, com a nossa branch master local:

      • git merge upstream/master

      A saída aqui vai variar, mas começará com Updating se tiverem sido feitas alterações, ou Already up-to-date, se nenhuma alteração foi feita desde que você fez o fork do repositório.

      A branch master do seu fork agora está em sincronia com o repositório upstream, e as alterações locais que você fez não foram perdidas.

      Dependendo do seu fluxo de trabalho e da quantidade de tempo que você gasta para fazer alterações, você pode sincronizar seu fork com o código upstream do repositório original quantas vezes isso fizer sentido para você. No entanto, você certamente deve sincronizar seu fork antes de fazer um pull request para garantir que não contribuirá com código conflitante.

      Crie um Pull Request

      Neste ponto, você está pronto para fazer um pull request para o repositório original.

      Você deve navegar até o seu repositório onde você fez o fork e pressionar o botão "New pull request" no lado esquerdo da página.

      Você pode modificar a branch na próxima tela. Em qualquer site, você pode selecionar o repositório apropriado no menu suspenso e a branch apropriada.

      Depois de ter escolhido, por exemplo, a branch master do repositório original no lado esquerdo, e a nova-branch do seu fork do lado direito, você deve ver uma tela assim:

      O GitHub vai lhe alertar de que é possível mesclar as duas branches porque não há código concorrente. Você deve adicionar um título, um comentário e, em seguida, pressionar o botão "Create pull request".

      Neste ponto, os mantenedores do repositório original decidirão se aceitam ou não o seu pull request. Eles podem solicitar que você edite ou revise seu código antes de aceitar o pull request.

      Conclusão

      Neste ponto, você enviou com êxito um pull request para um repositório de software open-source. Depois disso, você deve se certificar de atualizar e fazer um rebase do seu código enquanto espera que ele seja revisado. Os mantenedores do projeto podem pedir que você refaça seu código, então você deve estar preparado para isso.

      Contribuir para projetos de open-source - e se tornar um desenvolvedor ativo de open-source - pode ser uma experiência gratificante. Fazer contribuições regulares para o software que você usa com frequência lhe permite certificar-se de que esse software seja tão valioso para outros usuários finais quanto possível.

      Se você estiver interessado em aprender mais sobre o Git e colaborar com open-source, leia nossa série de tutoriais intitulada An Introduction to Open Source. Se você já conhece o Git e gostaria de um guia de consulta rápida, consulte “Como Usar o Git: Um Guia de Consulta Rápida.”

      Por Lisa Tagliaferri



      Source link