From: "Konstantin Khomoutov" <>
Sent: Tuesday, February 05, 2013 6:08 PM
On Tue, 5 Feb 2013 06:17:56 -0800 (PST)
Jacques Knipper <> wrote:

> The basic idea is that your code base evloves and at some point you
> decide that its current state is mature enough to eventually
> produce a new release after certain polishing and bug squashing.
> Normally you fork a new branch at this point and name it something
> like release-1.1.  You then can continue developing on the mainline
> branch and do only bugfix commits on the release-1.1 branch (which
> can be backported back to the mainline branch using `git
> cherry-pick`). You can have any number of such release-X.Y branches
> in parallel, of course.
> A classical essay on this approach is [1].  It contains nice
> pictures so consider reading it.  Note that it's not the only
> possible workflow, and at least you might adjust certain details if
> you decide to adopt it.
OK, I understand, a way to use git in my case is to use branching for
software release.
But how to set branch for development, integration and production in
parallels of releases branch?
The site has a nice discussion about branches and 'references', and how they are simply ways to find, and not loose, your [many and various pieces of] work.

Along with they give some insight.

It is hard to unlearn the old habits that belong in a different era. Keep smiling, it gets easier with use (for which the advice is to use it on a small interesting project to become familiar ;-)

Using regular `git branch` command (or appropriate knobs in your UI
front-end if you're using one).
Creating branches is no magic in Git, really.  There's no limits on
how many branches do exist in parallel in a given repository.

I abviously need to be able to work on any release of any packages at
any time.

No problem at all: you use `git checkout <branch>` to switch between
branches -- this command brings your work tree to the state held in the
tip of the specified branch.

Maybe you have already answered to me, and I apologize if it's the
case, but I need some lights on it I guess :)

I have a growing feeling you somehow did not manage to grasp the
concept of Git branches. I hence recommend to *play* with Git creating
a throw-away repository: create a local Git repo, throw a bunch of
files in it, record a number of commits on its default branch,
"master", fork off a "devel" branch, crunch a number of commits there,
now create a "release" branch off the master's tip (using
`git checkout -b release master`), record a number of commits there;
now check out each branch in turn and see what happens, run `gitk --all` to visualize the situation. Experiment, that is. Reading introduction
material and manuals is paramaunt for mastering a tool, but there's no
substitution for practice.

Another thing to consider is to start with readingh The Git Parable [1] which is the most gentle introduction to Git's approach to managing data
I ever saw.


You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to