Branch Cleanup
#2614
Replies: 1 comment
-
I would suggest an amendment to point 1: Creating a branch for the purpose of immediately creating a pull request and merging it, by pushing a complete set of changes from a local repo, should be okay. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've taken time to go through all branches on this project and bring them up to date with 'master' or with 'release-3.1'. Many were able to be deleted.
This is going to lead to a few things. Just thoughts off the top of my head on this.
1 - I suggest we don't create branches on the main repo.
That is bad practice unless someone is willing to maintain such a state. The current process I had to go through clearly showed at least 5 years of not keeping anything up to date. That becomes a nightmare situation and wasteful at best. I consider that all WIP. So if something is WIP, keep to your own personal repos. GHA has been fixed to build so that is no longer an issue if it was previously and we will work to fix sonar for same. External contributors are already not allowed doing this and OSS works best when we reduce our noise by following same process.
2 - Branches that come up such as 'Renovate' where we need to do more work on, we should simply pull those branches to our personal repos and do the work and submit a new PR back to the repo instead.
That avoids fact that clicking the tick box in Renovate will delete the code. While Renovate doesn't delete if author differs on its own, its stated as not that advisable of a practice.
3 - If we do any direct patch work such as messing with templates or trivial things, it seems github adds a branch so we need to be mindful to cleanup if we do that or just avoid it all together as I am going to do going forwards since that was a surprise.
4 - We need to go through all the branches we have and review them to see what we want to keep or get rid of. I did an initial pass, all seems ok to keep but I don't know any specifics of any to make that final call. Really the original author should...
5 - We may want to consider merging the locked release-3.1 back into master without applying commits, its easy and I can do it. That way its there if we ever cared to check it out but also we can remove the branch as no longer necessary and its incredibly unlikely we ever touch that again.
Deleting that branch without pulling it in will lose whatever tags it had and make it impossible to find again. Doing a process to merge it to master without applying the changes directly insures we lose nothing but keep the repo clean. Branches like that were clearly a support level branch at some point and the need is long gone so its just a good practice to make sure the repo is tidy.
Beta Was this translation helpful? Give feedback.
All reactions