I've tried adding to the .gitignore file but I can't seem to get git to ignore anything.
On Monday, April 3, 2017 at 1:07:44 PM UTC-6, Michael Gersten wrote: > > > On 2017-04-03, at 11:44 AM, bestbrightes...@gmail.com <javascript:> 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+...@googlegroups.com <javascript:>. > 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.
