736
edits
Difference between revisions of "Git tips"
Jump to navigation
Jump to search
m
type os
Salty-horse (talk | contribs) (→Organization: Add note about official branches) |
m (type os) |
||
| Line 1: | Line 1: | ||
The following is a list of tips, | The following is a list of tips, dos and don'ts for working with the ScummVM Git repositories, compared to working with Subversion. | ||
== Organization == | == Organization == | ||
Development is done on the ''master'' branch, which is equivalent | Development is done on the ''master'' branch, which is equivalent to 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. | 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. | ||
== | == Don'ts == | ||
* '''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. | * '''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. | ||
| Line 14: | Line 14: | ||
== Workflow == | == 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 | 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 === | === How to push changes === | ||
| Line 31: | Line 31: | ||
fast-forwards' section of 'git push --help' for details. | fast-forwards' section of 'git push --help' for details. | ||
To 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: | 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 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 | * '''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 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). | * '''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 | 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 we can use <tt>git pull --rebase</tt> which will get the remote changes, and reapply our local changes on top of the remote's. From that state, we could <tt>git push</tt> our changes back up. | ||
=== Branchy development === | === Branchy development === | ||
TODO | TODO | ||