Hi Curt, 2011/1/7 Curtis Olson <curtol...@gmail.com>: > Hi Stefan, > Thanks for the reply. You are exactly right to notice that I am struggling > a bit to understand the proper git workflow when dealing with branches. I > have a couple more questions inserted below ... > > On Fri, Jan 7, 2011 at 1:39 PM, stefan riemens wrote: >> >> Hi Curt, >> >> git merge is your friend! Perhaps a complete example workflow will >> help you get along: >> suppose you are on branch "next" tracking the gitorious branch "next". >> git branch wip -- wip is now an exact copy of the next branch >> git checkout wip >> Edit files to add some really cool feature >> git add [files to add] -- select which modified files you want to >> commit to branch "wip" >> git commit >> >> Suppose you want to update your next branch, and incorporate those >> changes in you "wip" branch: >> git checkout next >> git pull -- updates your branch "next". Should not produce any >> merge-conflicts, since you didn't alter anything in your local branch > > Clarification: as long as I've committed all my local changes to the wip > branch before I switch back to the next branch, then I shouldn't ever have > any conflicts, right? If I switch back to the next branch with some > uncommited changes in my branch, those will be sitting there still in my > local next branch and I could have problems with the pull (and blindly > following the suggestions in the git error messages isn't probably always > the best solution I've found.) :-) Am I understanding all this right? > Yes, that is correct. Uncommitted changes are at the filesystem level and don't belong to any branch. Note that switching branches in this case may fail, because git can't merge uncommitted files. That's also the reason that a pull may fail if you have uncommitted changes. >> >> git checkout wip >> >> git merge next -- merges changes in "next" into your "wip" branch >> (in case of merge-conflicts, fix 'em) > > Questions: > Can you explain exactly what this "git merge next" does? Does the it only > merge my local changes in the next branch into my wip branch? Does it > merge all remote changes to the remote next branch into my local wip branch? > Do I first need to do a git pull in my next branch before switching to my > wip branch and doing the merge? > What if it's been a few days since I created my "wip" branch and I've > committed a few local changes to it. Now I want to make sure my wip branch > is fully up to date with all remote changes on the remote/server's next > branch? What is the proper way to do that? > I could describe this another way. Pretend I want to do something > similar/analogous to an "svn update" on a tree where I've made some local > changes, but I want to catch up with all the remote changes and make sure my > local changes are compatible and function correctly and there aren't merge > conflicts. But in the git world I now have my own separate branch, my own > local commits, and now I want to update that my local "wip" branch to > reflect all the changes that have been subsequently pushed to the remote > next branch by other developers. >> Git merge next will do just that: merge your local branch "next" into the current branch. So in this example where wip is a couple of days "old", you could bring it up to date using this sequence: git checkout next -- checkout your local next branch git pull -- get the changes in the gitorious "next" branch, and merge them into your local "next" branch. git checkout wip -- checkout your local "wip" branch git merge next -- merge your local branch next into the currently checked out branch (wip)
>> git add [conflicted files] -- git's way of marking the conflicts resolved >> git commit >> >> Suppose you've got your "wip" branch in good shape, and up to date >> (ie, you've just merged next into wip) and want to push to gitorious: >> git checkout next >> git merge wip -- should not produce merge-conflicts, since wip was >> already up to date >> git push > > One question here: > Let's say I have committed two unrelated features into my "wip" branch. Is > there a way to merge individual features/commits? Or is it all or nothing? > If I want finer grain control would I have to create a new branch for each > independent feature/idea I am working on? > Yes, that sure is possible. git merge [commit hash] works fine for this. There is also git cherry-pick, I've never used that myself though, so I can't tell you how that works exactly. However, always remember that branches are cheap with git, so it is very git-like to use a branch per feature. >> >> Then another useful feature of git: you can easily alter history. >> (NOTE: you should only change history that is only your own repo. >> Don't change the history which is already in more repos (pushed to >> gitorious) >> git commit --amend -- "extends" the previous commit. Useful when >> you're working in a branch, and need to make a temp commit to be able >> to switch branches. You should also be able to use git stash in this >> case, but I find this to be a lot less confusing than git stash > > When studying robotics, the "level of intelligence" of a system is defined > by how detailed your instructions to the system have to be in order for it > to successfully accomplish the task. > For instance, let's say the task we want to accomplish is to open a jar of > pickles. Can you just say "open the jar". Or do you have to say lift up > your hand, now put it on the jar, no on the jar Patrick, the jar, no the lid > of the jar, ok turn it, no turn the lid, no hold the jar still while you > turn the lid ... (spongebob reference) :-) > I'm not sure why this thought popped into my head right now ... and I'm not > sure at the moment if it would apply to git or apply to myself. :-) > Curt > -- > Curtis Olson: > http://www.atiak.com - http://aem.umn.edu/~uav/ > http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ Stefan > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
