GIT and Github - howto.

[Tom Haws]

Keith,

Git is magic and it will make all your troubles go away.  Really.  I am
speaking from real world before-and-after experience with two
clients/projects in the past two years.  Call me and we can discuss it
480-201-5476.  And you can also start by watching this essential Youtube
talk by Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 .

But for the benefit of the list, here's the scoop on Git.

1.  Yes, you can work on the same file simultaneously.  We are doing it all
the time.  And the magic only begins there.
2.  Yes, some coordination helps, but Git's (or Mercurial's) magic helps
unbelievably.
3.  The occasional manual merges referred to, in real life, usually stem
from either a) gross miscommunication or b) clumsiness (inevitable) with
Git.  It's okay, Git's (or Mercurial's) there to help you.
4.  Manual merges are SUPER easier thanks to Git.

As I've hinted (and Linus Torvalds admits) Mercurial/Hg is a worthy
alternative to Git.  SVN/CVS are not.

Maybe if I get some free time I can help you out.  I'm still in Gilbert.

Bottom line:  Git IS magic, and it WILL turn your nightmares into rainbows.

Tom
--
"To forgive is the highest, most beautiful form of love. In return, you
will receive untold peace and happiness." - Dr. Robert Muller


On Wed, Mar 7, 2012 at 6:42 PM, Alan Dayley <adayley at gmail.com> wrote:

> 1. Software development IS communication. To make it otherwise is to make
> it harder than it should be.
>
> Seems you either wait to ask for a file or you wait to see when the file
> is unlocked.  Or you change how you work as a team such that asking is
> usually answered right away.
>
> 2. Don't rewrite, separate and organize.  For example: One function per
> file.  Or five per file or something like that.  This will increase the
> granularity of the files and decrease the chance that two people will want
> the same file at the same time.  Not knowing your code, even this simple
> rule could be a bit difficult to do. It's still easier than being locked
> out of files when you need them or wiping out the other developers
> modifications.
>
> 3. Poor craftsmanship has a high cost, yes.
>
> All my experience with VSS tallies up to calling it barely usable.  It did
> file locking by default and has thus trained many developers that locking
> is a necessity.  CVS was invented years before VSS and it has strong
> merging capability.  The "C" stands for concurrent, after all!
>
> IMO file locking is a brute force bandage hiding other incorrect practices
> that developers don't think hurts the work and product.
>
> Sorry to steer the conversation away from your question.  I don't know
> what alternatives to Git do file locking since I don't use that feature,
> even if it is available.
>
> Alan
>
>
> On Wed, Mar 7, 2012 at 6:19 PM, keith smith <klsmith2020 at yahoo.com> wrote:
>
>>
>> Thanks Alan,
>>
>> 1. Developers are not communicating enough. - I was hoping to reduce the
>> need to verify each time I need a file or a group of files.  This can be
>> rather time consuming especially when we work when we want and may have a
>> last minute task to fix or modify something that takes minutes.
>>
>> 2. The source file organization needs improvement (files too big, unlike
>> functions/methods in the same file, etc.)  - There is a little of this
>> going on.  Sometimes you get what you get and you do not have the luxury to
>> rewrite massive amounts of code.
>>
>> 3. The architecture of the product, and therefore the code, is
>> suboptimal.  - From my experience, especially in the PHP world this is the
>> nature of almost all the code I have seen.
>>
>> In the end it looks like we will just have to communicate more.
>>
>> 17 years ago I worked with a company that used Visual Source Safe.  There
>> was 4 of us and a lead.  On a number of occasions it it saved us from
>> stepping on someone else's modifications.  I'm not sure how you can track
>> the work of 4 people working all day on small modifications to an existing
>> system without spending a lot of time coordinating.
>>
>> ------------------------
>> Keith Smith
>>
>> --- On *Wed, 3/7/12, Alan Dayley <adayley at gmail.com>* wrote:
>>
>>
>> From: Alan Dayley <adayley at gmail.com>
>>
>> Subject: Re: GIT and Github - howto.
>> To: "Main PLUG discussion list" <plug-discuss at lists.plug.phoenix.az.us>
>> Date: Wednesday, March 7, 2012, 5:31 PM
>>
>>
>> The need for source file locking is often an indicator of a problem.
>> Three likely ones:
>>
>> 1. Developers are not communicating enough.
>> 2. The source file organization needs improvement (files too big, unlike
>> functions/methods in the same file, etc.)
>> 3. The architecture of the product, and therefore the code, is suboptimal.
>>
>> Fix the reason file locking is needed instead of diminishing the ability
>> to get work done.
>>
>> Alan
>>
>> On Mar 7, 2012, at 5:22 PM, keith smith <klsmith2020 at yahoo.com<http://mc/compose?to=klsmith2020@yahoo.com>>
>> wrote:
>>
>>
>> Thanks James.  What is everyone else doing.  I'm sure others have had the
>> problem of needing to "check out" code so others cannot modify the file.
>>
>> ------------------------
>> Keith Smith
>>
>> --- On *Wed, 3/7/12, James Mcphee <jmcphe at gmail.com<http://mc/compose?to=jmcphe@gmail.com>
>> >* wrote:
>>
>>
>> From: James Mcphee <jmcphe at gmail.com<http://mc/compose?to=jmcphe@gmail.com>
>> >
>> Subject: Re: GIT and Github - howto.
>> To: "Main PLUG discussion list" <plug-discuss at lists.plug.phoenix.az.us<http://mc/compose?to=plug-discuss@lists.plug.phoenix.az.us>
>> >
>> Date: Wednesday, March 7, 2012, 4:51 PM
>>
>> Git doesn't really allow file locking.  You'd have to have some good
>> communication to prevent working on the same file.  Or...  You can use the
>> merge process.  If the other person updates a file, pushes to the repo, and
>> you try to pull it in after you've updated same file, you will be told you
>> need to merge.  That can get messy, but git has no built-in way to lock a
>> file.
>>
>> On Wed, Mar 7, 2012 at 4:36 PM, keith smith <klsmith2020 at yahoo.com>wrote:
>>
>>
>>
>> Hi,
>>
>> I have GIT installed on my server and I have Github.  I understand the
>> versioning part.  The concept I am having trouble grasping is how I can use
>> it a collaboration tool.
>>
>> It is just me and another programmer.  We both have a local dev
>> environment.  We work out of our homes and we live a fair distance apart -
>> about a 1.5 hour drive.
>>
>> We have a server in a data center that contains both our test server and
>> our production server.
>>
>> To this point we have worked on separate parts of this online app so we
>> have not had any occasion to step on what they other guy is doing.
>>
>> The two of us will be taking on a project that will require us to work
>> within the same code set.
>>
>> What we need to achieve is a way to checkout a PHP file work on it and
>> then check it back in.  While the file is checked no one else should be
>> able to use it.
>>
>> I've been reading about GIT, however it is not clear if I can use it this
>> way.
>>
>> Your guidance is much appreciated.
>>
>> ------------------------
>> Keith Smith
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>>
>>
>>
>> --
>> James McPhee
>> jmcphe at gmail.com
>>
>> -----Inline Attachment Follows-----
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us<http://mc/compose?to=PLUG-discuss@lists.plug.phoenix.az.us>
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>>
>> -----Inline Attachment Follows-----
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us<http://mc/compose?to=PLUG-discuss@lists.plug.phoenix.az.us>
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20120308/7818c32c/attachment.html>