34 ms·

Git: the minimum you need to know (sorta like a cheat or nutshell)

69 points by gtani 18y ago

note that hyphenated commands are now officiall discouraged/deprecated http://article.gmane.org/gmane.comp.version-control.git/72874

orib 18y ago
I wrote something similar to this a while back: http://eigenstate.org/git-quickref.html 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 18y ago
  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 18y ago
    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
dabeeeenster 18y ago
Can anyone explain to me, someone who manages a small (< 10) team of developers with an SVN repository, why I need git?
- orib 18y ago
  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 18y ago
    Thanks. Actually browsing around I found this very useful: http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html
    - gtani 18y ago
      http://wincent.com/a/about/wincent/weblog/archives/2007/07/git_notes.php http://wincent.com/a/about/wincent/weblog/archives/2007/07/g... short and sweet: no metadata http://www.newartisans.com/blog_files/diving.into.git.php http://www.newartisans.com/blog_files/diving.into.git.php http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ http://www.simplisticcomplexity.com/2008/03/05/cleanly-migra... You used to be able to call "git", no options, it would tell you how many commands it has. "wc" says 140!
- pjhyett 18y ago
  http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8 Watch the entire thing.
- DarkShikari 18y ago
litewulf 18y ago
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.
- arthurk 18y ago
  This simple workflow is actually not that much more complicated with git: clone once, update, commit, push.
- cstejerean 18y ago
  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.
  - allenbrunson 18y ago
    i use svn, but i have never created a branch or performed a merge. i do occasionally revert back to older versions of files, and i look at the commit log a lot. svn diffs are always informative. but even if i didn't do all that stuff, svn would beat periodic tarballs. it's a great way to collaborate with others, for example.
  - litewulf 18y ago
    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)
deleted 18y ago
[deleted]
gtani 18y ago
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://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg http://www.spheredev.org/wiki/Git_for_the_lazy http://www.spheredev.org/wiki/Git_for_the_lazy http://jan-krueger.net/development/git-cheat-sheet-take-two http://jan-krueger.net/development/git-cheat-sheet-take-two http://www.gnome.org/~federico/misc/git-cheat-sheet.txt http://www.gnome.org/~federico/misc/git-cheat-sheet.txt http://home.regit.org/?page_id=32 http://home.regit.org/?page_id=32 others?
Oatmeat 18y ago
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 18y ago
  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 18y ago
    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.
jamongkad 18y ago
Wow just to think I was actually contemplating using Git for my future projects. Thank you!

69 points by gtani 18y ago

note that hyphenated commands are now officiall discouraged/deprecated http://article.gmane.org/gmane.comp.version-control.git/72874

orib 18y ago

I wrote something similar to this a while back: http://eigenstate.org/git-quickref.html 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 18y ago
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 18y ago
  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

dabeeeenster 18y ago

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

orib 18y ago
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 18y ago
  Thanks. Actually browsing around I found this very useful: http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html
  - gtani 18y ago
    http://wincent.com/a/about/wincent/weblog/archives/2007/07/git_notes.php http://wincent.com/a/about/wincent/weblog/archives/2007/07/g... short and sweet: no metadata http://www.newartisans.com/blog_files/diving.into.git.php http://www.newartisans.com/blog_files/diving.into.git.php http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ http://www.simplisticcomplexity.com/2008/03/05/cleanly-migra... You used to be able to call "git", no options, it would tell you how many commands it has. "wc" says 140!
pjhyett 18y ago
http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8 Watch the entire thing.
DarkShikari 18y ago

litewulf 18y ago

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.

arthurk 18y ago
This simple workflow is actually not that much more complicated with git: clone once, update, commit, push.
cstejerean 18y ago
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.
- allenbrunson 18y ago
  i use svn, but i have never created a branch or performed a merge. i do occasionally revert back to older versions of files, and i look at the commit log a lot. svn diffs are always informative. but even if i didn't do all that stuff, svn would beat periodic tarballs. it's a great way to collaborate with others, for example.
- litewulf 18y ago
  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)

deleted 18y ago

[deleted]

gtani 18y ago

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://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg http://www.spheredev.org/wiki/Git_for_the_lazy http://www.spheredev.org/wiki/Git_for_the_lazy http://jan-krueger.net/development/git-cheat-sheet-take-two http://jan-krueger.net/development/git-cheat-sheet-take-two http://www.gnome.org/~federico/misc/git-cheat-sheet.txt http://www.gnome.org/~federico/misc/git-cheat-sheet.txt http://home.regit.org/?page_id=32 http://home.regit.org/?page_id=32 others?

Oatmeat 18y ago

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 18y ago
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 18y ago
  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.

jamongkad 18y ago

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