Open main menu

Difference between revisions of "Git tips"

6 bytes removed ,  09:52, 13 February 2011
m
type os
(→‎Organization: Add note about official branches)
m (type os)
Line 1: Line 1:
The following is a list of tips, do's and dont's for working with the ScummVM Git repositories, compared to working with Subversion.
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 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.
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.


== Dont's ==
== 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.


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.
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. (This is configurable).
* '''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 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.
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
736

edits