Development work available in branches #3
KennedyRichard
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello, everyone!
In case some of you didn't notice, just wanted to point out that whenever I'm doing development work in any repos of the Indie Python project, that work will be available in branches in the respective repos. That is, in branches other than
main
, naturally.I know this already is common practice for other people and the intended way to make work available for other people to see, but you may remember until recently I was sharing a local copy of my repos instead of doing that. In the following paragraphs I explain why I switched to this conventional way of doing things and why I wasn't doing this from the beginning.
A few months ago, a member of the community asked me to make the local branch in which I was working available on GitHub as well, instead of sharing a local copy of the repo. After thinking about it for some time I reached the conclusion it was indeed reasonable and better to do so.
It is much more convenient and straightforward to access the repo on GitHub and simply switch to the branch were the work is being done instead of having to follow a link elsewhere. It is more centralized this way.
At the time, I already knew that, but I had my reasons to do so. Now I think despite my reasons, just uploading the branches to GitHub is indeed the best way.
What made me share the local copy of my repo at first was the fact that I like to edit my commits a lot, and thought it would be useful to share my local copy so that you could keep track of my work. After trying this for a few months I reached the conclusion that this is not that valuable.
Sure, it is interesting to know the many editions made (editing commits, squashing them, rebasing them, etc.), but the truth is that most people don't have time to inspect this. In fact, even if they have, it doesn't mean it would be that valuable as well. At the end of the day, we must be efficient and only care for the changes that were committed to
main
in the end.Inspecting the local copy of my repo, one can see the many edits made by checking the reflog (
git reflog
command). You can also get a better picture of what my work entails. For instance, this is an example of the same branch before (left) and after (right) my editions:As you can see, I like to edit and squash my commits a lot, before merging them into
main
. I don't like the commit history of repos to be bloated with thousands of tiny changes. I prefer to squash all the micro/medium changes made into a larger commit in the end.Of course, I only do such squashing after making sure the changes made are solid enough, because once you turn a lot of commits into a single one you lose the ability to get back to the different intermediate stages of implementation represented by the squashed commits.
Additionally, as can also be seen in the image presented above, although all or most of the work is kept at the end, only a few commits are integrated into the final history of the repo. Branches on GitHub don't show the community all the editions made, all the commits created, all the work done. They just show the few commits remaining after the squash. Because of that, people may end up with the impression that I put much less work than I did in fact.
But again, as I said, most people don't have the time anyway to inspect all the work done. Some don't even know how to use git that well and there's also people who just don't care to inspect these intermediate changes (which is a legitimate feeling).
In conclusion, this is the reason why instead of sharing a local copy of my repo, all my work on the repos has been and will continue to be easily available to you on the GitHub repos themselves, as dedicated branches. This is what I think is best for everyone, way easier to access for the community in general and way easier to discover for newcomers visiting a repo for the first time. After all, this is how git and GitHub are supposed to work anyway. That is, someone visits a repo, checks the README to know about that repo and checks whether there are branches other than
main
available to see if there's work being done at the moment.The only downside is that people can't see how much time and effort I put into the submitted changes. But, more important than that is that people have the most efficient, convenient, fastest, easiest, straightforward and standard way to access ongoing changes. And this better way is via branches on GitHub.
Just beware that commits in branches other than
main
can be edited at any time. Whenever you want to contribute to Nodezator, only ever work on top of themain
branch. Any other branch is just there...I think that's all for now. Thank you for your attention.
Peace
Beta Was this translation helpful? Give feedback.
All reactions