Workflows

In centralized systems like subversion, you have a single repository that is shared by all team members. The problem with this system is that everyone is dependent on this central repository. If the server that is hosting this repository goes offline, no one can commit or view the project history.

In distributed systems like git, every developer has a repository on their machine. So they're not dependent on a central server, they can work offline with their local repository.
We can synchronize our work directly with each other. But this is often too complex and error prone. Instead, we can use centralized workflow. So everyone has their local repository, but there's also a central repository they used to synchronize their work. This is the workflow used in most private teams and closed source projects.
With this model, we don't have a single point of failure, we can work with our local repository and if a central repository is unavailable for a period of time, we can synchronize our work directly.
Some organizations put the repository on a server in their private network. Others prefer to use Git hosting services like GitHub, Gitlab, Gitbucket, and so on. With all these services, we can set up a repository as a private repository. So it's only accessible to our team and no one else.

First start off by cloning or taking a copy of this central repository
Use the push command to send the commits to the central repository.
Use the pull command to bring in others work into the local repository.
Resolve the conflicts and then push the changes to the central repository
The centralized workflow, which is used in most private teams, everyone in the team has push access to write to the central repository,

We have another workflow for open source projects called integration manager workflow.
In an open source project, we have one or more maintainers, and many contributors. The problem is that we don't know the contributors. So we cannot trust them enough to give them push a write access to our repository, only the maintainers of the project have push access to the project repository.
So if you want to contribute, first, we should fork the project repository to get a copy of this repository in the cloud. Next, we clone this repository to get a local copy on our machine, we make a few commits, and when we're ready to share our work, we do a push to send our commits to our forked repository.
Next, we send a pull request to the maintainer of the project. This is a feature built into platforms like GitHub. So the maintainer of the project gets notified, then they can pull in our changes, review them and if they're happy, they can merge our work into their local repository, and then push the merge changes to the official repository. This is called the integration manager workflow.
Because someone is in charge of integrating changes, we cannot push directly to this official repository. That's why we have to fork it to get a copy in the cloud. Because this repository is in the cloud. It's also visible to the maintainer of the project, and that's how they can pull in our changes.

Git