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.

Reply via email to