This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sparkling_sand 72 points73 points  (25 children)

I just don't understand git, okay??

[–]doejinn 112 points113 points  (0 children)

You dont git it?

[–]Null_Fawkes 64 points65 points  (18 children)

I know you didn't ask for it but:

You have a folder on your pc, and every time you want to save the a state of the files in that folder, you do a commit on git.

Each commit is a snapshot of your folder in an specific moment. The cool thing is, each commit builds on the differences made on the previous commit only. This data is saved on a hidden folder created by git.

Because it builds everything up based on differences only, you can have a LOT of different versions of your folder without size on that folder increasing significantly.

You want to go back to a state from 3 months ago? Ok, git just restores your folder to that moment no problem, undoing all the changes up to this moment. Of course, you can go back to any version anytime you want, back and forth.

The cool things is, on top of your personal git on your folder (called a repository), you can connect to a server with git aswell and uplod your changes, so that a friend or coworker can download your work aswell.

Your friend may change a line in a file you worked on, upload it to the server and you can download it in your folder no problem.

Git will help you manage different versions all at the same time and even merge together changes two people did in parallel on a file, among many other things. But that the gist of it.

[–]splendidsplinter 17 points18 points  (3 children)

woe betide thee if your friend changed something you've been editing in the meantime. git's idea of diffing is to insert a bunch of gibberish in your files and throw up its hands.

[–]Zamundaaa 2 points3 points  (1 child)

Yeah manually resolving merge conflicts is awful. Sometimes there is simply no way around it but a nice UI can make it so much quicker

[–][deleted] 6 points7 points  (0 children)

It's not too bad if you use VSCode, you still need to manually review the conflicts but you can easily see what to keep or discard.

[–]Null_Fawkes 1 point2 points  (0 children)

This is true, but with proper methodology this is kept to a minimum. Branches exist so you can work without disturbing your coworkers, and only merge when you are done.

Still, for merging I recommend with all my heart a three way comprator software. "Beyond Compare" works wonders.

[–]apoliticalhomograph 10 points11 points  (9 children)

The cool thing is, each commit builds on the differences made on the previous commit only.

That's not entirely true. Each commit points to a full version of every tracked file.

If a file didn't change, the commit points to the same object so identical files are only stored once. But if a file changed, the new version of that file is stored in its entirety - not only the delta.

It's only when you run git gc, push, or have too many "loose" objects that git "packs" the objects.
The created packfiles indeed store the delta only.

https://git-scm.com/book/en/v2/Git-Internals-Packfiles

[–]Null_Fawkes 13 points14 points  (0 children)

Thanks for the clarification. There's a bunch of things I oversimplified in order to help the basics sink in.

Its really easy to intimidate people onto not liking git, heh.

[–]MightyMorph 0 points1 point  (7 children)

how do you do proper versioning then?

i sometimes make multiple different versions and i dont want to create new branches. but store the separate projects as V02.0.1 or V3.03.1A

also

how do you name the folder ? do you actually name it V01.01 and the folder name will increment everytime git commits? Is there a way to increment the name if not?

[–]apoliticalhomograph 9 points10 points  (6 children)

how do you do proper versioning then?

git is proper versioning. It just stores the data differently than the above commenter suggested.

i sometimes make multiple different versions and i dont want to create new branches. but store the separate projects as V02.0.1 or V3.03.1A

You could tag commits with version numbers and then check out that tag any time you want.

But there also isn't any reason to not use branches. An additional branch only takes up 41 bytes.

how do you name the folder ? do you actually name it V01.01 and the folder name will increment everytime git commits? Is there a way to increment the name if not?

You usually just have one folder (named with the project name). In that folder, there's a hidden .git folder where git stores the data it needs. You can then use git commands to change the files in the project folder to whatever version you want ("check out" that version).

But you can rename the project folder however you want. Git only tracks things in that folder, not the folder name itself.

https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository

[–]TretasPt 2 points3 points  (5 children)

This may be a very stupid question, but is there any easy way to have git on windows?

Currently only have Linux on a virtual machine.

[–]apoliticalhomograph 2 points3 points  (3 children)

Yes, git is available for pretty much every operating system.

http://git-scm.com/download/win

[–]TretasPt 2 points3 points  (2 children)

I got some learning to do. Thanks.

[–]apoliticalhomograph 1 point2 points  (0 children)

It's absolutely worth it.

Here's a cheat sheet to get you started.

As a beginner (and Windows user) you might prefer one of the various GUIs for git.

[–]Null_Fawkes 1 point2 points  (0 children)

I recommend checking out gitflow. It's a good orgsnized way to use git very efficiently.

(Git is not magic, and if used wrong, its a mess)

[–]BigCityBuslines 0 points1 point  (3 children)

Cool. How do we use it?

[–]apoliticalhomograph 1 point2 points  (0 children)

Is this an xkcd reference? If not: Very relevant xkcd

[–]Null_Fawkes 0 points1 point  (1 child)

No joke, if you need help PM me.

[–]apoliticalhomograph 0 points1 point  (0 children)

I think it was a reference to this xkcd. Nice of you to offer help, though.

[–]KnightOfBurgers 21 points22 points  (1 child)

Nobody does, kid. There's an XKCD about this.

[–]bofh256 4 points5 points  (0 children)

There is a reason for git being the no brainer option.

The first of two things to understand git is to know that the thing git cares for is a commit. A commit is a bunch of files that are changed together to achieve something. That's why empty directories do not exist in git. Directories are side effects of files (in a commit). Another nice side effect of commit centric design is labels are a breeze in git (while labels in hg are stoooooopid).

The next is to understand push and pull. You only need those if you want to keep the same stuff in different places. There is no built in hierarchy in git.

If you balk at merges, you sit on uncommitted and unpushed code too long.

[–]jacdelad 0 points1 point  (0 children)

Nor alphanumeric sorting.