Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple guide for getting started with git

rogerdudler.github.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: A simple guide for getting started with git

#101

Post by brador »

danneu wrote: post #94
brador wrote: post #82

Earlier quoted context omitted.

So let me see if I get this right. A repository is like a slave folder to a master folder, when the master folder is updated (the github folder) the contents are automatically copied to all repositories. In this way, it saves from having to update all folders manually and keeps everything in one place, with only one thing needing changes, which then propogate automatically to where they are needed? Any idea what vers…

i use git and here's an example. you can think of a repository as a git-aware folder of code. if you go into your My_Documents folder, type `git init`, it's now a repository. if you click New Repository on github.com, navigate back to your local My_Documents repo, type `git remote add my_github_repo git@github.com:brador/my_documents.git`, you can then push your local repo into that repo with `git push my_github_repo…

Thanks, that explanation actually makes quite a lot of sense!

Re: A simple guide for getting started with git

#103

Post by MartinCron »

MartinCron wrote: post #100

Hey pixeldude, there's a lot of negative feedback on here that seems pretty hostile in tone. Don't let it get you down. It's not perfect yet, but you're writing something that I specifically wanted to give others at multiple points in the past. Some constructive criticism: don't align=center absolutely everything, it makes it difficult to read larger sections of text. If everything is centered, then nothing is center…

And a little more, I would suggest changing the focus of branches from isolating "features" to isolating "changes" as that's more generalized.

Re: A simple guide for getting started with git

#104

Post by mikeheath »

chadmaughan wrote: post #67

"There's just one thing, Dude. Do you have to use so many cuss words?" -- Big Lebowski Joking aside, there is really no need to ruin a great guide by swearing in the subtitle. I'm not sure I'll ever understand why developers think they need to swear in articles. In this instance, is it because the author is writing in nerd (addressing a seemingly technical concept) and needs to show his article has some universal acc…

+1

Re: A simple guide for getting started with git

#106

Post by adrianmsmith »

mquander wrote: post #88
jasonkester wrote: post #68

Earlier quoted context omitted.

Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than…

Note that source control in particular is particularly amenable to the command line, since the output of source control commands is blobs of text that refers to text files on disk; grepping around in it and wanting to access, process, or modify those files by name is a common operation.

I'm not sure I agree with that; I mean I use TortoiseSVN and before that TortoiseCVS as my main interface to version control, and have done for the last 10 years. It works perfectly and I don't feel I'm missing the command-line at all.

(A goal of Subversion was that its command-line commands produce output which is both easily parsable by humans and machines. But still, I never use it.)

Re: A simple guide for getting started with git

#107

Post by gigantor »

This community gets to me on occasion, parallel to that meme with the asian father saying 'Why you no get A+'?

I know what git is. I know what source control is. To my knowledge toolbox, you just added an explanation of how a git commit->master is different than a push->remote server. Mission accomplished. Win. Author, please continue executing your work and making this world a better place.

Re: A simple guide for getting started with git

#108

Post by graywh »

agwa wrote: post #31

You should mention the "git gui" command alongside gitk. It's a really great way to see the changes in your working tree, stage files into the index, and finally commit. You can even right click on hunks in the diff and select "Stage Hunk for Commit" to stage just parts of a file. Generally I'm a command-line person but git gui is a lot easier to use than "git add -i" Also, git novices whom I know have generally reac…

I particularly like "Stage Line for Commit".

Re: A simple guide for getting started with git

#110

Post by vectorpush »

jasonkester wrote: post #68
tanoku wrote: post #60

Earlier quoted context omitted.

> I don't have to actually type commands into a command prompt like some bearded guy from the '70s Really? I mean, really?

Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than…

>am aware that lots of developers seem to like the command line, but I can't for the life of me understand why.

I used to think exactly like this. It takes a while to get used to the CLI workflow, you only start to reap its benefits once you've gained a solid understanding of unix and also developed the autonomy to select the right CLI tools (e.g. tmux, zsh, vim, git) which creates synergy at every tier of your development stack.

I have written software on Windows and Linux, and when it comes to most tasks related to software development, GUIs tend to get in the way. GUIs are useful at first because all your options are laid out before you, but the complexity increases since the functionality of the entire system must be abstracted through a visual interface.

Post reply on HN