Understanding and using the "Fork & Pull" model is essential for distributed software development, IMHO.

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. 2/6

#C4process

Jan Wildeboer 😷:krulorange:

What *is* helpful IMHO is to add the real upstream as a second remote to your local clone. `git remote add upstream <user@forge:<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` (or whatever other name than `main` upstream uses for the default branch). 3/6

#C4process

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. 4/6

#C4process

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.

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.

Jan Wildeboer 😷:krulorange:

This post is deleted!

Braw ☕🏳️‍🌈

@jwildeboer I hate that we made forking necessary to work collaboratively on Git

Jan Wildeboer 😷:krulorange:

This post is deleted!

Jan Wildeboer 😷:krulorange:

This post is deleted!

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 5/6

#C4process

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

#C4process

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.

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

Jan Wildeboer 😷:krulorange:

This post is deleted!

Beowulf

@brawaru Forgejo also supports a method without forking - AGit

https://forgejo.org/docs/latest/user/agit-support/
@jwildeboer

Jan Wildeboer 😷:krulorange:

This post is deleted!