Versions Compared

Old Version 15

changes.mady.by.user Scott Prater

Saved on

compared with

New Version 16

changes.mady.by.user Scott Prater

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:

  • NEVER force a push
    If you find yourself in a situation where your changes can't be pushed upstream, something is wrong. Contact another Fedora developer for help tracking down the problem.
  • NEVER rebase a branch that you pushed, or that you pulled from another person
    Rebasing published branches can lead to duplicate commits in the shared repository.

In general, the preferred workflow is:

  • create a branch from master, check it out, do your work
  • test and commit your changes
  • optionally push your branch up to the remote repository (origin)
  • optionally rebase your branch to master (if your changes are unpublished)
  • checkout master, make sure it's up-to-date with upstream changes
  • merge your branch into master
  • test again (and again)
  • push your local copy of master up to the remote repository master (origin/master)
  • delete your branch (and remotely, too, if you published it)

Overview of the Git Lifecycle

...

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 available for other developers to checkout and work on.

...