2021-09-20
My experience with git has for years been that of having a repo on github or other domain where all collaborators have registered users. Some have rights to push to the master branch, while others can only push to feature branches. Either feature branches have gone through CI testing and merged to the master branch automatically, or the contributors have pushed a button in a web UI to create a pull request.
But just this last weekend I had an experience that just made everything click regarding how git works in truly distributed projects.
I wanted to contribute to someone else's project, and they had it in a git repository of their own which was publicly readable. I was given the options to either send patches by email, or use git-send-email (which I'm not sure how to set up) or send a pull request.
And it just suddenly occurred to me that I actually knew how to make a pull request and how that would work to merge.
I cloned their repo:
git clone https://their.repo
Then I created a new empty repo at tinybug.org, where I usually place my repos. And added it as a remote in the git config file:
[remote "notabug"]
url = git@notabug.org:tinyrabbit/my-version.git
fetch = +refs/heads/*:refs/remotes/notabug/*
This can of course also be done with the "git remote add" command, but I've honestly never tried it.
After this it's just a matter of making my changes and pushing them to my notabug repo. The maintainer of the project can then set up a branch tracking my repo, and merge or cherry-pick commits at their leisure.
A platform like Github makes this different, in that it abstracts these tools into a web UI and expect all collaborators to have an account at the platform. The more I learn about ways of collaborating outside of a centralised service like that, the more I've come to dislike them. Decentralised collaboration is a lot more enjoyable and empowering.
-- CC0 Björn Wärmedal