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 [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? 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. 1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
