- This topic is empty.
September 13, 2014 at 5:01 pm #182897
github (and similar services; tower also I assume) are actually set up in something of a nonstandard way
basic concepts. rote memorization is not the way to learn git; it makes very little sense without knowing what it is actually doing and how it organizes things:
git for ages 4 and up
Linus talking about git
(you can skip the first 6-8 minutes if you want; it starts slow)
There’s another vid that’s really really great, but I can’t find it right now. Don’t remember who did it.September 13, 2014 at 5:07 pm #182898September 14, 2014 at 7:56 pm #183028
@traq So far have watched half of that video and it’s beginning to make more sense. Thank you!!!.September 15, 2014 at 6:48 am #183081
Let me see if I’ve got this:
Commit: changes to the code are recorded during this
Branch: I don’t have a clue
Merge: takes the commit and merges with the existing code
Adrian, after watching the whole video, it became quite confusing as the audience kept interrupting. It almost seemed as if it threw off Schwern quite a bit. He was all over the place in which at one point the audience had to interject during his model building to correct him. That’s what made it evermore difficult to follow. Another thing, research him (Michael Schwern).September 15, 2014 at 8:00 am #183090
it became quite confusing as the audience kept interrupting. …He was all over the place
Yeah, I think one of the times someone asked him to explain again he accidentally left one of the flags in the wrong spot. Don’t worry about it. Most of the presentation is good, and it leaves you (me, anyway) with a good concept of what git actually does. This helps a lot with remembering the commands.
Another thing, research him
I didn’t know that. Ain’t right.
But about git, he was right.
Commit: yes, records and documents your changes. Changes are added to the existing repo.
Branch: branching is when you want to do something new. It doesn’t change the repo at all, but allows your work to be saved in a special “version” of the repo without affecting the master branch or others. To illustrate:
- I have a repo for my website. The master branch is my “live” site.
- I want to add a feature. Instead of working on the master branch (and risking breaking the production site), I make a “newfeature” branch and work there.
- I can make any changes, stop working and start again later, anything, without worrying about affecting the live site. I could even delete the whole thing, and “master” would still be there, unaffected.
- Say I found a bug in my live site before I was done. I can switch back to master, branch again (make a “fixbug” branch), and fix the bug. I’d have the same isolation in this new branch. When done, merge it back to master and switch back to my “newfeature” branch.
- when done, do all my tests, and merge “newfeature” back to “master” for deployment.*
* in this example, I’d actually pull the “bugfix” changes into my “newfeature” branch before merging back with master, so there are no conflicts. but git handles conflicts pretty well on its own, too. If the two branches didn’t actually edit the same lines of code, it would probably figure it out automatically.
merge: as seen above, merging is when you take the changes you made in a branch and put them back into the master branch (you can merge any two branches, actually, but that’s the most common scenario).
Commit will be what you do most. These will also be nice to know:
init: creates a new repo.
add: put new files into the repo. (commit only works for files already in the repo. If you make a brand-new file, you must add first, then commit it.)
If you’re working across servers (your host, github, etc.), some others that will be useful:
clone: creates a new repo by copying another one. works locally, over ssh, https. This is how you get stuff from github onto your local computer.
pull: gets changes to another repo and merges them with yours (e.g., you made a change to your repo on github and want to update your local repo to match).
push: sends changes to your repo to be merged with another repo (i.e., the opposite of pull).September 15, 2014 at 8:09 am #183092
When I say “master is my website,” I mean that it’s the version of the code that is live, not that it’s actually being served from that directory. One copy of the repo actually is the live site, but you do all your work in a separate repo, then push. Here’s why:
Branching literally changes all the files on your disk. Don’t be freaked out when this happens. Nothing is lost. If you switch back, the files will switch back also. It’s all still there.September 15, 2014 at 8:28 am #183103
Ah ha. Now all this makes much more sense. Thank you for breaking it down!September 15, 2014 at 10:57 am #183110September 15, 2014 at 11:04 am #183111nixnerdParticipant
Hey @chrisburton… are you looking for something a little more “automatic” or is it that you want a GUI? I don’t know what these things are but them seem to add an extra step that may not be necessary?
I could be completely wrong. Maybe they have crazy benefit, I just don’t understand them. I usually just clone a repo from Github.September 15, 2014 at 11:09 am #183114
@Joe_Temp I’m looking for something where I can limit dealing with the command line as much as possible right now. I’m not sure how difficult it would be to clone a repo on Centos 6 so I’ll do that research right now. Initially I was having trouble finding the correct terms to apply when searching on doing this. As you’ve just expressed, it appears “clone” is the correct keyword.September 15, 2014 at 11:11 am #183115
Have any of you used Sparkleshare or dploy.io for syncing Github repos to servers? Are there better options?
You don’t need services like this. It’s like hiring someone to turn on your car for you. (Okay, there’s a bit more value than this, but my point is it’s nothing you couldn’t do yourself, and with less hassle once you learn the process.)
I just SSH to my server, go to the directory, and do
git pull. All sync’d.
Or you could use hooks to tell git to do this automatically, as we were discussing earlier.September 15, 2014 at 11:12 am #183116
I’m not sure how difficult it would be to clone a repo on Centos 6
Not difficult at all. Create a directory, change to it, and do
git clone.September 15, 2014 at 11:17 am #183117nixnerdParticipant
I’m not sure how difficult it would be to clone a repo on Centos 6
Another point on this is that it will be exactly the same as with any other Linux distribution. And… all Git commands are standard across ALL platforms. This includes Mac and Windows. It’s easy as hell dude.
In 17 minutes, this video will teach you everything you need to know about the basic Git workflow (kudos @TheDoc).
Github makes this really easy to by giving you the little URL copy button so you can just paste it right in!September 15, 2014 at 11:20 am #183119
clone: creates a new repo by copying another one. works locally, over ssh, https. This is how you get stuff from github onto your local computer. – @traq
I know you’ve mentioned this before but I wasn’t aware this could be done to the server rather than locally.
Or you could use hooks to tell git to do this automatically, as we were discussing earlier.
Right. I know the very basics of SSH (logging in, starting/stopping/restarting apache/mysql, checking statuses and changing directories) and that’s it. Therefore, I just want my server to watch my repo and if there are changes, upload those changes to the server. I’m not sure what all that entails, whether I have install stuff just to give it a basic command to do this.September 15, 2014 at 11:21 am #183120
Not difficult at all. Create a directory, change to it, and do git clone.
But I’m assuming it would be more than that. I would actually have to install git, correct?
- The forum ‘Other’ is closed to new topics and replies.