From: William Lasiewicz
I worked this way in other places where we shipped a release every 3 months.,
but this won't work here. . We will have a set of changes on Monday, Merge
them in, deploy to prod stage, and deploy to prod. We may then do the same
thing on Wednesday. Using this system, we would have about 6 million branches
after a 6 months.
I would like to find a way to work with GIT and keep our current workflow.
Creating a branch each time we go to prod, would give us about 10 branches a
month. It would get out of hand in no time.
Surely there is a way to do this.
Remember, branches in Git are considered ephemeral. That is, branches are
normally merged in, and then (the branch ref) deleted, The change sequence is
still there within the main commit DAG, so the name is no longer needed.
The 'cherry-pick' concept should (in a sense) only be used when you want to
'borrow' from a permanent part of the DAG/lines of development. It seems to me
perverse to have a loose branch which doesn't go anywhere, and yet is
cherry-pick picked, *and* the loose branch must then (you imply) be retained
because of the cherry pick. Once a valid 'fix' is cherry picked, you can delete
the branch because the complete change is now embedded at the destination and
has no dependency on the old branch (the commit message will say which commit
it was cherry picked from, but if it was a gash branch that part isn't
required, you simply have the 'fix' in-place)
As I mentioned previously, the mind set of Git DVCS is not the same as older
VCS systems. Why not look at how branching is done on the linux kernel, or the
Git code itself.
On Friday, March 13, 2015 at 4:35:07 PM UTC-7, Philip Oakley wrote:
From: William Lasiewicz
I am looking for a script to merge selected checkins from one branch to
another. We have a script that does this in perforce, but we want to switch
to git ( because its free)
I am looking in to it and the cherrypick command looks like what I am
lookng for.
Developers will check in to the staging branch and we we are satisfied
with the changes, we want to merge those checkin to release. We won't want to
merge the whole branch only certain checkin ( in perforce they are changelists)
Any ideas?
The Git way is to get the developers, on their local working branch, to
locally rebase (polish) their work, such that the upstream reviewers (when they
push that branch up to the public repo for review) can then take the change in
a nice easy merge.
There are variants of how upstream recieves and integrates the branches,
but the key learning is to get the individual dev's to do more (because they
can, and they feel better having the approriate freedoms ;-)
The classic post is http://nvie.com/posts/a-successful-git-branching-model/
(have a look more at what the devs are doing at this stage)
Philip
--
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/d/optout.
