On 2017-04-03, at 11:44 AM, bestbrightestandthens...@gmail.com wrote:

> I just need some sort of tutorial. I will see what I can find on youtube. 
> It's a rather odd product compared to other source safe systems I have used 
> in the past. The Microsoft systems I can figure out in 5 minutes without even 
> needing any instructions. Git is just plain weird.

Let me see if I can give you a quick intro to git:

Git's goal is different from most other version tracking systems. Git wants to 
track the state of the whole project at a given time, rather than the state of 
the files that make up the project.

Git's organization is based around this. Any given "commit" object represents 
the entire file tree at that point, rather than just the files that changed. 
Since you can look at the parents that gave that commit (normally 1; usually 2 
after a merge), you can quickly see which files differed, and that is what 
tells you what changed. Instead of a commit object saying what changed, a 
commit shows the tree, and you need to compare two different commits to see 
what changed.

Side note: a file is identified by its hash, so comparisons are just a quick 
comparison of 40 byte hex strings.

The first benefit of this way of arranging commits is that you can compare any 
two commits to see what files changed. You can look at the current head of a 
branch, or the point where the branch split from the main trunk, and do the 
comparison, to see what has changed on the branch, without having to track 
every commit along the way to sum up the changes.

The result?
1. Branches are cheap -- they are just the name of the current commit at the 
tip of a branch.
2. Branch to trunk comparisons are cheap -- as cheap as looking at the latest 
diff.
3. Merging is normally fast -- you just need to compare the current tips with 
where the two tips last had a common point (looking at a total of 3 places in 
most cases).

Side effects:
1. Git has a "cache" / "index" -- this is "Everything that has been checked in 
for the next commit but not yet committed". You can think of this as a list of 
the files in your project, *both those changed and not changed*. Remember, the 
commit object mentions all the files in your project, so everything is here as 
well. To see what has actually changed, this index is compared to the previous 
commit, again, by comparing the 40 byte hash strings.
2. This index is what tells git which files are a part of your project; files 
not in the index are not in the project.
3. Git has a .gitignore file to indicate which files should not be tracked -- 
not in the index, and ignored if present in the file system. Naturally, 
problems arise if the list of ignored files change while one of those files is 
present in the file system, and in some commits but not in other commits. (This 
is probably unavoidable, just be careful.)

What is a "tree": In git terms, a tree is basically a set of files that matches 
the filesystem / directory structure.

Now, another aspect of git is the push/fetch behavior, and the whole "multiple 
different repositories". While you *can* do a single, privileged repository 
with git, you don't have to; you can fetch copies of data from other people's 
public repositories, and merge their work into yours. When you like what you 
have in yours, you can push your private repository (or more likely, the subset 
that you want others to see) to your public one for them to fetch from.

> 
> On Sunday, April 2, 2017 at 6:19:15 AM UTC-6, Igor Djordjevic wrote:
> Do you need to figure out how to _use_ Git in everyday work, or how Git 
> itself works _internally_?
> 
> I may assume it`s the former, but asking about "tree" makes me wonder - that 
> said, how computer savvy are you in the first place, and what would your 
> desired context/flow of using Git be?
> 
> Before needlessly drowning you in stuff you may not be that familiar with 
> (and which you could avoid), it might be good to know what do you really 
> need, so you may get the answer that helps you the most, without creating 
> even more unnecessary confusion and headaches.
> 
> Regards,
> Buga
> 
> On Sunday, April 2, 2017 at 4:41:54 AM UTC+2, bestbrightes...@gmail.com wrote:
> Any suggestions? This company uses bitbucket and sourcetree. Is there a 
> tutorial (that works) that I could view?
> One specific question is, what exactly is a tree in computer terms? I'm 
> guessing it is a directory, so how do I list the contents of the tree?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to