[Phpwm] Git (was Version control - project organisation)

[Dave Brotherstone]

Rob Allen wrote

> (Going off topic here)
> I've never used it, but understand that git is much much faster for
> branching and merging which is nice. Personally, with my Tech Director's hat
> on, I'm concerned about four main things with git in terms of introducing to
> the company:
>     1. The two-step process required to get a commit to the master server
> (git commit, git push). I'm especially worried that devs will commit and not
> push and have no idea how easy it is for them to see what they haven't
> pushed yet. (Of course, it may be easy to automate this for all I know!)
>     2. Windows support is not a first class citizen
>     3. Easy switching of a working copy to a different branch means more
> developer care needed to ensure on correct branch before coding
>     4. Lack of GUI tools and integration
>


Rob, just thought I'd answer these:

1. You can a git status, and it will tell you that you are ahead of the
server by X commits.  This snippet from Git bash after I just committed
something on a branch that is also on a server.

Dave at XP64 /d/work/npp/notepad-plus (IncludeRedux)
$ git status
# On branch IncludeRedux
# Your branch is ahead of 'joce/IncludeRedux' by 1 commit.
#
<snipped rest of output>

There are probably more sophisticated things you can do in order to tell
exactly what hasn't been pushed.  But, what I've found is, that even junior
devs quite like the fact that they can commit on their own, then when
they're ready to share it, they can push it.


2. Actually now Windows support is really quite good. msysGit is very
stable, and comes with Git Bash, which is bash but optimised for git usage,
so it displays the current branch you're on, tab completion for paths,
branch and remote names, plus other good stuff which i'm either not aware
i'm using, or don't know is there!

3. Actually, I think it's far easier to commit something to the wrong branch
with svn than it is with git.  See answer to point 4 (or point 2 if you
prefer the command line).  Plus, it is far easier in git to move a commit to
a different branch, than in SVN. SVN would require (I think), reverse merge
the rev on the branch committed wrongly, switch to correct branch, merge the
rev from the wrong branch.  Then you can run into problems if those two
branches ever merge.  Maybe there's an easier way..., but that's what i've
had to do in the past.

4. That's not really true any more.  TortoiseGit is actually really good now
(that's quite a recent change, IMHO, when i tried it a few months ago, it
was still a little buggy, but now it's spot on, and i use it regularly).
And, unlike TortoiseSVN, because the branches have regular names, the
context menu shows "Git commit -> yourBranchName", so it's obvious which
branch you're committing on.   I'm told Git extensions is very good too.


For me, from a work scenario, the barrier is getting the suits to understand
the benefits of the distributed bit, rather than seeing the "we're losing
control, we don't know where anything is, we've got no central server"
attitude.  The possibilities when you've got a few devs working on a
project, and they need to share some code, and not share other bits, are
really tremendous.

Plus, if you want, you can mirror the git repo to an svn repo.

<dave steps off his soapbox now> ;)

Cheers,
Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/phpwm/attachments/20090829/b62847a9/attachment.htm