Op zondag 2 april 2017 04:41:54 UTC+2 schreef bestbrightes...@gmail.com: > > 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? >
I would recommend the small tutorial at Atlassian: https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud. Or perhaps this link: https://www.atlassian.com/git/tutorials/setting-up-a-repository, but anyway, that's the same, you will find the index on the left. Anyway. Things that make sense to me: - git is hard to use if you get in trouble but often times the commands needed to resolve something are suggested while you are doing it, but not always. - git has repositories that are clones of one another and all repositories are pretty much equivalent, both on the "server" and on your computer - the clone on the server is called the "bare" copy, it just contains all of the versioning control without actually having the files themselves on disk - git doesn't store files, only commits, or "changes" - any file can be reproduced from all of these changes and it regularly does that when you check out a different version of your "working directory" and git doesn't like to create sub-directories for your various "branches", each branch can be "checked out" to the current working directory which is just the space where your files are (the space above your .git directory, containing the .git directory, that contains all of the versioning control data). - so git reproduces files when you need them. - a simple git may only contain one branch, the "master" branch. - your local git is often linked to a remote git using "git remote add origin https:// ......" - git stores data in commits - each commit can contain a number of changed files that first have to be added to the index using "git add" commands - there are various "git reset" commands that either reset only the index or also revert files to their previous stored version (git reset --hard -- use with caution). - generally it is advisable to sometimes back up your entire source tree so you can undo bad git commands easily ;-). - an important thing to learn is "git rebase -i" -- this produces an interactive rebase in which you can sort, merge, and delete commits the way you want them to be sorted, merged or deleted. - splitting commits is a bit harder but can also be done. - the "git status" command shows the current index and any files that have been changed or added or deleted that are not yet in the index. - once committed, the index is cleared and no files will be "pending". - you can see the list of commits with "git log" or "git log --oneline". - "git pull" traditionally does a "git fetch" followed by a "git merge". You can change this to become "git fetch" with "git rebase" which is my preference. - without changing this preference, you can also do this with "git pull --rebase". - a git rebase will try to replay local changes on top of remote commits that you have fetched - rebasing is often used to "redo' a feature branch based on a newer version of the "master" branch - it means the changes that have happened to your older version of the master branch, will now be redone on top of the newer master branch you have access to. - this ensures that the "split off point" of your feature branch as compared to your master branch, becomes more current and less changes are left unprocessed, so there is less work to be done if you eventually completely merge your feature branch, if you would want to do that. - rebasing may require manual work like merging in case a commit cannot be replayed easily on top of a newer version, but ideally this works well without it if the same base files haven't been changed in the same places, so there is no merge conflict. - there is a way to "stash" all of the changes to your working directory (compared to the last commit you have checked out) or to stash all of the changes you have put into the index for later committing. These commands are "git stash -u" and "git stash" respectively, I think (not sure). - the benefit of stashing is that you can also "check out" your changes from the stash in order to review them. - you can check out those changes using "git checkout -p stash" and you will get an interactive dialogue that enables you to 'cherry pick' the changes you have done in order to pick those you want for the current commit; in this way you can split all of the changes you have done into multiple different commits if you want to. - so if you want to work for a while without worrying about commits, you can later just stash everything and then take out individual parts of the changes you have done, by way of "git stash -u" and "git checkout -p stash". When you are done "picking" the changes you want for the current commit, you just commit that, and then you run the "git checkout -p stash" command again to process the next batch of changes you want for the next commit. - this enables you to work for longer periods without constantly messing about with how you want to split your commits or what parts you want to go into meaningful commit X and what parts you want to go into meaningful commit Y. Commits are a way of labeling changes, so people usually try to keep them a little bit smaller than big batches of changes all in one go. by using the stash and the checkout -p, you can split those big batches of changes after the fact and still end up with nice looking commits for individual parts. - if you want to merge commits after the fact you can use "git rebase -i" which is self-explanatory for the most part. - splitting commits after the fact is a little harder because the rebase will ask you (you can ask the rebase to "edit" the current commit you select) to do a routine of deciding what to put into the index and what to put into the (two new or more) commits you want to have for the preceding older commit. This routine can be the same as described above. Once you are done creating new commits, you would do "git rebase --continue" and then it would replay the later commits on top of the changes you just made. - so this "editing an older commit" would give you the working tree at the time of the older commit as if you were doing a time travel. - you are basically given "authority" to make changes at that earlier point in time; while git remembers how to fast forward to the current moment again. - so basically git rebase -i (that's the tool that does that) can put you in charge of some in-between moment. - cherry-picking is a git concept where you "copy" commits from a different branch onto your current branch. - so when I said "cherry-picking" above I didn't mean this precisely defined concept; I meant to just hand-pick stuff (using git checkout -p stash), but "git cherry-pick" (or git cherrypick) is actually a real git command. - you can undo commits by "resetting" to an earlier commit. This may actually delete those later commits. Sometimes those later commits would still hang around in the data-store, but there would not be a reference to them anymore from the current tree (or line, or branch). At a later point, they would be garbage-collected. -- 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.
