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.
For that sort of work, you get exactly 4 commands to replace svn's 3 commands:
git-clone
git-commit -a
git-push
git-pull --rebase
With git, though, you tend to use it's advanced features a whole lot more. Why? I guess it's partly a cultural thing, partly a "holy crap things happen instantly" thing. It no longer hurts to use advanced features like branching, so you use them.
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)
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 :(
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.
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
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
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?
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).
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.
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 :-)
I have a similar work flow to yours and I experience many of the same problems you do with DVCS. I'm currently thinking about just using rsync to keep my development environments the same. I haven't made this move yet but, I can't think why I couldn't.
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.
1. I can commit things locally before committing them to the main repository. This allows me to commit something in a manner that separates it from all future changes, but test it for a few more days in future development before I actually push it to the main repository.
2. I can correct past commits. This means I don't have to clutter up the history with "fix typo"; I can just amend the previous commit. Obviously this isn't useful for stuff far back, but if I commit something and 2 minutes later someone points out a typo, I can fix it. A messy history makes development and bugfinding harder; git helps avoid it.
3. Git diff is formatted a bit more nicely than svn diff, IMO.
"... Can anyone explain to me, someone who manages a small (< 10) team of developers with an SVN repository, why I need git? ..."
You don't.
For revision control you can use CVS, SVN or VSS if your tastes include MS. Git was born out problems with the Linus, "the Git's" attempt to adopt BitKeeper for the Linux kernel ~ http://en.wikipedia.org/wiki/BitKeeper The only reasons I can think using Git would be if you are using Rails, developing OLPC or hacking on kernels.
The rules change of course if you are an individual hacker or a new startup as more and more software uses git. Plus you can use github.
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
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
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.)
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.