Git cleanup - Githubissues

pflarue / ardop

ardopcf - A multi-platform implementation of the Amateur Radio Digital Open Protocol (ARDOP)

Other

30 stars 7 forks source link

Git cleanup #14

Closed cbs228 closed 6 months ago

cbs228 commented 6 months ago

Add a .gitignore file to prevent binaries, logs, and other outputs from being unintentionally committed. The file is based on github's recommendation.
Remove "bare repo" files that appear to have been unintentionally committed in the initial commit (651ff3cf5688d8c23b9ba5caddc0c8ed409a8324). They are not necessary and can be removed.

We should decide which branch will be the default branch for new merge requests. It appears that new work is being done on develop, so I have selected the develop branch. If that is the plan, you should set the "Default branch" in the settings page to develop. This will make new PRs target the develop branch by default.

pflarue commented 6 months ago

These changes seem reasonable.

Yes, I'd prefer that all pull requests target the develop branch. My intent is to keep the master branch matching the most recent release, and keeping it as the default branch. I violated this plan by accepting Martin's pull request into master. In the future, I'll try to avoid doing that. That way, if someone clones the repository or downloads a zip file from the main page they get the released code. They have to make an additional effort to get to the less tested code in the develop branch. While I try to do some testing before I push anything to the develop branch, I intend to do do a bit more before I create new releases and update the master branch.

I'm no expert in git, and even less familiar with GitHub. So, I'm still learning how all of this works.

cbs228 commented 6 months ago

My intent is to keep the master branch matching the most recent release, and keeping it as the default branch.

I would definitely advocate for being lazy: set a default branch of develop to reduce your own workload. People can always check out a tag if they want a release. Having to rebase PRs is likely going to get very old very quickly.

Alternatively, you could write a CONTRIBUTING.md file with instructions. Github will remind anyone adding a new issue or PR to read the file. (But they don't always.)

Anyway, thanks for the review!