I want to start putting some code into public Git, what’s some good / bad practices?

don't forget uploading node_modules

This is a fun one:

- make sure you have a good gitignore. You might consider starting a clean repo if the repo wasn't meant to be public originally, people are less cautious with passwords if they think the project is private but git keeps all committed code forever.

- try to ensure that every future commit on master compiles. People will use these for cutting edge builds of your product.

- keep some kind of documentation with the code, so that people reverting to older versions don't end up without docs.

- annotate the commits that represent releases. I use labels but some people use a branch, or multiple branches, or a mixture of both. It's a matter of taste.

- document the dev environment, the build and test process. If you can, add automated tests. Coverage is less important than to have the infrastructure in place, you can add just those tests which help you solve a specific concrete issue.

I think this is the gist of it, the rest are language and framework specific.

Just follow the contribution guidelines in the repo you want to work on. Any product with many contributors should have one.

I'd look for something where PRs actually get reviewed in a timely manner so you don't feel like you wasted your time.

Use the readme to briefly describe your project. Docs, processes, dependencies can all be referenced or inlined in the readme if they're short enough.

Wait, is this about contributing or publishing?

@lorentz
My job has a review from time-to-time and one of the things they like to hear about is how you may be contributing to the developer world outside of my work. They liked the idea of me having a few public repos of side projects, so all stand alone kinda’ work.

Was looking for advice on best GitHub practices really, so anything I put up might help someone else - not give someone extra headache!
Naturally, the ticky bit is finding some mini projects that others would find helpful or interesting!

If it's something serious already you may need to think about the licence, multiple maintainers, how to handle issues, enforce some policies together with automated tests and publishing. You also want to put extra effort in docs.

If it's not yet something like that don't worry and just put it out there. Just make sure you don't publish shit you don't want (like credentials) and add a nice readme. You get bonus points for polishing it for readability and removing commented code.

License!

In open source, as a rule of thumb, I use MIT if it's a small thing and I don't want people to worry about it, LGPL if I want improvements to also be LGPL, and GPL if I want both improvements and embedders to also be GPL. I only really use this for one project because it's very large and most likely will be a significant feature in any embedder, so I expect non-GPL embedders to contact me for a custom license.

IANAL, I talked about this with a lawyer but if you can invest the time to read a primary source you should.

Thanks all, great feedback - thank you