Samba GIT Mini-HOWTO

Gerald (Jerry) Carter jerry at
Thu Oct 4 19:37:52 GMT 2007

Hash: SHA1


This is a working draft.  I'll post it to the Wiki after a few
rounds of comments and edits.  Probably the workflow section
is of most interest for people.

cheers, jerry

## DRAFT: Samba-GIT-Mini-HOWTO

Git Installation

The git source code is available from

The project home page is located at

The examples in the following sections are based off of the tools
and syntax used by git v1.5.3 or later which is the recommended
version for Samba.  Either apt-get, yum, or make install the tools.
See Git documentation for details on this part.

Basic Samba Git

The master git repository is currently located at

There is also a GitWeb installation at

Cloning the repository:
  $ git clone git:// samba
  $ cd samba

Listing remote branches:
  $ git branch -r

Listing tags:
  $ git tag -l

Creating your own working branch from v3-2-test:
  $ git checkout -b my_branch origin/v3-2-test

* SVN-DIFF: Git uses views rather than the svn layout of
  putting branches into individual directories.  This may
  seem like a deficiency at first, but is very natural
  the more your use it.

Fetching remote branch history:
  $ git fetch origin

Merging remote branch changes:
  $ git merge origin/v3-2-test

Viewing status of local branch checkout after doing some work:
  $ git status

Committing changes:
  $ git {add,rm} <filename>
  $ git commit

* SVN-DIFF: Git only commits what has been added or removed
  from the index cache via git-add or git-rm.

Advanced (But Potentially Dangerous) Commands

* git-rebase
* git-reset
* git-gc

Publishing Your Work

[INCOMPLETE] At least read the tutorial at

Development Work Flow Policies

The best way to describe the proposed Distributed-VCS workflow
is the process of how a patch or feature should makes its way
into the stable tree.  Currently there are three branches for
each major release series (v3-0, v3-2, & v4-0).  These branches,
modeled after the debian release tags, are:

  * unstable
  * test
  * stable

The short versions of bringing a patch from beginning to end
is a push/pull/merge combination.

  1.  The developer pushes to "unstable" (may be skipped
      for obviously correct changes).
  2.  The release manager pulls from the developer to "test".
  3.  And then merges to "stable".

The "unstable" tree is a shared repository open for all Samba
Team developers with an ssh account on and is
the first code base run on the buildfarm.  Developers should
use this branch (e.g. v3-2-unstable or v4-0-unstable) when
testing portability issues, regression testing, and other
features supported by Samba's buildfarm infrastructure.

The "test" and "stable" branches are maintained by the
series release manager.  When a developer has a feature
that is complete, has passed the build farm tests, and
is ready for widespread testing, an email should be sent
to the samba-technical mailing list asking for the RM to
pull from the developers feature "test" branch.  Assuming
that the changes passes code review and are approved by
a majority of developers, the code is pulled into the series
"test".  The RM may then merge is the changes from his/her
"test" tree to "stable" once sufficient testing has been
done to ensure that the change integrates cleanly into the
tree with no known regressions.

The "stable" tree performs the role of the previous svn
branch SAMBA_x_x_RELEASE trees and is the code base from
which release tarballs are cut and signed. The RM is
responsible for tagging releases from this branch.

Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list