On Tue, Dec 30, 2014 at 12:14 AM, eiger3970 <kenfromthegoldco...@gmail.com> wrote:
> I think I worked out how to view vimdiff current file and previously saved > file. I have to rename the files each time. I don't know a better way yet. > Also, now I don't see why I should use git, unless it's a team environment > where I have to push to remote? I thought I could use git to quickly save > and review previous saves, but not sure how? > > First off, I strongly suggest that you read a good git book. A very good one you can read on-line, for free, is here: http://git-scm.com/documentation I use git for my personal, textual, files such as source code and configuration files. Why? 1. I control when a change is actually "saved" by doing a "git add file" followed by a "git commit". This is rather than each time I do a save. I do a lot of saves which I don't really want to keep track of. (edit, compile, test loop) 2. The saved versions are compressed automatically, and so take up less room. 3. The saved versions are in the "git directory" (usually the .git directory in the current directory) and so don't clutter up my "ls" output. 4. If I happen to make a change which reverts a previous change, that is the resulting file is actually a previous version, git does not keep an actual identical copy, it uses the older, identical, copy 5. After doing a commit, I can create a human readable tag for that level of the code. That is, I can do something like: "git tag rc1 #release candidate 1 " or "git tag production_release_1.5.2" 6. I can revert the git controlled files in toto back to some specific commit point, either by the long, git generated, commit id, or by the tag or to another branch. git checkout <tag name>|<commit id>|<branch> 7. Oh, yes, branching. Suppose I have a project. I have created the 1.5.2 version. I marked that with a git tag. Time passes and I've made changes. I need to do an emergency fix to the 1.5.2 version, but I don't want to lose what I've done; git stash git checkout production_release_1.5.2 ... fix problem ... git add -A . #stage changes git commit git tag production_release_1.5.2#fix_1 git stash pop #back to where I was before the emergency 8. Even if you are an individual, you can create a bare repository into which you can do a "push". Why? It is a rather easy way to do a backup, if you have the bare repository on a different hard drive (in case of an HD failure) or, as I do, on a NAS box. 9. You develop on multiple boxes. As I sometimes do. I can be working at home. When I get to a point, I git add; git commit; git push. The git push is to a bare respository on the web (private repo github). At work, I can do a git pull and do some hacking at work, then again "git add", "git commit", "git push" to github. When back home "git pull" to sync back up. Given that github might be hacked, I don't keep code there which is "secret" or "company proprietary". Just some of my working stuff. You want to revert to a previous commit level: git reset --hard <commit> . The <commit> can be a tag. This does _not_ "clean up" the git repository. So all the <commit> levels taken after the one you reset too are still available. If you want to get an old version of a single file, rather than everything, then "git checkout <commit> -- file.to.restore". You want to know the changes: git diff <old commit> <new commit> will show the changes to all the files which differ. git diff <old> <new> -- <file> shows only the changes to "file". -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! <>< John McKown -- 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.
