32 replies to this topic

[.:Cyb3rGlitch:.]

... Well, yeah, I guess as a learning exercise it makes sense.  Still seems a bit like taking pyrochemistry courses to learn how to make propellants when all you want to do is go shooting.

 

Not really, since it almost never makes sense to store code outside a repository.

[Cybes]

 

... Well, yeah, I guess as a learning exercise it makes sense.  Still seems a bit like taking pyrochemistry courses to learn how to make propellants when all you want to do is go shooting.

 

Not really, since it almost never makes sense to store code outside a repository.

 

 

"Why on Earth would anyone need to shoot anything if they're not going to war?  And then they're damned well going to need to know how to make powder!"

 

Sometimes, ya just want to go plinking, ya know?  I know I have a dozen or so small personal project sources stashed away; nobody needs to see them - probably not even me any more.  But they're there in case I get nostalgic for Pascal... or have another brain tumour. ;p

[.:Cyb3rGlitch:.]

I get what you're saying, but it's a bad habit to get into. If you start with trivial projects then you're prepared when you want to move onto bigger and better things. Sometimes little hack projects end up morphing into larger projects too. Version control is one of those things that saves you time in the long run, and people always kick themselves for not learning it sooner.

[@~thehung]

aah fucking GitHub...

 

ya know, theres a few things on the net that make me feel proper retarded.  heres a short list of really embarrassing admissions:

 

- although i read Reddit a damn lot these days, i still have N.F.I. how to navigate it properly

- i NEVER understood how to use Slashdot at all -- although it seems i havent been there in ages

- whenever i follow a 'helpful' link to GitHub where i can 'find the latest build' of whatever, my inner dialogue usually goes like this:  "err....um...wheres the...is this the...no thats...gah!  where is ANYTHING here?...what in the actual fuck is going on?....have i had a stroke?....do i even know how to use a computer anymore?..." <closes tab>   (i know right :S)

 

anyway...if you are just a fledgling coder working alone, is learning to use GitHub advisable primarily because you might one day intend to manage collaboration, or is it like amazing for managing your own shit too?  because i would have thought a simple taxonomy of carefully named local files and folders should be more than enough for source files that dont add up to terrabytes.

Edited by @~thehung, 07 April 2015 - 05:39 AM.

[Cybes]

i would have thought a simple taxonomy of carefully named local files and folders should be more than enough for source files that dont add up to terrabytes.

 

Well, I can't relate to your reddit problem (intuitive for me), and I never did get into Slashdot, but I agree with you about Git.

 

Maybe it's just that there was no such thing when I was learning - everything was down to my own ability to make a naming scheme and directory structure, and keep archives.  Maybe it's that cloud storage still seems to me like a Really Bad Idea.  <shrug>  Not a problem I have to deal with any more.

[.:Cyb3rGlitch:.]

anyway...if you are just a fledgling coder working alone, is learning to use GitHub advisable primarily because you might one day intend to manage collaboration, or is it like amazing for managing your own shit too?  because i would have thought a simple taxonomy of carefully named local files and folders should be more than enough for source files that dont add up to terrabytes.

 

I use it for my own projects. The advantage is that you can quickly branch off to work on new features/fixes without breaking your always usually stable master branch. That way you never find yourself with totally broken shit. I have thousands of customers, so not using GIt would be spectacularly dangerous. I can quickly branch off master, create a fix, test it, then merge it back into master once it's been tested. Trying to do that without version control would result in a massive mess and a whole lot of work merging changes manually. Now imagine you're working on version 2.0 of your software when half way through ripping files apart the version 1.0 customers discover a major bug? You could find your manually copied backup of 1.0 (if you remembered to do it) and fix it, but then you'd have to remember to manually merge those changes into your 2.0 copy. It gets messy very quickly.

 

Learning Git (not GitHub, that's a company) has a learning curve, but the core commands/principles are actually fairly straightforward.

 

https://www.atlassia...up-a-repository

https://try.github.io/

[@~thehung]

yeah...still not really getting it.  and i guess i wont until i create something with sufficiently sprawling levels of complexity.  or, until i see an actual concrete example rather than abstract talk with fancy animated flowcharts.

i mean, half the point of modular design is that you can often work on the isolated functionality of a given source file, creating new versions with abandon until youre happy to overwrite the 'master' for each, at any point in time.

now, i can imagine it could quickly get mega complicated if your modular pieces of code are modifying global state, but even then, why not just 'fork' with abandon by making copies of the whole project each time? (since we are generally talking about ascii, as opposed to, say, massive raw assets for a video/audio project that would not be feasible in terms of storage space without multiple stages of destructive editing)

so then, okay, lets say youve got a master project and two whole alternate copies that have gone in slightly different temporary directions, and you end up with divergent bits of finalised code in each that you now want to consolidate back into the master -- things are starting to get ugly.  

but if theres little clash of dependencies then you could just open the corresponding files in multi-pane text editors to see what you need to copypasta from each. no?

however, if there ARE many clashing dependencies then, from my admittedly naive point of view, it already seems youre kind of fucked with major problems in your design concept and work flow that no fancy tool is going to be much help with.
 

Edited by @~thehung, 07 April 2015 - 06:29 PM.

[.:Cyb3rGlitch:.]

For someone who has a very small project that is only every touched by one person, it's entirely possible to get away without version control. However the effort required to meticulously name each file every time you want to duplicate the project - just to try something new - outweighs the effort required to learn the basics of Git. The prospect of manually merging files that can be merged automatically is not appealing to me, and is very prone to human error. There's also no easy way to find exactly which copy of your files is the one you want to revert back to, since there's no individual commit messages to look through. You'd have to remember which copy had the changes you want, which in my experience ends up with a very flustered Cyb3rGlitch. You can also quickly see what changed between each commit, with side by side diffs, just in case you forgot what your commit message actually meant. It's invaluable. I guess just keep it in mind until you realise you need it.

 

I'm not sure what you mean by code dependancies, since Git has nothing to do with them. It tracks changes in files, not the dependences between them, and that's about it.

Edited by .:Cyb3rGlitch:., 07 April 2015 - 07:09 PM.

[@~thehung]

yeah, dependancies kind of the wrong word.  i just meant incompatibilites in the forks that would prevent all the finalised bits and pieces of new code playing well together without rewrites (possibly trivial but numerous/tedious) at the core of the program.  i mean, when designing all sorts of stuff, there tends to be natural limits on how many alternate directions can be explored at once before it all gets forked up.

[SonOfNoddy]

I am trying hard to understand, but I can't, can someone please sum up everything that was just typed in 1 or 2 sentences?

[ArchangelOfTheLamb]

Here's an attempt at a summary:

 

Git is an online, cloud-based service that's designed for software development. It basically lets you store your source code online and has version control and forking built in. You create a repository for your project and then you add your files to it. Each file that you store will be version-numbered and any changes that you make to the version stored on Git will be tracked, which makes it easier to go back to an older version if you make changes and break something. Forking is where you, say, want to add a new feature to an existing project. It allows you to add the code for the new feature into a separate 'fork' of files, so that your main files remain untouched. This is very handy for experimenting, for if you break something, it's easy to go back to what you had originally without needing to trawl through every bit of source code and manually change everything back to the way it was before it broke.

 

Whilst Git's real power comes out when you use it for collaborative projects that several people are working on (this is where version control becomes essential), you can still use it for solo projects and small projects. For these, you can set up private repositories that only you can view and modify. These aren't accessible to the world at large.

 

Whilst that's longer than a couple of sentences, hopefully it helps to give you an overview of the purpose and benefits of Git.

[SonOfNoddy]

Here's an attempt at a summary:

 

Git is an online, cloud-based service that's designed for software development. It basically lets you store your source code online and has version control and forking built in. You create a repository for your project and then you add your files to it. Each file that you store will be version-numbered and any changes that you make to the version stored on Git will be tracked, which makes it easier to go back to an older version if you make changes and break something. Forking is where you, say, want to add a new feature to an existing project. It allows you to add the code for the new feature into a separate 'fork' of files, so that your main files remain untouched. This is very handy for experimenting, for if you break something, it's easy to go back to what you had originally without needing to trawl through every bit of source code and manually change everything back to the way it was before it broke.

 

Whilst Git's real power comes out when you use it for collaborative projects that several people are working on (this is where version control becomes essential), you can still use it for solo projects and small projects. For these, you can set up private repositories that only you can view and modify. These aren't accessible to the world at large.

 

Whilst that's longer than a couple of sentences, hopefully it helps to give you an overview of the purpose and benefits of Git.

Well, it may be longer than a couple of sentences, it's still a decent summary, not to say that everyone else didn't do a good job explaining, i'm reading it all now and It makes sense (what the others wrote that is), turns out I was either tired af, or naive af, probably both :p

[Sir_Substance]

Git is an online, cloud-based service that's designed for software development. It basically lets you store your source code online and has version control and forking built in.

*twitches a little* That's what github is.

Git is a version control system. There are lots of them out there. Subversion, Mercurial, Perforce, Team Foundation Server and Fossil are all version control systems. Git is one of the most popular, although I would argue that Mercurial is friendlier to newcomers. Whatever. You install them on your computer, they're a program, just like firefox.

The purpose of a version control system is to maintain a full history of your code. It's kind of like an enhanced save function. You can write some code, hit ctrl-s, write some more, save again. At some point, you'll go "Ok, this is working. This is good.". At that point, you may choose to commit your changes to your VCS. This takes a snapshot of your code, and stores it in the version control system. At any point in the future, you can ask the version control system to show you the difference between the current code on your computer, and what it was like the last time it was working properly, when you committed it. You could roll back to that version if you had problems, or just wanted to test how it worked at that time.

VCS's often support branching as well. You might have a problem, and can think of two possible solutions to it. You can branch your code, and the VCS will keep track of two different copies of it. You can swap between and work on both branches, until you decide on your preferred solution. You can then merge that branch back into your main (often called release) branch, and continue developing. Maybe later, you might want to go back and look at the alternative solution you discard. The version control system still has it stored, and can show it to you.

They often have a bunch of other features as well, including decentralized sharing of code, storage of large binary files, redundant backup, access control blah blah blah. At some point as you continue coding, you'll one day find yourself copying a folder and naming it "sourcecode_backup_2016_11_18" or whatever, because you want to make a change but you're worried you're gonna break your currently working code, and you want to have a copy of the working version on hand. When you find yourself about to do that, that's the point where you should go look into git :)

Github is all that, but managed via a nice web interface. It's kinda sorta turned into a programmers social network as well. I'm not a fan of giving other people control over my sourcecode, so I run a self-hosted instance of gitlab instead, but I'm rapidly turning into an angry old man that yells at Clouds so don't listen to me.

edit: also jeez this thread was from last year, how embarrassment

Edited by Sir_Substance, 19 November 2016 - 06:40 AM.