5 ms·

If git pull is causing problems for you, you are not using git correctly. You shouldn't be doing work on upstream branches -- that's one of the wonderful things

• hrjet 13y ago
  This is a fine suggestion for large, systematically developed projects. But for hobby projects supported by an occasional community contribution, branching everytime can be cumbersome.
  • yock 13y ago
    It really isn't. It takes almost no effort to `git checkout -b feature-branch` before an add and commit.
    • gbog 13y ago
      Except that you need to know what you will do in advance, in order to give a meaningful name to the branch, and you need to delete odds branches in order to find your way when switching, et cetera. The first point is stronger than it seems, at least for me. It is a bit like requiring a definitive title to a novel I'm starting to write before the first line is there.
      • jstclair 13y ago
        To rename: git branch -m old-name new-name Candidate branches for deletion: git branch --merged
      • Crito 13y ago
        Branches are literally just text files that contain a sha in refs/heads. The name of the file is the name of your branch. They are an incredibly lightweight concept that should never be considered the source of any sort of technical debt.
      • Cthulhu_ 13y ago
        Luckily with Git, you have infinite power with that kinda thing - at least until you push and share your code. Branching is cheap; moving commits from one branch to another is easy; creating a branch after you've done a couple commits is simple. The difficult part, I think, is on the one side realizing what power you have and how to use it, and on the other side plain discipline.
      • aqme28 13y ago
        I think that knowing what you want to do before you try to do it is a good engineering practice in its own right.
        • gbog 13y ago
          Not sure. Do you think Da Vinci sat at his table and thought "let's invent the helicopter" (with a nice unique memorable name for his work in progress)? I would rather imagine Da Vinci being supposed to draw some boring architectural work or even writing against his will to his great-grant aunt. And then a paper fell off his table, spinning away. And then I imagine Da Vinci drawing a spinning paper on the margins, and adding equations, schemas, and getting deeply inside this new project, which becomes clearer in his mind as he works on it, without ever having a name. This is exactly why I hate deciding a branch name before some tasks and I love `git add -p` which allow me to add a bucnh of unrelated things in the work tree and extract the juice later.
          • yock 13y ago
            With git you can experiment to your hearts content. Then, once you decide you have something ready to go, create the branch and commit to it. You don't have to create the branch first.
            • dllthomas 13y ago
              Or even create some branches called "experiment1", "experiment2", &c, until you figure out what it should be called.
          • yock 13y ago
            Here, $10 well spent. Watch and be enlightened. http://pragprog.com/screencasts/v-jwsceasy/source-control-made-easy http://pragprog.com/screencasts/v-jwsceasy/source-control-ma...
      • Aloisius 13y ago
        Then use git stash?
  • dasil003 13y ago
    Once you know what you're doing you don't have to branch preemptively, because it's easy to branch in an ad-hoc manner. For instance, I often develop directly on master, but if some change request comes in that needs urgent attention I simply `git branch tmp && git reset --hard origin/master`.
  • josephlord 13y ago
    I do it even on projects when I am absolutely the only developer. I can then commit away whenever I want a checkpoint in my work and merge to master when it is in a stable and sensible state. Editted to add "absolutely".
    • hrjet 13y ago
      I have tried that for personal projects, and more than once I have forgotten about a branch entirely. Imagine: I spend couple of days working on a feature, commit into a feature branch, tick it off the todo list, and after several weeks realize that I didn't merge it into master! And by now there are going to be merge conflicts. The only time I branch for personal projects is when it is going to be a truck-load of changes, which are going to be hard to forget.
  • Ygg2 13y ago
    And if you work on a large project, people will push their own development branches upstream and other people will complain there are branches there. Git pull offers very little good stuff, compared to fetch and whatever.
• tight_scientist 13y ago
  I completely agree. This is exactly my team's workflow at work. I've never had any problems using git pull in this way.
• sanderjd 13y ago
  I think this is mostly true, but a couple points: Firstly, it is actually very easy for new work to happen upstream while you're merging your work in. Now you have the same problems the OP is discussing - your git pull will merge the upstream branch in, which you don't want (if you are like the OP). The only solution to this is to fast forward to upstream and re-do the merge (hopefully faster this time, especially if you're using rerere!), which is basically what the OP is suggesting. Also, it seems to me that the OP's point is more "why using pull with the default options is considered harmful", and I think it's worth noting that the "correct" workflow you're advocating doesn't seem to be the one "advocated" by those defaults. You're saying "you shouldn't be merging upstream in, you should be merging your branch into upstream", but git pull's default behavior is precisely "merge upstream in". I think people can be forgiven for "not using git correctly" when they're using it in the way it seems to be encouraging! I'm being uncharitable to you - I know you mean "not using git in the manner I've found to work the most nicely" (and I agree with you), but I think it's worth pointing out that there a lot of git usage patterns are different than what the tool seems to point people toward.
• pjc50 13y ago
  This is the classic "if you use a prominent feature in a seemingly obvious way, then it causing problems for you is your own fault". People familiar with `svn update` or other VCS actions which synchronise a local copy with a central repository will get surprised by `git pull`.
  • asolove 13y ago
    This is the classic "I want to use a new, more powerful tool, but I'm going to rely on concepts from the old tool and not bother to learn the new one." If you're using git in this way, you should just use svn. You'll be missing out on the power of git, but you already are, and at least your tool will match your mental model of it.
    • phillmv 13y ago
      That's a false dichotomy. Matter of fact is there is no right way to use git, because the way you use git is going to change according to your organization size and complexity. The Linux kernel is a very different animal than your average rinky-dink hobby project, which is different from your ten-dev consultancy. Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works.
      • jheriko 13y ago
        > Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. that is very true imo. reverting a merge once its pushed is a real headache in git compared to mercurial and its caused me problems often enough at critical moments that i simply refuse to use git it can solve my problem but even 'experts' who like to tell me how to do it and how 'easy' it is seem to miss crucial details - the documentation is a little lacking in that area too... in short i can learn how to do it with hg from no previous knowledge so quickly that i can not worry about forgetting it. with git the overhead for learning how to perform this one task is far too great - mainly down to ultra configurability and what imo are extremely poor choices of defaults.
• Spittie 13y ago
  I agree, but I've been bitten by this more times that I would admit. Usually it's for "silly" things, like updating the readme with the online editor over GitHub (to quickly fix a type for example, when I'm not on my desktop) and then forgetting to do a "git pull" as the next thing on my local branch.
  • anentropic 13y ago
    I don't understand... I do those silly things too quite often and I've never been 'bitten' you try to push and it tells you you can't until you do a pull you do a pull, resolve conflicts if any where is the problem?
    • Spittie 13y ago
      You get those "Merge branch 'master' of github.com:Username/Repository" commits, that introduce "unnecessary nonlinearities in the history" (to quote the reply). I mean, it's not an huge problem (and that's why I still use git pull), but it does comport some kind of annoyance.
      • krisdol 13y ago
        It seems that the SO answer doesn't understand that there is a `git pull --rebase` option. It attempts to rebase local commits on top of what was fetched, and by default shows merge issues if the conflicts could not be resolved automatically. It is my default for my workflow, but I will use different merge strategy when necessary (which is almost never).
      • bronson 13y ago
        git pull --rebase would take care of those nonlinearities. In my experience, on projects with a few developers, --rebase is awesome.
    • syllogism 13y ago
      Let's say I've got a copy on my server and a copy on my laptop. I fix a typo in the README on the server, as that's the window I've got in front of me. I push the change, but don't pull it onto my laptop. I don't pull the change to my laptop. I fix a different typo, and push it. I pull down the new version on the server. I fix another typo. Now this commit has two parents: the one from the server earlier, and the new one from my laptop. Because it has two parents, it's a merge commit.
• lars 13y ago
  I think this practice tends to encourage merging code later rather than sooner, which has caused more problems in code I've worked on than anything else. With N developers, you may end up with N or more increasingly diverging branches. If feature A and feature B subtly breaks one another, neither developer A or B will catch this problem until both branches are merged into master, at which point both developers are probably convinced their code works, and may have moved on. If they had worked on the same branch, the problem would have been apparent from the moment the code was written.
  • JoeAltmaier 13y ago
    But you can't actually 'work on the same code'. You have to have a copy. And some projects are significant, not committed in a day or two. SO merging is a fact of life. And in an open-source community, as you rightly point out, nobody wants to do the dirty work. And merging is as dirty as it gets.
    • lars 13y ago
      > But you can't actually 'work on the same code'. You have to have a copy. Surely this is a little overly pedantic? The point is that you want developers A and B to work on code bases that are as close to each other as possible, so that any problem in the interaction between these developers' work is caught early. Your project doesn't need to be completed in a day or two, you just need to accept that you have a dev branch which isn't always in a shippable state (which I think is usually unproblematic).
      • JoeAltmaier 13y ago
        Which begs the question: which branch? How do you know what all the others are working on, and if you'll conflict.
  • asolove 13y ago
    If they work on the same branch, what happens if A finishes early and B is late, or abandoned as a bad idea? Instead, A and B should be on separate branches. Maintain integration environments where the feature branches are regularly merged together when each gets to the level of doneness that environment represents. The final step is to get promoted to master-candidate, where you are going to launch tomorrow unless we find a problem. If things break there, blow that away and recreate it from master, and fix your problems one integration environment lower.