Let's imagine that you have a git repository that already has a few commits.
If you're working with a team, This same repository actually exists in a few different places. It exists on a git host (like github), on your computer, and on your teammate's computer (we call each of these 'clones')
Now let's imagine that you and your partner are working at the same time. you both make commits at the same time and they are different. I'll use red to represent your work and green to represent your partner's work
Now it's a race. Whoever pushes their commit first has it easy. Let's assume your partner pushes first. The remote doesn't know about your work, so it accepts the push.
But when you try to push, it will fail, with an error that says the remote contains work you don't have locally.
Before you can push, you must pull the commit that your partner made into your local repository. Run: `git pull` We call this situation 'divergent branches' because you started with common code and diverged from there.
Now you must reconcile the differences with a merge. A merge is a special commit that has two parents. Run: `git merge`
If your commit and your partner's commit are mutually exclusive, this can happen automatically (called a 'fast forward merge'). Otherwise, you'll have a 'merge conflict' and will need to put some extra effort into deciding which version (or combination) of the two commits to keep. Open the file in your favorite editor, and find the markers that show the changes you made vs the changes your partner made. Manually delete those markers and decide what to keep, then save and close. Run `git add` and `git commit` to make the merge commit
Now you can successfully push. Note that you aren't re-writing history here, you're telling the whole story of how the code got to its current state.
Next time your partner pulls, they'll get both your original commit and the merge commit.
And from there, you can continue collaborating.