From: "Konstantin Khomoutov" <flatw...@users.sourceforge.net>
Sent: Tuesday, February 05, 2013 6:08 PM
On Tue, 5 Feb 2013 06:17:56 -0800 (PST)
Jacques Knipper <jacques.knip...@gmail.com> 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 . 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
But how to set branch for development, integration and production in
parallels of releases branch?
The http://think-like-a-git.net/ 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 http://nvie.com/posts/a-successful-git-branching-model/? 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
No problem at all: you use `git checkout <branch>` to switch between
branches -- this command brings your work tree to the state held in
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
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
to visualize the situation. Experiment, that is. Reading
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
which is the most gentle introduction to Git's approach to managing
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 https://groups.google.com/groups/opt_out.