On Thu, Sep 3, 2009 at 22:32, Guenter<lists_at_gknw.net> 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
Received on 2009-09-07