We Talked Git with an Expert – The Transcript

Talk with the Experts this morning was an awesome experience for those that were lucky enough to be present. The guy with all the expertise was SitePoint forum Team Leader Thom Parkin, and he definitely knows his stuff. Rather than the usual flurry of questions and answers, Thom ran more of a mini-lecture style session, and even some of the more experienced among us learned something.

Unfortunately (and more than slightly ironically), a GitHub outage half way through the session meant that access to anyone trying to get in was denied – we rely on Gists to control access to the chatroom. Apologies to anyone that failed to join for that reason.

Some good resources came out of the talk, and I have listed those below for anyone that doesn’t want to filter through the entire transcript.

A Comprehensive Beginner’s Guide to Git
McCullough and Berglund on Mastering Git
McCullough and Berglund on Mastering Advanced Git
Learn Git in 15 minutes
Thom on Using Git with Dropbox
How to commit changes to a new branch using Git

If you want to see what we have lined up in the coming weeks, we have a schedule of upcoming sessions. If you missed today’s session because you didn’t know about it, you can sign up for email reminders of future sessions.

And for anyone that wants to see what went on this morning, here is the full transcript:

[21:53] <ParkinT> A grand WELCOME to all – especially those who are new.
[21:53] <ParkinT> I encourage you to join the Sitepoint forums, where we have an active exchange of ideas and tips on Web Development and all the associated disciplines
[21:54] <HAWK> Are any of you already using Git in the daily course of your work?
[21:54] <scruggs> Whats the advantage of using git over something like subversion?
[21:54] <ParkinT> Great question, scruggs.
[21:55] <ParkinT> The discussion about Source Control can often become a bit of a “Religious arguement”
[21:55] <ParkinT> There are many who have preferences and those are usually borne out of familiarity with one particular tool.
[21:56] <ParkinT> I have used many of the most common tools, including SVN.  As a matter of fact, in my “Day Job” I am forced to use SVN.
[21:56] <ParkinT> Git has a few distinct differences that *I* see as advantages.
[21:56] <ParkinT> Primarily, it is LOCAL; meaning you do not need a centralized server.
[21:56] <Triopticon> From the short time I have tried Git, I have to say I just loving it! 
[21:57] <ParkinT> The primary complaint about Git is the [often] obtuse commands and their syntax.
[21:57] <ParkinT> And I do not disagree with that!
[21:57] <ParkinT> Systems like Subversion *require* a centralized server and special consideration to remain synchronized with that server
[21:57] <ParkinT> Git is {more or less} stand-alone.
[21:58] <ParkinT> Now, that does not mean you cannot collaborate!!
[21:58] <ParkinT> And Github is the most popular site that represents a place to host Git repositories.
[21:58] <ParkinT> I think the most common misperception (or misunderstanding) about Git is that Github and Git are one in the same.
[21:59] <ParkinT> Bitbucket is another popular site that hosts Git repositories.  But you can host a centralized Git repo anywhere.
[21:59] <HAWK> Yup, I hear that one a lot
[21:59] <Velochicdunord> How are they different?
[21:59] <ParkinT> Years ago I created a video demonstrating how to host a Git repo on Dropbox; when Dropbox was new
[21:59] <Triopticon> I like both Github and Bitbucket.
[22:00] <Velochicdunord> Any links to that video?
[22:00] <HAWK> Velochicdunord Github is a site that hosts Git repositories.
[22:00] <ParkinT> To answer Velochicunord’s question (and continue my discussion)…
[22:00] <ParkinT> Sorry.  I misunderstood the question.  Thanks, Hawk
[22:00] <ParkinT> Another thing about Git that differs from Subversion is that the entire history lives in the local repository.

[22:01] <ParkinT> You have ALL the commits (states of files) with you when working in Git.
[22:02] <ParkinT> As a matter of fact, every collaborator on a project (in a Git repo) has the entire history.  So, by virtue of that, there are numerous redundant backup copies at all times
[22:02] <ParkinT> The way in which Git stores the information is also efficient and lightweight.
[22:02] <HAWK> Welcome to those of you that have just joined.
[22:02] <HAWK> I’ll post a full transcript up on SitePoint later today
[22:03] <HAWK> But you might find this document useful in the mean time https://s3.sitepoint.com/examples/git-project-changes.pdf
[22:03] <HAWK> Hi molona
[22:03] <molona> Hi
[22:03] <molona> don’t tell me that I came late?
[22:03] <ParkinT> Sorry, I started without you.
[22:03] <HAWK> we started a few mins early
[22:03] <ParkinT> I AM JUST SO ENTHUSIASTIC ABOUT THIS TOPIC I CANNOT CONTAIN MYSELF!!
[22:04] <molona> Ok. For this time I will forgive you… for this time only :-p
[22:04] <Jerry> Say I start working on a project with some history and manual version control (either snapshots of a directory or a series of files with a version number appended to the file name). I’m starting development on a new version right now with a clean git repository. Is it possible to create a second repository to use as the master archive, building it
[22:04] <Jerry> by hand using the available files, then eventually merge the current repository into the master?
[22:04] <ParkinT> Thank you
[22:04] <HAWK> we’ve been talking about the advantages of Git over similar tools
[22:04] <HAWK> and the distinction between Git and Github
[22:04] <Jerry> A bit convoluted, but I don’t have time to create the master repository before starting the current work
[22:04] <JS> That is a very good beginning guide to Git. Thanks Hawk I read it today.
[22:04] <molona> That’s an important one… Thank you Hawk
[22:05] <ParkinT> “advantages” is a bit subjective.  But I have highlighted differences *I* consider advantages
[22:05] <Carolyn> Oh, I thought there was a free Git class starting a few minutes ago. Am I lost?
[22:05] <ParkinT> The flexibility of Git means you can approach this problem in numerous ways.
[22:05] <scruggs> ParkinT: your conclusions have been insightful
[22:05] <ParkinT> If I was facing this, here’s how *I* would handle it.
[22:06] <ParkinT> Take the current, working files and get them in to a Git repo.  Keep the previous work (maybe on a DVD) as an archive.
[22:06] <HAWK> Hi Carolyn – no, you’re in the right place. :) We’re chatting about Git now. Feel free to jump in with questions at any time. :)
[22:06] <ParkinT> I would be willing to bet that, once the project is complete, it will look much LESS like those old files than it does now.
[22:06] <HAWK> I’ll post a full transcript up on SitePoint later today
[22:06] <ParkinT> Moving forward be sure to commit your changes.
[22:07] <Triopticon> What is the differences or advantages/disadvantages compared to Mercurial?
[22:07] <ParkinT> Another thing Git does VERY well, is it allows you to ‘experiment’ or test.
[22:07] <ParkinT> Using Git branches you can make dramatic changes without any FEAR you will lose your place (or need to backtrack).
[22:07] <ParkinT> Mercurial and Git are *very* similar.
[22:08] <Carolyn> Ha. I have no idea what any of you are talking about, that’s why I wanted to take the class  to “learn Git”!
[22:08] <ParkinT> I have very, very little experience with Mercurial.  If you pressed me I would say simply, “I can spell it!!”  LOL
[22:08] <HAWK> Carolyn – you might find this document helpful https://s3.sitepoint.com/examples/git-project-changes.pdf
[22:08] <Carolyn> Thanks, I’ll go there. 
[22:08] <HAWK> Hang around if you have time. We welcome any questions at all – even very basic ones. :)
[22:09] <ParkinT> The document HAWK has referenced is a great INTRODUCTION to git
[22:09] <ParkinT> If you are unfamiliar with the concept of Source Control.  Or you are not a developer but wondering about how this tool can help you.
[22:09] <Triopticon> ParkinT – Now worries… :D
[22:09] <ParkinT> It was carefully crafted to be a safe, guided tutorial.  Just enough to get your feet wet.
[22:10] <molona> So ParkinT, have you used any other source control software before using GIT? and if so, why made you change?
[22:10] <ParkinT> I have used SourceSafe (don’t get me started!!) and, as I mentioned early, my “day job” forces me to use Subversion.
[22:11] <molona> I have to say that it is a great tool for those that use Linux, it is a bit hard when you’re used to Windows :D
[22:11] <Carolyn> I am a writer and need to learn more than one CMS, and Git is often mentioned right in the beginning. Sooo, obviously I need to learn it and know nothing about it. :)
[22:11] <ParkinT> The switch to Git was not easy for me.  It required a little adjustment in my perspective. 
[22:11] <Jerry> Thanks Parkin. Actually, we do reference the old files quite a bit for support purposes because many of the users of the product remain on older versions Two repositories is certainly better than where we are now, but it would be nice if I could ultimately merge them
[22:11] <ParkinT> But, I must say, a) reading the ProGit book and b) learning more about the internal workings of Git gave me a profound appreciation for it.
[22:11] <molona> Carolyn, GIT is not a CMS. It is a version control software
[22:12] <ParkinT> Ah, Jerry, I that was not clear to me.  I see your dilema.
[22:12] <HAWK> I used SourceSafe at my last job ParkinT, so I hear you on that!
[22:12] <ParkinT> I have been evangelizing the use of Git by “all walks of life”.
[22:12] <molona> Do you use GIT now, Hawk?
[22:13] <Carolyn> I realize that GIT is not a CMS. But when I start looking at EE or Chart, etc. etc. they immediately mention Git. So, I need to learn about it. 
[22:13] <ParkinT> One part of my “day job” involves technical training where I need to develop curricula.  Mostly these are MSWord documents.
[22:13] <ParkinT> I use Git to help me track (and retrace) my work.
[22:13] <molona> Carolyn, Ok, Apologies. Just misunderstood what you said :D
[22:13] <HAWK> I don’t do much coding these days Molona! I use GitHub, but only for the Gist functionality
[22:13] <ParkinT> Carolyn makes an interesting point.
[22:14] <Triopticon> I would also recommend this two video sit-downs at O’Reilly: “McCullough and Berglund on Mastering Git” and “McCullough and Berglund on Mastering Advanced Git”!
[22:14] <ParkinT> Git is (probably) the most popular VCS in Open Source world
[22:14] <HAWK> I should jump in and say that if anyone has any good resources, feel free to link to them
[22:14] <ParkinT> You will find yourself pointed to Git repositories (many on Github) quite often for software to download/install/use
[22:14] <HAWK> I’ll add them to the transcript when I post it later on
[22:15] <ParkinT> Thanks Triopticon.  Great resources.
[22:15] <ParkinT> Code School also has a “Try Git” course (I think it has its own domain ‘trygit.com’).
[22:15] <molona> When I installed GIT, it automatically connected to GitHub… but am I force to use GitHub? What if I want to use some other repository?
[22:15] <ParkinT> But its intended audience is software developers
[22:16] <James> it’s http://try.github.io/
[22:16] <ParkinT> There are numerous places to host a Git repository.
[22:16] <ParkinT> Here is a video I created many years ago http://www.youtube.com/watch?v=2bxbzFQEMYM  that demonstrates using Dropbox for your Git repository
[22:17] <Triopticon> Nice!
[22:17] <ParkinT> Github simply is the most popular.
[22:17] <molona> Cool, you’re my hero now ParkinT
[22:17] <ParkinT> Bitbucket is another I know that supports Git.
[22:17] * Hardy slaps Hardy around a bit with a large trout
[22:17] <Velochicdunord> Thanks!
[22:18] <HAWK> Ah, the old trout, eh Hardy?
[22:18] <ParkinT> ANother of the things Git does differently but I think is a great advantage
[22:18] <Hardy> Hehe – just wanted to see how much damage I’d do ;)
[22:18] <ParkinT> is the way it handles [what it calls] patches.  In this way you can email the Delta of a repository in a packaged form that Git understands
[22:19] <ParkinT> Hardy, you will have a bruise tomorrow!
[22:19] <Triopticon> I would say that Github is more geared against the social aspect and open source environment even if you can pay for private repos as well.
[22:19] <scruggs> “Delta of a respository”, what does that mean?
[22:19] <molona> I didn’t know that dropbox could work with GIT…nice!
[22:19] <ParkinT> True.  Git bills itself at “Facebook for developers”
[22:19] <James> Any recommended tutorials that are noob friendly?
[22:19] <jerrac> http://gitlab.org/ is good if you have the resources to host it yourself.
[22:20] <ParkinT> What I mean by ‘delta’ is the difference between one and another.
[22:20] <scruggs> Ok, thanks for clarifying.
[22:20] <ParkinT> Github, by the way, is open source.  With a web host you can create your own version of what is at Github.com
[22:21] <ParkinT> The way Git conceptualizes the commit (and the history tree) it lends itself to branching far better than others like SVN
[22:21] <jerrac> Github is open source? I’ve never seen any place to download their source code.
[22:21] <ParkinT> I can be working on a project; let’s pretend it is a website.
[22:22] <ParkinT> I get an idea that I want to try some fancy AJAX stuff.  But I am afraid to mess up what already “works”.
[22:22] <ParkinT> I simply create a branch in git.  This gives me a new place to go FROM MY CURRENT STATE
[22:22] <ParkinT> After experimenting, if I don’t like the results I can simply restore (checkout) the master 
[22:23] <ParkinT> If I have made an amazing improvement I can merge my branch with the master.
[22:23] <ParkinT> Now, here’s the cool part.
[22:23] <molona> Does merging mean that you will delete that branch forever?
[22:23] <ParkinT> I have a new set of code.  But, at anytime, I can go RIGHT BACK TO THAT PREVIOUS STATE just with a checkout.
[22:24] <ParkinT> No.  The branch is not deleted.  You can explicitly delete a branch.
[22:24] <ParkinT> But Git works really hard to not let you shoot yourself in the foot.
[22:24] <lj> How do I download from a ghithub pages BRANCH. Is it possible? I only get the master files.
[22:24] <ParkinT> YOu cannot delete a branch if it does not have any history behind it.
[22:24] <molona> Don’t worry. I’ll still manage to shoot myself in the foot :p
[22:24] <ParkinT> On Github, there is a dropdown that shows you all the branches.
[22:25] <ParkinT> Many repositories only have one (master) branch.
[22:25] <lj> I know but when I try to download with all the files from a githhub pages branch, I do not get all the files on that branch.
[22:25] <ParkinT> Like I said before, one of the unique things about Git is that the repository contains the entire history.  So, if there are branches, they will be included when you fetch the repo.
[22:26] <ParkinT> Github has added a lot of web-based, GUI stuff to allow you to view the contents of a repository.  In order to get the entire Git repository you need to use Git (traditionally on the command line).
[22:26] <lj> I can clone onto my own github, but I cannot download the branch “github pages” files to my machine to work on.
[22:26] <ParkinT> I suspect you are just copying files from the website.
[22:26] <ParkinT> Ah Github pages is not part of Git.
[22:27] <ParkinT> It is a ‘feature’ of Github.  Like Fork and Star
[22:27] <lj> yes I was trying to zip these files..
[22:27] <ParkinT> The group at Github are amazing innovators.
[22:27] <James> Should I edit the code first then create a branch? or Create the branch / checkout and add new codes? so that the changes will not appear in the master branch?
[22:27] * Codebold slaps Codebold around a bit with a large trout
[22:27] <ParkinT> Great question, James.
[22:28] <ParkinT> Whenever you issue the ‘commit’ command, all the files (that have been marked to be tracked by Git) are captured as part of that commit.
[22:28] <ParkinT> The current STATE of all those files is captured and the commit – as a whole – is assigned a Globally unique identifier.
[22:28] <ParkinT> If you then create a branch, it will – at that moment – contain all the same files.
[22:29] <ParkinT> You should then hack on those files and, when you make another commit it will be in that branch.
[22:29] <ParkinT> You now have, essentially, two different versions of the files to reference.
[22:29] <ParkinT> Think of the trunk of a mighty OAK as the master Git repository.
[22:29] <ParkinT> Each time you make a branch, it is a limb that comes out of that growing tree at some definite point in time.
[22:30] <ParkinT> The main part of the tree continues to grow, independently.
[22:30] <ParkinT> The master branch can continue to grow (change). And it will if you are working on a collaborative project.
[22:30] <ParkinT> Because OTHERS are hacking on THEIR copy of the repository.
[22:30] <Jerry> If I am on the master, edit some files, then decide I need to put the changes on a branch, how do I do that?
[22:31] <ParkinT> Unlike other systems, the synchronization process (merge) is performed on each individual computer (copy of the repo).
[22:31] <ParkinT> There is a Git command to do that, Jerry
[22:32] <scruggs> I think the best approach would be to always checkout the files you need, make changes, and them commit those changes. The commit/change history information is valuable when trying to figure out where something in the master repo changed
[22:32] <HAWK> FYI guys, due to a GitHub outage, if you leave this chatroom (by refreshing your page) you won’t be able to get back in.
[22:32] <ParkinT> That’s exactly right, scruggs.
[22:32] <HAWK> I hope they’ll sort it out soon! I rely on Gists to control access.
[22:32] <ParkinT> There is another of my ‘favorite’ commands in Git.  “BLAME”
[22:33] <HAWK> Oh the irony
[22:33] <molona> lol Hawk
[22:33] <ParkinT> You can reference a commit (or a file in a commit) and find out who/when that change occured
[22:33] <ParkinT> Gist is another innovation of the smart people at Github!
[22:33] <ParkinT> I love Gitst
[22:33] <lj> is it possible to pull in one directory of a repo into local with a terminal command? Like you said, “checkout the files you need”
[22:34] <ParkinT> *even when I cannot spell it correctly!
[22:34] <ParkinT> Yes, lj
[22:34] <Jerry> <– waiting with bated breath for the name of the command…  :)
[22:34] <ParkinT> You can `checkout` any portion of a commit by naming the file(s) you want
[22:34] <lj> yes, panting
[22:35] <ParkinT> Sorry Jerry.  Just checkout with -b for a new branch
[22:35] <scruggs> Can the git admin control that somewhat?
[22:35] <ParkinT> Then add if necessary and commit
[22:35] <ParkinT> http://stackoverflow.com/questions/14655816/how-to-commit-changes-to-new-branch
[22:35] <ParkinT> The Git admin is YOU. 
[22:35] <ParkinT> The repository is on your machine and you control the horizontal, you control the vertical…
[22:35] <Jerry> Won’t checkout -b complain if there are uncommitted changes?
[22:36] <ParkinT> Like I said before, git was designed with “human beings” in mind.
[22:36] <ParkinT> It helps you avoid making dumb mistakes and hating yourself.
[22:36] <Triopticon> :p
[22:36] <ParkinT> But it *is* possible to do anything
[22:36] <scruggs> I guess what I mean…is lets say you have multiple repos…like dev, test, and production. Could the git admin setup security rules to prevent lower developers from committing things to lets say the production repo?
[22:36] <ParkinT> Many commands include a -f (it means ‘force’) switch.
[22:37] <lj> OK so $git checkout sass this would actually download the sass folder onto my local machine? Sorry I’m not too experienced with this.
[22:37] <ParkinT> It does not make sense to setup different repositories for the same project. 
[22:37] <ParkinT> YOu want to encourage collaboration.  With Git in place NO ONE PERSON can cause the system to die with a bad piece of code.
[22:37] <HAWK> Yay – we’re open again!
[22:37] <ParkinT> Because a) you can go back in history and b) every collaborator has a copy of the entire repo on his/her desk.
[22:38] <Triopticon> I love this branching model: http://nvie.com/posts/a-successful-git-branching-model/
[22:38] <lj> Im confused when you say 
[22:38] <ParkinT> $git checkout sass would rewrite (overwrite if necessary) all the files that are part of the most recent git commit on the branch named sass
[22:38] <lj> “desk” do you mean local or do you mean my own git repo? Because I can’t get a copy of the whole repo
[22:39] <ParkinT> Don’t think of them as directories  A commit is an OBJECT that contains a whole set of files and folders
[22:39] <lj> sass is not a branch it is a directory
[22:39] <scruggs> I like your comment about collaboration. I’ve seen a few web shops that set up multiple repos as ways to show things that are under development, things that are upcoming in the next release, and things that are currently “live”. Just was curious on your take on it.
[22:40] <ParkinT> Scruggs, that is EXACTLY how branches were/are intended to be used.
[22:40] <molona> But I’m cocern that at some point I would like someone to look into some files in a particular branch but I don’t want them to commit anything
[22:40] <ParkinT>For example,  I want to try a new feature.  I create a feature branch, make my changes, test them and then push the changes to the test server.
[22:40] <molona> Altough it may be useful as a revision process if they did change the files with their comments, I suppose
[22:41] <ParkinT> If they seem to work we can ‘decide’ to merge that branch into master and deploy.  If there is a problem we can hack at it some more.
[22:41] <ParkinT> Good point, molona.
[22:41] <ParkinT> The way you do this is to a) commit the changes on the branch, b) allow the collaborator to pull (from you or from a site like Github) the entire repo to their machine
[22:42] <Sef> hey again, guys. it is just me or all of you have been disconnected? sorry for interrupting
[22:42] <ParkinT> They then have that commit as part of the entire history, merged with whatever THEY had changed in the meantime.
[22:42] <blogjunkie> Talking about testing before deploying, would you have a checklist of things to check before deploying to production? I’m working with WordPress sites specifically
[22:42] <HAWK> Sef Can you see this?
[22:42] <scruggs> blogjunkie: always plan and test!
[22:43] <ParkinT> Traditionally (and I am talking from experience back in the days even BEFORE the Internet), you have a list of ‘requirements’
[22:43] <Sef> HAWK yep, im now connected, it’s just that I couldn’t connect for half an hour
[22:43] <ParkinT> The testing process should be nothing more than validating that those requirements have been met.
[22:43] <HAWK> Yeah, sorry about that. GitHub had an outage (ironically) and I use Gists to control access.
[22:43] <HAWK> Of all the sessions for it to happen in!
[22:44] <ParkinT> LOL
[22:44] <ParkinT> The definition of irony, eh?
[22:44] <HAWK> I’ll post a transcript of the whole session up on SitePoint later today so you can see the stuff that you missed out on. In the mean time, if you have questions that are important, feel free to ask them
[22:44] <blogjunkie> ok cool. is there a list of requirements that I can refer to? otherwise i guess i could compile my own and turn it into a useful blog post…
[22:45] <ParkinT> In my experience, the set of requirements is derived (in collaboration with the client) before any work is done.
[22:46] <ParkinT> Ultimately though, the requirements should be a list of “when it does this I will consider it done and I will pay you” from the client
[22:46] <scruggs> also, it basically stems to the basics of problem-solving. what’s the problem and what steps are needed to solve the problem
[22:46] <Sef> ok, i see :) well, i actually wanted to ask a couple of questions. first is – i would like to talk about automatic websites deployment via git. is it possible for me to commit to production branch so that it will automatically launch some builds scripts / tests / whatever and in case of success bring it all to my website?
[22:46] <molona> good question sef!
[22:46] <ParkinT> Short answer:  ABSOLUTELY
[22:46] <blogjunkie> thanks ParkinT and scruggs
[22:46] <ParkinT> Another of the cool features of Git is a set of ‘hooks’
[22:46] <molona> good answer ParkinT but now expand, please
[22:47] <Sef> i know there’s a bunch of tutorials about this and continuous integration, but maybe you know some best how-to’s and stuff
[22:47] <ParkinT> Github utilizes these very skillfully
[22:47] <ParkinT> Using hooks you can trigger any number of automated operations.
[22:47] <ParkinT> I work often in (Ruby on) Rails.  And one of my favorite tools (an open Source project to which I have proudly contributed) is Capistrano
[22:48] <ParkinT> It is an automated system that – in a simple explanation – reaches out to your Git repo (from the deployment server) and PULLS IN the recent changes (or any branch you specify).
[22:49] <molona> Does the automatic stuff that you can do depend on where your repository is? I mean, if I use GitHub, there are a number things that I can do but if I use other repository, I wouldn’t be able to do them? or would I be able to code them myself?
[22:49] <sewmyheadon> We use Beanstalk for client work because it’s got built-in deployments that are easy for all our devs to setup.
[22:49] <ParkinT> No.  Github has some simply tools in their GUI that help you hook into many common services.
[22:50] <ParkinT> But Git contains the hooks and you can utilize them in any way you choose; regardless of the host.
[22:50] <HAWK> Just a head’s up all – there is 10 mins left in this session. If you’re sitting on a question, make sure you jump in with it soon.
[22:50] <molona> can you program new hooks if you need to?
[22:50] <sewmyheadon> I also saw ftploy.com does deployments
[22:51] <chris> Another good thing to do with a hook is to run something to check your source against a coding standard before you commit, like PHP_CodeSniffer for example.
[22:51] <ParkinT> Great point, chris
[22:52] <ParkinT> As far as I know the hooks exist and you would need to work on the Git source code (which is in a public repository) to make changes.
[22:52] <molona> Ok, then I assume that you can create new hooks… and maybe use the hook created by someone else?
[22:52] <ParkinT> I think they have already included everything you wourd ever need.
[22:52] <ParkinT> Realize the hooks are triggers of events in Git.
[22:52] <molona> In my case, sure! I was just curious
[22:53] <ParkinT> There are only a finite number of events that occur.  YOu are flexible to use them in any way you choose.
[22:53] <molona> yeah, probably I should have said “action” instead of hook… I was curious to find out if Git could be custom, somehow
[22:53] <ParkinT> Thank you, all, for the active participation.  I hope no one feels their question did get the proper attention.
[22:54] <ParkinT> There are many tools built to use Git in a number of ways.
[22:54] <ParkinT> Mostly they are “shell” scripts.
[22:54] <HAWK> Yeah, it’s been a fantastic session. More of a mini-lecture really. You’ve done an amazing job thanks Thom.
[22:54] <Sef> thanks guys, this was interesting, looking forward to full transcript
[22:54] <chris> Thanks for hosting this!
[22:54] <Triopticon> I enjoyed it! :D
[22:54] <HAWK> No worries. :)
[22:54] <HAWK> I run one every week. The times change slightly so make sure you check the schedule
[22:55] <blogjunkie> thanks all
[22:55] <ParkinT> Thank you HAWk.  :blushing:
[22:55] <sewmyheadon> So, here’s my boneheaded question: if I have a repo and create a feature branch that contains all the same files as the original, just in different states and containing different code, when I switch to that branch all of the files in the repo effectively ‘change’ to mimic the state of the files in the branch I’m using?
[22:55] <molona> and Hawk, of course
[22:55] <molona> and the rest
[22:55] <ParkinT> Sewmyheadon, you are absolutely correct!
[22:56] <sewmyheadon> Thanks! ParkinT
[22:56] <ParkinT> It is best to think of each COMMIT as a snapshot of the STATE of those files
[22:56] <ParkinT> A moment in time, like a photograph.
[22:56] <ParkinT> Good bye/night/day all