[git-users] Re: Merging workflow
> Or course, it's perfectly sensible to > merge back to a "common" branch any bugfixes pertaining to it, but I > can't get such "accumulate and apply all at once" approach. It seems > like a quite contrived approach, whch is invented just because it > could be invented, and not from a real need. My company is moving to git soon, and I think we will need a workflow kind of like this to support our multi-product build process with point releases. Here's what we're thinking; I'd appreciate the input from the group on it. We have a single code base, from which we produce several products (prodA, prodB, etc). The code is mostly common, but some is specific to prodA, some to prodB. The idea is that the 2010 releases of all these products starts out from the same trunk, but as each one is released it goes onto its own release branch (for 2010.1, 2010.2, etc. releases). Now the question is how to handle bug fixes; we want the bug fixes to go into whatever releases need them (and only those -- to avoid destabilizing the others), but also merge back to trunk for the 2011 development that's ongoing. Our current plan is to have trunk, release_prodA, release_prodB, and release_common branches. If you have a bug fix for prodA, you go to its release branch, make the fix and test it there, commit it, and then merge to trunk. If you have a bug fix that applies to >1 product, you go to one of the release branches (release_prodA for instance), make the fix and test it, but then apply the fix on release_common. Then merge from release_common to all the other release branches, and to the trunk. This way everyone gets the common fixes, and the specific product fixes don't pollute the other products. Does that seem like a decent workflow? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Merging workflow
On Aug 13, 7:37 pm, David Doria wrote:
> Ah, so fetch is an operation on the entire repository and merge is an
> operation on a specific branch? So you're say that 'pull'ing each
> branch is not necessary because the 'fetch' in 'pull's fetch+merge is
> redundant. Is that correct?
It's a bit more involved: git-fetch can be used to fetch specific
objects from a remote repository, but in the most common case it's
used without any refspecs on the command line, and in this case Git's
behaviour is governed by a special configuration parameter. This
parameter is named "fetch", and it is autocreated for each remote when
you do
$ git remote add ...
or
$ git clone
That parameter is set for you to something like "+refs/heads/*:refs/
remotes/origin/*" ("origin" is the name of the remote here) which
means "fetch all remote branches and forcibly update the same-named
local branches pertaining to that remote".
This default setup makes "git fetch " bring everything
applicable from the specified remote.
Of course, you're free to tweak this option to suit your needs but in
the general case it just does the right thing.
> I also don't understand why this is a deficient approach? If each
> branch is for a bug fix, then wouldn't it make sense to want to be
> able to work with a branch that has ALL of the bugs fixed?
I meant something different. Or course, it's perfectly sensible to
merge back to a "common" branch any bugfixes pertaining to it, but I
can't get such "accumulate and apply all at once" approach. It seems
like a quite contrived approach, whch is invented just because it
could be invented, and not from a real need.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Merging workflow
Ah, so fetch is an operation on the entire repository and merge is an operation on a specific branch? So you're say that 'pull'ing each branch is not necessary because the 'fetch' in 'pull's fetch+merge is redundant. Is that correct? I also don't understand why this is a deficient approach? If each branch is for a bug fix, then wouldn't it make sense to want to be able to work with a branch that has ALL of the bugs fixed? Thanks for your help so far! David On Aug 13, 11:31 am, Konstantin Khomoutov wrote: > On Aug 13, 5:12 am, David Doria wrote: > > [...]> Then when I update something in Project1, I just do a > > > |[dor...@localhost AllProjects]$ git pull origin Project1 > > > and AllProjects is now up to date. > > It's not clear why you need to pull each branch. Note that pull does > fetch + merge, so each pull makes Git access the remote and ask for > changes. Hence doing multiple pulls in a row would only be sensible if > each of your "ProjectN" branches is hosted in its own remote > repository. > From your last example, it's appears to not be the case, so you should > probably do one fetch followed by multiple merges: > $ git fetch origin > $ git checkout All > $ git merge origin/Project1 > $ git merge origin/Project2 > ... > > > Is there any standard way to make a "script" to pull from a whole > > bunch of projects? Or should I just make a bash script with > > > git pull origin Project1 > > git pull origin Project2 > > etc > > ? > > To me, it appears that if you want such automation, something is > wrong. Having N parallel branches to develop N features and/or fix > bugs is perfectly OK, but having a need to periodically merge them > _all at once_ appears to be a deficient approach. Usually you should > be careful when doing each merge except for no-brainer fast-forwarding > cases, and in your setup fast-forwards should be rare. > > At least, if you will decide to write a shell script doing multiple > merges in a row, start it with > set -e > to make it crash as soon as the current merge command fails due to > conflicts. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Merging workflow
On Aug 13, 5:12 am, David Doria wrote: [...] > Then when I update something in Project1, I just do a > > |[dor...@localhost AllProjects]$ git pull origin Project1 > > and AllProjects is now up to date. It's not clear why you need to pull each branch. Note that pull does fetch + merge, so each pull makes Git access the remote and ask for changes. Hence doing multiple pulls in a row would only be sensible if each of your "ProjectN" branches is hosted in its own remote repository. >From your last example, it's appears to not be the case, so you should probably do one fetch followed by multiple merges: $ git fetch origin $ git checkout All $ git merge origin/Project1 $ git merge origin/Project2 ... > Is there any standard way to make a "script" to pull from a whole > bunch of projects? Or should I just make a bash script with > > git pull origin Project1 > git pull origin Project2 > etc > ? To me, it appears that if you want such automation, something is wrong. Having N parallel branches to develop N features and/or fix bugs is perfectly OK, but having a need to periodically merge them _all at once_ appears to be a deficient approach. Usually you should be careful when doing each merge except for no-brainer fast-forwarding cases, and in your setup fast-forwards should be rare. At least, if you will decide to write a shell script doing multiple merges in a row, start it with set -e to make it crash as soon as the current merge command fails due to conflicts. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Merging workflow
Wow.. it was that easy. Then when I update something in Project1, I just do a |[dor...@localhost AllProjects]$ git pull origin Project1 and AllProjects is now up to date. Is there any standard way to make a "script" to pull from a whole bunch of projects? Or should I just make a bash script with git pull origin Project1 git pull origin Project2 etc ? Thanks for the help! David On Aug 12, 11:10 am, Donovan Bray wrote: > Create a new branch "all" (or some other more descriptive name) based on > daviddoria, then merge the other projects into it. > > You have your combined branch, and all of the source branches won't be > polluted by each others commits. > > On Aug 12, 2010, at 7:22 AM, David Doria wrote: > > > > > Hi all, > > > I have a branch called daviddoria. From this branch, I created > > multiple branches (Project1, Project2, and Project3). I want to have a > > branch where I can use everything from all three project branches. My > > question is - if I merge Project1 into daviddoria, won't this also > > affect Project2 and Project3 (i.e. the next time Project2 and Project3 > > are pulled they will get all of the changes made to Project1)? If that > > is correct, how can I make a branch that contains all of the changes > > to all of the projects but still keep all of the projects separate > > from each other? > > > Thanks! > > > David > > > -- > > You received this message because you are subscribed to the Google Groups > > "Git for human beings" group. > > To post to this group, send email to git-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > git-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
