On Thu, Sep 3, 2009 at 22:32, Guenter<[email protected]> wrote: [... git work ]
Another way to combine local work with remote repository is to use branches. Unlike CVS branches are actually working very nicely in GIT. So, here is how I do it: $ git clone git://git.stuge.se/libssh2.git <-- clone the master repo $ cd libssh2 <-- cd to new directory $ git branch <-- just check the name of the branch, at this point it's always * master $ git branch tor <-- create a new branch, named 'tor', i.e. me $ git branch <-- this command will now show the two branches, and indicate that I'm still on 'master' * master tor $ git checkout tor <-- switch to new branch, and verify that I did so: $ git branch master * tor Now I work on my own branch, commiting as I go. Occasionally, after I have commited stuff so that I have a clean branch, I switch back to master and synch with the master repo: $ git checkout master <-- I'm back to 'master', I can verify this with just 'git branch' $ git pull <-- Pull the changes on master since my original clone (or previous pull) Now I can do 'git log', 'git show' and all kinds of stuff just to have a look at those last changes. At this point I move back to my own branch: $git checkout tor And I merge the changes from upstream: $git merge master I may have to resolve some conflicts here, then commit. Other times not. And then I continue working on my branch, until my change is finished. Then I change back to 'master', and I do $git merge tor Now, when doing that command, I may want to squash all my commits on that branch into a single commit, if I did several commits which are really about the same single change, just that I commited several times because I wanted to synch while I was working. In that case I would use $git merge --squash tor which will allow me to the $ git commit the changes, with a single comment. Now I could do $ git push except that I don't have push rights so I would instead prepare the change with $ git format-patch so that someone else can apply it with git-am. At this point I may also choose to do $ git checkout tor $ git rebase master so that my branch is now again just sprouting out from the top of the master branch. All of the above is just really a 'formalized' way of working with git stash. git stash uses a temporary, unnamed branch. There are many ways of working with git, and there's no single "right way". The best is to find the method that makes the most sense to you. As for why GIT is better that CVS.. for changes I do (I work with lots of different stuff, and if they're not in GIT to start with I always make a GIT repo out of it - it's easy to combine with other version control systems): When I have my changes commited on my branch, I move to another computer with a different operating system, then I git clone my own cloned repo, or git pull it, and then I can check my changes without manual, non-versioned copies. That kind of testing used to be a pain with CVS, mostly people would push to the master repo and let everything fail when checked out elsewhere. With GIT you can clone any repo so you don't have to push changes via a master repo. For libssh2, it would be easy for two collaborating people to pull changes from each other until some new feature or bugfix was finished, before finally pushing it to the master repo. There are so many things possible, but it does work differently from many other version control systems. But then again they all do. I remember having trouble with the CVS paradigm when I moved from SCCS, and I had to scratch my head a bit when starting with GIT. Still, GIT was not hard to learn. As for SVN, even though it's supposed to be a 'better CVS', I still haven't managed to do anything useful with it - it was easier to move to GIT for me. -Tor _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
