The following is a list of tips,
do's and dont' s for working with the ScummVM Git repositories, compared to working with Subversion.
== Organization ==
Development is done on the ''master'' branch, which is equivalent
the the old Subversion ''trunk''. Release branches are branched from, and merged to, ''master''. Tags are always annotated (<tt>git tag -a</tt>) in order to include a timestamp.
Please keep the "official" branches on the scummvm repository to "master" and release-*. If you want to use long-lived branches for other projects, either create them on your own forked repository, or consult the team to decide if they belong in the main repository.
Dont' s ==
* '''Never ever''' use '''''git push -f''''' without discussing it on the mailing-list. That operation deletes commits from the server, and will cause problems to others working with the repository.
== Workflow ==
There are several ways to work with git. Here we'll discuss two: You could make your commits on the master branch, or you could make them on a separate branch, called a ''topic branch'' and then merge them into the master branch, before pushing. We'll cover the basics of pushing first
=== How to push changes ===
fast-forwards' section of 'git push --help' for details.
This fix this problem, we need to fetch the remote commits we do not have, and then either "put" our new commits on top of the remote repository's, or create a new "merge commit" that combines the remote repository's commit and yours.
Let's introduce several related commands:
* '''git fetch''' — Retrieves commit objects from the remote repository. You can always run this command without fear. It doesn't modify any of your local changes.
* '''git merge''' — Creates a "merge commit" from 2 or more branches. If only one branch diverges from the root, it will perform a "fast-forward" and no merge commit will be created
. ( This is configurable).
* '''git rebase''' — Moves (i.e. reapplies) a series of commits onto a different base.
* '''git pull''' — Perform a ''fetch'' followed by a ''merge'' (the default behavior) or ''rebase'' (with a flag).
So in our case, if we made a few unrelated commits, we just want to apply them on top of the remote commits, and to do that
wen can use <tt>git pull --rebase</tt> which will get the remote changes, and re-apply our local changes on top of the remote's. From that state, we could <tt>git push</tt> our changes back up.
=== Branchy development ===