未加星标

Merging an Open-Source Pull Request

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二03 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

I'm going to share a video with you where I merge a PR on Github where I use two more advanced techniques to provide an alternative to a straight git merge . Don't miss this if you are going to start maintaining or contributing to an open-source project.

A new open-source project

A couple of weeks ago I started an open-source project to create a Golang port of the Pimoroni Blinkt library. The Blinkt is a hardware add-on for the Raspberry Pi with 8 RGB LEDs.

My aim for the Golang library was to match the python interface and API as closely as possible and then to port the examples one-by-one. Before sharing the library I wrote two blog posts to help people get started with Golang and the Raspberry Pi:

Golang basics - fetch JSON from an API

Golang and Docker 1.13 on your Raspberry Pi

The video

In this video I checkout a pull request from rgee0 , test the code and then rebase and squash his commits before pushing them back to the master branch on Github.

Additional notes

I wanted to highlight a few points about merging pull requests on an open-source project:

Checking out a PR for testing/editing

Once you have eye-balled a Pull Request on Github you will probably want to pull the code down onto your laptop or device to test it out. In the video we used git fetch . Read more on the Github documentation page:

Checking out pull requests locally Merge vs. rebase

Using git rebase overlays someone else's work over the top of your repository. If you have any pending changes you will need to commit them or stash them away with git stash prior to running the command. It saves spamming your log with messages produced by git merge like: Merging branch xyz into master .

The Github UI has recently added a feature to help maintainers for when squashing and rebasing is not practical for the contributors.


Merging an Open-Source Pull Request
Communicating with your contributors

Contributions to open-source projects could come from anyone, anywhere and at any time - so communication tends to be asynchronous and sporadic. Leaving specific and objective feedback will help with communication as will a paragraph or two on what kind of contributions are wanted.

Are you looking for specific help? Mention features / roadmap items Do you have goals and non-goals? It would be better for someone to know up front whether there vision aligns with yours Is there a contribution process? This could be anything from "No contributions wanted" to a paragraph about process or even a separate page with a checklist. Mention your project's license - so contributors can check if this is suitable for them. Example: Contributing guide

The docker/docker project has a detailed set of guidelines. Before a pull request is raised they recommend you first create a Github issue. By raising an issue before your PR it promotes discussion and increases the visibility of incoming changes.

Check out Docker's contributing guide for some more info on best practices for using Git to contribute to a large successful project.

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

主题: GitRaspberry PiDockerPython
分页:12
转载请注明
本文标题:Merging an Open-Source Pull Request
本站链接:http://www.codesec.net/view/534014.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(15)