This page describes conventions and best practices applicable to the Fedora Git repository.
| Table of Contents |
|---|
| Note |
|---|
Two things you should never do in git:
In general, the preferred workflow is:
|
Overview of the Git Lifecycle
Git essentially allows a developer to copy a remote subversion repository to create a local subversion repository instance on their workstation, do all their work and commits in that local repository, then push the state of that repository back to a central facility (github).
...
Now, start creating, editing files, testing. When you're ready to commit your changes:
git add [file]
This tells git that the file(s) will be marked as managed by gitshould be added to the next commit. You'll need to do this on files you just modify, also.
git commit [file]
Commit your changes locally.
...
git push is the command that changes the state of the remote code branch. Nothing you do locally will have any affect outside your workstation until you push your changes.
{git pull}} is the command that brings your current local branch up-to-date with the state of the remote branch on github. Use this command when you want to make sure your local branch is all caught up with changes push'ed to the remote branch.
...
master: this is the main code branch, equivalent to trunk in Subversion. Branches are generally created off of master.
origin: the default remote repository that all your branches are pull'ed from and push'ed to. This is defined when you execute the initial git clone command.
unpublished vs. published branches: an unpublished branch is a branch that only exists on your local workstation, in your local repository. Nobody but you know that branch exists. A published branch is one that has been push'ed up to github, and is avaialble available for other developers to checkout and work on.
...