

Git: the minimum you need to know (sorta like a cheat or nutshell) - gtani
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
note that hyphenated commands are now officiall discouraged/deprecated<p>http://article.gmane.org/gmane.comp.version-control.git/72874
======
litewulf
One of the most frustrating things about git (as someone who occasionally uses
git, mercurial and svn) is that the title here is "20 commands".

For svn my workflow is (checkout once), update, commit. Whereas I feel I'm
mucking about in man and googling substantially more in order to do things in
git.

~~~
cstejerean
You've never used svn to create branches, merge, revert back an accidentally
modified file, look at the log or run svn blame on a file?

If all you use svn for is commiting changes you might as well use periodic tar
snapshots, then your workflow would be completely eliminated.

~~~
litewulf
I want to clarify, the commands I use daily in svn number at two: update, and
commit. I actually use IDE integration for most of the
adding/deleting/copying, though I use the command line for that in svn and git
when it suits me.

The "problem" with git is that there are commands like git-branch which I use
infrequently... so I can never quite remember how it works. (Just like
revert.)

This isn't really an attack on git, its perfect when I use it daily, but the
moment I stop, I have a week of floundering about idiotically while
CVS/SVN/etc feel substantially more simple. (Perforce as well, but to a lesser
extent)

~~~
cstejerean
git is certainly full of interesting commands, and I'm still learning about
some of them after 6 months. When unclear about a command try using

    
    
      git --help commandname
    

I highly recommend getting used to some of the "advanced" commands in git,
once you learn to master them they become powerful tools.

~~~
litewulf
Right. And thats my problem. "I'm still learning about some of them after 6
months".

Its tiring to have to type git --help, or man git-blah or whatever. Is it cool
because I realize I have INFINITE POWER WAHAHA? Yah. But I have to look it up
too :(

------
Oatmeat
I'm a single developer who has recently switched from subversion to git and
I'm having a few problems adjusting. My setup is that I work on my code from
various places (home, laptop, school) and I want to a consistent view of my
code from each place. That is, if I create a git branch at home and write some
code in it, I want to see that branch right away when I start working from
school.

Right now, I have a main server set up where I push my changes to after
finishing work for the day. But now suppose I create some new tags and
branches. I need to do

    
    
      git push --all
      git push --tags
    

Then when I start working from a different location next time, I do

    
    
      git pull
      git checkout --track -b <new-branch> origin/<new-branch>
    

Where I have to do the last command for each new branch that I want to see in
my working copy. Things are even worse when I want to delete a branch (after
having merged it into the mainline). I do

    
    
      git branch -d <branch-name>
      git push origin :<branch-name>
    

And this will remove the branch from the local repository and my main repo,
but at each of the other repositories I still need to delete the remote
tracking branch.

Does anybody know a way to simplify this workflow with git?

~~~
aggieben
From home, start with condensing to one command:

    
    
      git push --all --tags
    

From location1, if you just want to be able to make your working copy look
like origin/<branchname>, you don't have to create a new branch. You can
checkout on a tracking branch. You just can't do all your normal work there
(i.e., when you want to commit, you'd need to checkout a branch to commit on).
If you want to create local branches that track all the remote branches, the
command you're currently using (minus the --track option) is what you need.

As for deleting a branch, the simplest way is to not push branches that you're
not going to keep. I understand what your context is, so you'll likely be
stuck with maintaining branches in your central repository.

There's not a dramatic simplification I can see in your workflow, but here's
where Git's strong-suit really kicks in: it's very, very scriptable. It would
be nearly trivial to write simple bash scripts to do most of this in one
command (you might even be able to get there with aliases).

~~~
Oatmeat
Thanks for the reply.

Regarding the push command, it currently does not allow both the --all and
--tags options to be used together (very strange).

Regarding not pushing temporary branches, this seems contrary to one of the
reasons I started using git: it makes branches cheap and easy to throw away
when you are done with them.

I can understand the way git works regarding each developer using only the
branches they are interested in, but I can't seem scale this philosophy down
to a single developer. I want all my working copies to be the same. I want new
branches to propagate. I want branch deletions to propagate.

I've thought about scripting some of this, but for some pieces I am not sure
how to proceed. Consider branch deletion. The problem here is that I can
delete the branch from the main repository, but that doesn't force deletion
for each of the clients. Instead, I would need to write a custom "git pull"
style command that I run in a working directory before I start my work. Should
this command delete all remote branches so that actual deletions are
propagated, and then "git pull" restores the remote branches which still
exist?

[edit: I've discovered that "git remote prune" will delete remote tracking
branches that are no longer in the repo]

Don't other git users have this issue? Presumably there are others who work
from more than one location and want a consistent view from each, yet I can't
seem to google for any help on these issues.

~~~
aggieben
Yeah, I realized post-facto that --all and --tags doesn't work. Alternatively,
you can list your tags with things to push, like

    
    
      git push origin master my-tag ...
    

That might also work with --all. If it does, you could get away with:

    
    
      git push --all origin my-tag
    

As for the rest...I'm not sure what your best way forward is. One way might be
simply to don't delete branches. They'll clutter the list of branches, but so
what? Just ignore them if you don't use them.

The 'git remote prune' way is probably best. Run that, and then check for
local branches that aren't tracking a remote. That's scriptable.

I don't think there's a simple and elegant answer here, because what you're
doing basically turns Git into subversion. That's pretty much unavoidable when
one is doing what you're doing.

You could be more "distributed" if you only worked on specific features or
modules (or whatever) at specific locations. Then you could just merge when
necessary instead of always having to keep your branches in sync :-)

------
gtani
BTW, here's some other cheats i've bookmarked. With 100+ commands, different
teams' workflows are significantly different.

<http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg>

<http://www.spheredev.org/wiki/Git_for_the_lazy>

<http://jan-krueger.net/development/git-cheat-sheet-take-two>

<http://www.gnome.org/~federico/misc/git-cheat-sheet.txt>

<http://home.regit.org/?page_id=32>

others?

------
dabeeeenster
Can anyone explain to me, someone who manages a small (< 10) team of
developers with an SVN repository, why I need git?

~~~
orib
Better workflow.

There are tons of times I want to try something locally without affecting the
main repository. It hurts trying to keep uncommitted experimental changes from
messing up local upstream, while still switching back to the old code to fix a
bug that affects everybody. With git's local branches, rebasing, and fast
branch switching, it's easy to keep your local, not-yet-ready changes in a
branch, and fix bugs on master, for example.

Allowing other people to pull your changes directly from your repository for
testing, without committing it, is also a big plus. "Hey, I have this fix that
I want to test before I commit it. Can you pull tag omg-git-is-awesome from my
machine and test it to make sure I didn't mess things up?"

Overall, DVCS just fits better with the way I work. Note, pretty much any DVCS
will give you similar advantages. Git's just nice because it feels fast, and
I'm just comfortable with it. Plus, stuff like rebase and bisect are sweet.

~~~
dabeeeenster
Thanks.

Actually browsing around I found this very useful:

<http://git.or.cz/course/svn.html>

~~~
gtani
[http://wincent.com/a/about/wincent/weblog/archives/2007/07/g...](http://wincent.com/a/about/wincent/weblog/archives/2007/07/git_notes.php)

short and sweet: no metadata

<http://www.newartisans.com/blog_files/diving.into.git.php>

[http://www.simplisticcomplexity.com/2008/03/05/cleanly-
migra...](http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-
subversion-repository-to-a-git-repository/)

You used to be able to call "git", no options, it would tell you how many
commands it has. "wc" says 140!

------
orib
I wrote something similar to this a while back:

<http://eigenstate.org/git-quickref.html>

The rest of the site is effectively void of information, though, although I
keep wanting to put stuff up on it. I need to get around to writing up an
Autofoo tutorial, because it's one of those big scary piles of crap that isn't
too bad (at least too bad to _use_ ) once you figure it out

~~~
gtani
Thx. i tried to add a comment that the hyphenated commands "git-clone" are
deprecated or discouraged. not sure what happend to it. Also not sure how
aggressive they'll be about removing the hyphenated commands from future
releases, google-fu on holiday today

~~~
orib
Yeah, thanks for the reminder.

That page was put up a while ago. Comments = email; that site is just plain
old static HTML + 6 lines of awk to shove in the stuff that gets duplicated
across pages (navbars, etc). I can't be arsed to do more. I'll be replacing
the -'s later on today, I think. (It's a pity. I never liked the programmable
bash completion all that much; I really preferred git-blah.)

edit: fixed the deprecated git-foo commands

------
jamongkad
Wow just to think I was actually contemplating using Git for my future
projects. Thank you!

