On Tue, Dec 30, 2014 at 12:14 AM, eiger3970 <kenfromthegoldco...@gmail.com>
> 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:
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,
2. The saved versions are compressed automatically, and so take up less
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 checkout production_release_1.5.2
... fix problem ...
git add -A . #stage changes
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
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
For more options, visit https://groups.google.com/d/optout.