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 create copy a local remote subversion repository to a local 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:
Wiki Markup git add \ [file\]}}
This tells git that the file(s) will be marked as managed by git. should be added to the next commit. You'll need to do this on files you modify, also.
Wiki Markup git commit \ [file\]}}
Commit your changes locally.
Now, the magic:
git push origin fcrepo-756
This command pushes the current state of your local repository, including all commits, up to github. Your work becomes part of the history of the fcrepo-756 branch on github.
...
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.
...