Jan Wildeboer 😷:krulorange:
Understanding and using the "Fork & Pull" model is essential for distributed software development, IMHO.
In its simplest form (there are many approaches):
- Fork from a repo in your git forge of choice (I use Forgejo)
- Git clone thatforsk to your local machine
- Work on something and commit your changes
- Push your changes to the forge
- Use the forge to create a pull request that you send upstream
- Hope for a merge, be ready to make changes
Rinse and repeat.
Jan Wildeboer 😷:krulorange:
Some people will tell you that you MUST create a branch for every work unit/feature/fix. You don't have to. Branching makes life miserable for people just starting the Fork&Pull dance. How you get to your pull request is yours to decide. You can do without branches.
Jan Wildeboer 😷:krulorange:
What *is* helpful is to add the real upstream as a second remote to your local clone. `git remote add upstream <usr@froge:<URL TO REPO>` so you can update your local clone to the current state of upstream with a `git fetch upstream` followed by a `git merge upstream/main`.
Jan Wildeboer 😷:krulorange:
But if you only do a one-off change as a drive-by coder, you don't even have to do that. You just keep your fork alive until the Pull Request is merged and after that you simply delete the whole thing as it has served its purpose and you can always create a new fork, if needed.
Fluchtkapsel
@jwildeboer That's really good advice. The only thing that'd come to my mind: How to merge my local changes with upstream then? Or rebase or whatever.
Fluchtkapsel
@jwildeboer Branches and tags are very confusing for beginners like me. The whole git concept is totally strange for people not working with it every day. So, I totally agree.
Braw ☕🏳️🌈
@jwildeboer I hate that we made forking necessary to work collaboratively on Git
Jan Wildeboer 😷:krulorange:
I think that working collaboratively with Pull Requests as abstraction layer is totally worth it. And soon(tm) we will be able to collaborate that way using #ActivityPub to connect between different, decentralised forges, getting rid of the need to have accounts everywhere :) #Forgejo (and other forges) are working on implementing #ForgeFed https://forgefed.org for that :)
Jan Wildeboer 😷:krulorange:
Which brings me back to why I started this thread: The #ForkAndPull approach as part of the #C4process in times of decentralised forges. But that's a different and longer story that I hope to develop at https://c4process.wildeboer.net :) 6/6
Jan Wildeboer 😷:krulorange:
(I admit I was a bit disappointed when I looked for a short and practical explanation of #ForkAndPull. Most articles I found dived deep into branches, rebases and merge conflicts. Which are important, but also overwhelming, if you just start to work with git and a forge. I hope this thread helps you to find out that you can do this too and with a bit of exercise it becomes a natural reflex :)
Aleksandra Fedorova :fedora:
@jwildeboer I still think that "Clone and Pull" model would be superior for drive-by contributors. "Fork" usually means overhead of long-term maintenance of your own "version" of a project in your own space, while often you just want to send a change request one time, not to become a real admin of your own full copy.
But that's an implementation detail.
Beowulf
@brawaru Forgejo also supports a method without forking - AGit 😉
https://forgejo.org/docs/latest/user/agit-support/
@jwildeboer
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.