Use git from the command line (not a GUI)
blog.jenius.me
blog.jenius.me
I don't understand. If I and someone else are collaborating, wouldn't we each be working in our own repository, and then pushing and pulling either between the repositories, or through a third repository?
How does the interface one of uses to our repository affect the work of the other in his repository?
I have never collaborated that way, when I work with other devs (which I do full time), we make a project repo and push and pull to that repo. If we are working on specific features, we use branches. I have never heard of or seen the multiple repo approach, so I can't comment on that.
When I work with other people, we often come over to each others' computers to talk something out, take a look at a merge conflict, or debug things. When this is the case, it's a lot easier when the people that are working together have similar setups or use similar tools - this way it's easy to sit down at their computer and take a look at things.
Do you make commits directly to the remote repo, or do you have local repos that you push and pull to the remote from?
Edit: Sorry apparently this wasn't clear. I make commits to a local repo and push to github. The local and github repos are rarely out of sync.
What commands do you use to accomplish this?
This is correct. The repo doesn't care what the individual users are using, and it can't tell. On the flip side, this was never something I disagreed with. I was saying that I often work with other devs in person and we will frequently go over to each others' computer to talk something out, debug something, etc. In this aspect, it's easier to use similar tools.
If you always work in complete isolation, disregard this part of the article. I just assumed that most people don't.
By definition collaborative git is always multiple repo (unless you're doing something weird like all using the same working directory in a network share, but that'd defeat most of the purpose of git and be a terrible idea). You work on your own repo, and then push changes when you're done.
tzs is right in that what tool I use to manage my local repo is irrelevant to the operation of the repository. Git doesn't mind what tool I used. When it does matter how you're committing is if you're discussing doing things in git - it can cause confusion when someone's trying to find a GUI menu to do something.
The remote server argument's also valid, and probably the best reason to encourage people to use the command line. I've never found a git gui that was better than the command line, and the command line is the de-facto subject of tutorials. I agree with your overall theme of "use the command line".
On the other hand, the Github for Mac app is harmful because it hides almost all of git's features and replaces them with an SVN-like workflow. This lowers the barrier to entry and simplifies the common case, but if you're not going to Git like a DVCS then just don't use a DVCS.
My take: Git's power is not in its CLI tools. It is in its unique model of trees of commits/refs, and the concept of working tree+index+history. Good GUIs make you comfortable with this model. Bad GUIs hide it from you.
I still stand by my point though - you should know how to use git from command line. If you know it well and you want to try something else, go for it. But I think it's a very bad idea to learn only a gui and not be proficient with command line git.
It doesn't matter really which GUI we're talking about. You should learn command line git anyway. That was the point of this article.
Nope, not planning on doing so. I just wanted a context in which to evaluate your stance.
HN is weird in that people only up vote opinionated articles but then berate you in the comments for being "biased". Good on you for contributing your opinion. =]
Bottom line: use the tool that makes sense. Don't be overly pedantic.
Of course to each his own, and everyone has their own style - I'm trying to suggest a best approach for learning developers. Would you suggest that learning devs use gitx? If so, I'd love to see an article about it!
What I do agree wholeheartedly with is using the Git CLI for tree operations. Knowing what you're doing with `git pull`, or knowing when to rebase as opposed to a merge is incredibly useful when using git, and ultimately makes your usage of git more effective.
In short, I advocate using some sort of interface (GitX, fugitive.vim) for staging, and possible committing, but the git CLI should be used for almost everything else (except submodules, which seem to require an unholy mix of git and normal file operations).
This is why I decided to use git from the command line. I can't hope to understand everything git can/cannot do if I stick to a GUI interface. Sure, this means I have to spend more time googling but from my point of view, it's worth it (it's revision control so it's the last place I want surprises).
That said, I don't find the article's other points particularly compelling. The very last sentence seems to undermine the rest of the article [paraphrasing: "You should always use git from the command line! Heck, I'll even help you with it! But only if you've googled first."]
The GUI made everything intuitive by leading me through common tasks, instead of forcing me to memorize what is related to what. It showed file diffs on a bottom pane when I click on them, revealing that what Git cares about are changes to files. It showed a commit message draft on the right, indicating that what I am always working towards is a commit. The tabs clearly divided the workflow into two rough modes: making changes and examining history. These visual cues helped me understand the concepts within Git. Tower is also faster at staging only certain lines of a change, letting me use the mouse to point to those lines rather than going through the git add -i workflow of "split this hunk, split it again, yes stage that one, no don't stage that one", etc.
Now that I understand Git's concepts, I can use and have used Git on the command-line, but for now I use the GUI whenever possible. I still don't feel confident enough in my knowledge of all of Git's details, such as the commands to resolve merge conflicts, so the GUI's continued guidance is reassuring. Perhaps after I've used it actively for a few more months, a workflow like jenius describes at the end, using custom aliases for commands I use often, will be better for me.
I would still advocate moving as hard towards cli as you can though. Having someone on deck to help you out if you're confused is key - it seems like you are using the gui for that instead of an actual person right now, which is interesting.
As far as I see it, it's the most accessible and well designed, which is the entire purpose of building a gui over something - to make it more accessible and easy to handle. But what is the best one in your opinion?
The only situation in which I could claim to agree with this is if there is a super hard core and time intensive task where there is no room for learning at all, and all that matters is that a product gets out as fast as humanly possible. If that's your situation and you can't handle command line, so be it go for a GUI. But if your free time I still think you should be practicing command line.
People /should/ know how to use the command line, even if they prefer to use other tools daily, but often it's not practical to force people to use it.
I also didn't say that I am a great programmer, that every great programmer has to do these things, or that you have to do them. This is a push in the right direction for people learning to be developers, and I still think it's important to at least know the basics of vim, enough to get around.
My advice, if you're the sort of person that uses vim then stick with the command line. Otherwise download a GUI and spend the time learning something useful instead.
reply to op: A gui which covers 80% cases is way better than doing everything from command line, saves a lot of cognitive overload. If it's one of those 20% cases, ya, please you can fall back to command line. No, guis are not developed for those 20% percent cases; even if they did, they usually are painful like commandline as well.
I would argue that revision control is too important to try and hide the details from its users. I imagine that a GUI that only accounts for best-case-scenarios and 90% tasks is a great way to shoot yourself in the foot when your repo gets into a dangerous state.