pcottle/learnGitBranching https://github.com/pcottle/learnGitBranching as game with virtual animation, show u git orders what doing ;-)
On Wed, Mar 12, 2014 at 9:36 AM, HaveF <[email protected]> wrote: > I'm glad you like it. > > btw, git ref is another site which I like :-D > If you know some github thing would be much nice, but obviously, this thing > have low priority. > > -- > HaveF > > > On Tuesday, March 11, 2014 11:02:31 PM UTC+8, Edward K. Ream wrote: >> >> Yesterday someone suggested I read peepcode-git.pdf. I haven't been able >> to track down the thread, but you can find it here: >> https://github.com/pluralsight/git-internals-pdf/releases >> >> Despite it's name, it's an excellent overview of git and its workflow. I >> don't understand all the "hard parts" yet, but things are starting to fall >> into place. Some quotes: >> >> Pages 38-40: Use cases: >> >> "You have a master branch that is always stable – you never merge anything >> into it that you wouldn’t put into production. Then you have a development >> branch that you merge any experimental code into before you imagine pulling >> it into the master branch... >> >> Working with others is unbelievably easy. You ask in an IRC room if >> someone has implemented a feature in a library you are using. Turns out that >> someone has and you are sent the URL of their public Git repo for that >> project. You add it as a remote, fetch it, create a new merge-feature branch >> off your development branch, merge in the new changes and you’re done. >> There’s no awkward emailing of patches – you can just add contributors as a >> remote and try out their branches before deciding to merge them in. If it >> breaks things or is not a good patch, you simply delete the merge-feature >> branch and that’s it." >> >> I don't really get how this is going to work, but I am confident that with >> a little bit of coordinated experimentation all this will become much >> clearer to us all. >> >> Page 40-41: >> >> "You branch and rebase or merge several times a day in and out of several >> different branches, some of which last for hours and some are continually >> there. Once you get used to this pattern, it completely changes the way you >> approach your development and the way you contribute and collaborate." >> >> Sounds very cool. Again, learning by doing seems essential. >> >> Any comments? I'll reread this pdf several times before suggesting that >> we begin to experiment collaboratively. >> >> Edward > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦! KM keep growing environment culture which promoting organization be learnning! 俺: http://zoomquiet.io 许: http://creativecommons.org/licenses/by-sa/2.5/cn/ -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
