<div dir="ltr">The hump to get over is the distinction between a centralised repo (SVN) vs distributed. i.e. the fact that your working copy IS the repo, the whole repo. All the history. The whole enchillada.<div><br></div><div>A developer commits their work to their repository. ie. their working copy is not just just their latest version of their work on the code, but ALL of their revisions, so a developer can commit frequently and often to capture incremental revisions. Then, when work is complete they would push those changes out to other repositories that need to incorporate those changes. Again, ALL the revisions are transmitted, not just the latest changes.</div><div><br></div><div>Obviously trying to keep track of numerous sync'ed clones of a repo could be tricky, and you will ideally have a "master" repo that acts as a centralising repo. In Git this would usually be achieved with a "bare" repository.</div><div><br></div><div>A bare repository is the closest you get to a central/server repo in git. A bare repo simply means that it is a repository that contains no working code of it's own. If you navigate to that repo on disk you won't find any source code or other repo contents in directly readable form (hence "bare"). It is a repo that consists entirely of commit history.</div><div>.<br></div><div><br></div><div>To work with another repo you create a local clone. This initially contains all of the history in tat repo up to the point you clone it along with a reference back to the original repo as a "remote", allowing you to push any changes back up (or pull further changes back down).<br></div><div><br></div><div>For collaborative projects where the entire team is not directly under the repo owner's control, they will typically require that any changes you wish to submit be co-ordinated via a pull request. That is, you fork their repo, make your changes in a clone of that fork and then instead of directly pushing your changes into the original repo you send a pull-request which notifies the repo owner of the change. They are then able to review your change in your fork and pull it into the repo only if they are happy.</div><div><br></div><div>But this is just one workflow and with the flexibility offered by Git there are numerous workflow options to evaluate, in addition to understanding the core concepts they build on.</div><div><br></div><div><br>All of this I have picked up simply by reading the docs and experimenting. :)<br><br>It isn't rocket science, As I said, it's getting your head around the distributed approach that is key.</div><div><br></div><div><br></div><div><div>GitHub provides a useful playground to experiment with git. Set yourself up a free account and start playing with some public repos (you only have to pay to host private ones, or so it used to be). Be prepared to make mistakes as you get to grips with the concepts. Don't set out to create a "real" repo at first - it almost certainly won't fit your needs out of the gate.</div></div><div><br></div><div><br></div><div>Incidentally, I highly recommend Tortoise Git.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2015 at 17:03, Sean Cross <span dir="ltr"><<a href="mailto:Sean.Cross@catalystrisk.co.nz" target="_blank">Sean.Cross@catalystrisk.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We just started using it this month. I found <a href="http://www.diaryofaninja.com/blog/2014/08/20/so-you-want-your-team-to-start-using-git-ndash-part-1-getting-started" target="_blank">http://www.diaryofaninja.com/blog/2014/08/20/so-you-want-your-team-to-start-using-git-ndash-part-1-getting-started</a> to be very helpful. Syncfusion also do a " GIS Succinctly" ebook available for free from their website.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:delphi-bounces@listserver.123.net.nz">delphi-bounces@listserver.123.net.nz</a> [mailto:<a href="mailto:delphi-bounces@listserver.123.net.nz">delphi-bounces@listserver.123.net.nz</a>] On Behalf Of Rohit Gupta<br>
Sent: Monday, 30 March 2015 10:55 a.m.<br>
To: NZ Borland Developers Group - Delphi List<br>
Subject: [DUG] Anyone using GIT<br>
<br>
Has anyone been using GIT for a while ?<br>
<br>
I am looking for someone to give us a crash course on it. We will reimburse you for your time.<br>
<br>
Regards<br>
<br>
Rohit<br>
<br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br>
<br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br>
</div></div></blockquote></div><br></div>