Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Contributions to this project are released to the public under the project's open source license.
This project adheres to the Open Code of Conduct. By participating, you are expected to uphold this code.
Feature requests are welcome, but will have a much better chance of being accepted if they meet the first principles for the project. Git LFS is intended for end users, not Git experts. It should fit into the standard workflow as much as possible, and require little client configuration.
Since the focus for the project is on end users, we're generally hesitant about introducing new features that make data loss easy or are prone to misuse. However, we're not necessarily opposed to adding generally applicable customizability or features for advanced users if they don't conflict with other project goals.
The Git LFS project is managed completely through this open source project. The
milestones show the high level items that are prioritized for future work.
Suggestions for major features should be submitted as a pull request that adds a
markdown file to docs/proposals
discussing the feature. This gives the
community time to discuss it before a lot of code has been written.
The Git LFS teams mark issues and pull requests with the following labels:
bug
- An issue describing a bug.enhancement
- An issue for a possible new feature.review
- A pull request ready to be reviewed.release
- A checklist issue showing items marked for an upcoming release.In general, contributors should develop on branches based off of master
and pull requests should be to master
.
make
make test
master
: git checkout -b <my-branch-name> master
master
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
If you think you've found a bug or have an issue, we'd love to hear about it! Here are some tips for getting your question answered as quickly as possible:
git lfs env
, plus any
relevant information about platform or configuration (e.g., container or CI
usage, Cygwin, WSL, or non-Basic authentication).Git LFS depends on having a working Go development environment. We officially support the latest version of Go, although we try not to break backwards compatibility with older versions if it's possible to avoid doing so.
On RHEL etc. e.g. Red Hat Enterprise Linux Server release 7.2 (Maipo), you will neet the minimum packages installed to build Git LFS:
$ sudo yum install gcc
$ sudo yum install perl-Digest-SHA
In order to run the RPM build rpm/build_rpms.bsh
you will also need to:
$ sudo yum install ruby-devel
(note on an AWS instance you may first need to sudo yum-config-manager --enable rhui-REGION-rhel-server-optional
)
The easiest way to download Git LFS for making changes is git clone
:
$ git clone git@github.com:git-lfs/git-lfs.git
$ cd git-lfs
From here, run make
to build Git LFS in the ./bin
directory. Before
submitting changes, be sure to run the Go tests and the shell integration
tests:
$ make test # runs just the Go tests
$ cd t && make test # runs the shell tests in ./test
$ script/cibuild # runs everything, with verbose debug output
go.mod
.make vendor
to update the code in the vendor
directory.If you are the current maintainer, see the release howto for how to perform a release.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。