Difference between revisions of "Git tips"

Jump to navigation Jump to search
1,802 bytes added ,  15:19, 12 February 2011
(Start the Git tips page)
 
Line 16: Line 16:
=== How to push changes ===
=== How to push changes ===


The important thing to realize is that when pushing changes to the remote server (aka "''origin''"), your changes '''''must''''' be based on the remote server. Subversion allowed you, in some cases, to commit without having the most up-to-date working copy. Git doesn't.
The important thing to realize is that when pushing changes to the remote server (aka "''origin''"), your changes '''''must''''' be based on the remote repository. Subversion allowed you, in some cases, to commit without having the most up-to-date working copy. Git doesn't.


TODO
A normal ''git push'' without any errors is one that only adds new commits, that (in their metadata) point to existing commits.
 
If you try to push local commits when the ''origin'' has commits you do not have, you will get an error similar to this:
 
To git@github.com:scummvm/scummvm.git
  ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:scummvm/scummvm.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
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 ===
=== Branchy development ===


TODO
TODO
68

edits

Navigation menu