9 ms·

My Common Git Workflow

113 points by knowtheory 16y ago

knowtheory 16y ago
As a git user, i do really think it's critical that people think about their workflows and talk over what strategy they're going to use w/ their fellow committers. There's (definitely) more than one way to do it with Git, so it's best to read up on how other people use it.
gorm 16y ago
Comparing git with svn doesn't make sense. It's two different tools with different use-cases and a transition from svn to git only make sense for some (motivated) teams.
- wycats 16y ago
  While there are quite a few different workflows, there are a number of similar operations (get a repository, get updates from a remote, push changes to the remote). My point was not to compare git (as a whole) to subversion, it was to demonstrate how the tools handle those operations. I think it's reasonable for people who are moving from subversion to git to expect that commands for these operations will exist (and they, of course do). Finally, even in my limited description, I managed to demonstrate a benefit of git (namely, that the slightly different default workflow handles the common problem of rollback much more elegantly)
- j_baker 16y ago
  I think it can be useful to compare git and svn. True, it is comparing apples and oranges. However, that's a reasonable thing to do when you're considering migrating from apples to oranges.
- nfnaaron 16y ago
  What are the different use cases? I would have thought they're both basically version control, since one of the decisions in version control is whether to use svn or git or something else. So what use cases are svn appropriate for (and not git), and what use cases are git appropriate for (and not svn)?
buro9 16y ago
This is incredibly timely and I for one appreciate the post. I'm just moving myself and a team from past-experience of SVN into the world of git. None of us know git, but we're all vaguely aware of it. Unfortunately the place we are at requires us to integrate with ClearCase and SVN, and to make matters worse we're all on Macs and Linux for which ClearCase tools don't appear to exist. Our proposed solution to bring sanity to this is to use git with git-cc and git-svn to act as bridges to the legacy systems, whilst putting all new work natively into git. Now... I'll be the first to admit that we're not full of confidence about this as it's the fear of the unknown, so if anyone else has solid advice on how to work with git and workflows and integrating into existing legacy systems I would be keen to hear it.
- fragmede 16y ago
  Are you trying to integrate ClearCase with svn (with git as the go-between bridge)? Thats a bit more than I've had to deal with (though I've heard of perforce->(git)->svn being done). As for git-svn itself, I'll say what I said on the other thread - what finally got me to switch is that with git-svn, my local copy is a real live Git repo. Which means the code I write, my actual work, is all still there and accesible via standard Git commands that I can look up. The fix for the worst-case scenario? I do a fresh svn checkout to a new directory, and I do git checkout, I copy the files out, I do an svn commit of that version of files. Far from ideal, but knowing that I could recover from worst the system could throw at me, put me quite at ease. (Yeah, yeah git svn dcommit, but we're talking about a fearsome worst-case scenario.)
  - buro9 16y ago
    We all have experience with SVN, and that's been our preferred setup in our prior roles. Here, ClearCase is used by the back end services team and they use that to push things through the different environments too. So at some level we need to access their code, and to contribute code to their repository. SVN is used by other rogue developers to try and avoid ClearCase... very understandable really. So we also need to get some of their code and contribute to them. So neither holds all knowledge, and IBM doesn't provide ClearCase software for Mac OS X. So what we're looking at is a git-cc bridge to go in that direction, installed on a Windows box and then allowing us internally to use git to work and then just to periodically push upstream from the Win box. And as we'll be using git, it seems desirable (though not required) to use the git-svn bridge if that works well as then we only need to use the one tool daily. I've read a lot about how to setup the CC2Git bridge, and no solution seems great but all appear to be adequate enough for it to work at some level. I haven't checked out git-svn too much but what I had read was mostly good. The concerns we have are once we're in the git world, how do you use the thing? I've seen a lot mentioning the importance of understanding git and workflows, but not a great deal describing git for SVN users and then showing simple to follow guides that not just communicate the commands, but also a nice and solid workflow.
ivenkys 16y ago
"is that there are a set of high-level version control operations that you’d expect git to be able to handle in simple cases without a lot of fuss." True. git is a "particular kind of" swiss knife of Version Control - tonnes of options, not all of them intuitive but extremely powerful and useful if you like to work in the git way. I, for one am a bit surprised about all this noise on workflows of Version Control , you use what you think is best suited to you and your team. Its as useful as a language war , not all languages are equal but you use what suits your use-case and what you are most comfortable with. End of.
- lincolnq 16y ago
  The reason language and version control wars exist is because these are the mechanisms by which developers interoperate. It is worthwhile for me to convince you to use Git instead of Subversion, or Python instead of C++, because I might one day work with you and have to use your tools. If there's consensus about what the best tools are, then I am less likely to experience pain when moving. If we were talking about which editor to use, I am rarely bound to use a certain editor based on the team I'm on, so that's why editor wars are, indeed, largely noise.
  - ivenkys 16y ago
    "I might one day work with you and have to use your tools. If there's consensus about what the best tools are, then I am less likely to experience pain when moving." Your point though correct in the abstract misses one crucial piece of information . Is it the best tool for the job i.e. it is not simply enough to say Use git or Python or <foo> etc. The context around it is very important. For e.g. in my current team everyone is comfortable using git as we have a largely de-centralised development model. On the other hand in my previous role it was a very centralised - one true copy of source code model - hence SVN. The comparisons and wars that come out are devoid of this context and just say , i use this and therefore you should do. My point is that there is no one true way and attempting to posit that even though interesting is largely futile.
    - lincolnq 16y ago
mhb 16y ago
I'm using git on AWS running Ubuntu Hardy. Is there a GUI tool I can use to look at my repository from a remote Windows box (where I use SecureCRT to access the instance)?
- morbidkk 16y ago
  smartGIT
codesink 16y ago
There's a free book about git available at http://progit.org/book/ http://progit.org/book/ Both the basics and advanced topics are clearly discussed.
- morbidkk 16y ago
  yes I agree. this was clear and easy to understand. Now I keep http://cheat.errtheblog.com/s/git http://cheat.errtheblog.com/s/git this open all the time for easy reference
mark_l_watson 16y ago
I like Yehuda's advice to use --rebase. I'll have to try that. I used to really like svn, but after using git for about a year I am now feeling some cognitive dissonance using svn on a customer project. Great tools are better than good tools.
- knowtheory 16y ago
  I understand why --rebase isn't the default, but in the overwhelming majority of cases, you want to --rebase when pulling. I always tell newbies that they should default to --rebasing.
  - acqq 16y ago
    Why isn't --rebase default? Can anybody explain what it actually does and why it's not default, man pages are not clear to me? Every thing is explained by referring to a bunch of other things and there's not a trace of a simple explanation.
    - kemiller 16y ago
      I can't comment on the motivations of the maintainers, but in my experience normal merges can handle more conflicts cases smoothly than rebase. Rebase is also controversial because technically it's rewriting history. I think for the special case of pulling from remote, though, that the tradeoffs are often worth it, but nevertheless, merge is the safer default.
      - knowtheory 16y ago
        Not all history is sacrosanct. REMOTE history is absolutely sacrosanct (A remote being any repository that someone is going to pull from), but you can do whatever you like with your local repository, so long as you only push from it.
        acqq 16y ago
        OK, but I believe remote repo is there only to be pushed to, so then is there any example of benefit of pull without --rebase if the pull is anyway only done locally? http://progit.org/book/ch3-6.html http://progit.org/book/ch3-6.html Says " If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble." but not how that can happen at all, provided you always "pull --rebase" and then "push", and if that can happen at all, then what to do.
vlucas 16y ago
I moved all my projects and code over to git from svn about a year ago. My workflow has improved tremendously as a result - especially working in larger teams. That being said, resolving conflicts in git has almost always been more difficult and counter-intuitive than resolving conflicts in SVN. With git, you have to learn the "right way" to do it, which typically involves several steps or a "git reset --hard origin". I can understand the frustration coming from the guy in the linked post that this post is a response to.
acqq 16y ago
OK now I know about: "git pull --rebase" If only somebody would explain what this really does! The man pages are not helpful! git-pull(1) Manual Page says: "--rebase: Instead of a merge, perform a rebase after fetching. If there is a remote ref for the upstream branch, and this branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. To make this the default for branch <name>, set configuration branch.<name>.rebase to true." Oh how clear. So let's try git-rebase: "If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch. All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD (or git log HEAD, if --root is specified). The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as git reset --hard <upstream> (or <newbase>). ORIG_HEAD is set to point at the tip of the branch before the reset. The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped)." I'm lost! Now can anybody explain so nice like Yehuda did about the workflow, what and why that git pull did "wrong", and what the hell is that that "--rebase" does "right." Especially as here and there "--rebase" is described as something that "doesn't keep history" and therefore "bad." Note that I put "bad" "wrong" and "right" in quotes. I know that's all relative, I just want to get some simple explanation what's going on without reading "recursion see recursion" man pages! Thanks in advance!
- mgrouchy 16y ago
  I don't think "git pull" does anything particularly incorrect. Its just that when you have merge issues with a git pull you have to resolve all merge issues at the one time(as in resolve all changes all together). Someone can correct me if I am wrong, but a "git pull --rebase" will put all your current local commits aside and then pull everything from wherever you are pulling, applies those changes to the tree without your local changes, then applies all your changes in order one by one, until you are current with both the remote and local changes. If there is a problem with a merge on one of your applied changes, your rebase pauses , you fix the conflict as you would normally and then continue your rebase(as outlined in the article). Essentially the rebase takes all your changes and applies them in order on top of the changes you are pulling. Once again, if I made any mistakes in this explanation, someone please correct me.
theBobMcCormick 16y ago
My two favorite resources for getting started with git: 1) Using Git with a central repository: http://toroid.org/ams/git-central-repo-howto http://toroid.org/ams/git-central-repo-howto 2) A succesful Git branching model: http://nvie.com/git-model http://nvie.com/git-model

113 points by knowtheory 16y ago

As a git user, i do really think it's critical that people think about their workflows and talk over what strategy they're going to use w/ their fellow committers. There's (definitely) more than one way to do it with Git, so it's best to read up on how other people use it.

gorm 16y ago

Comparing git with svn doesn't make sense. It's two different tools with different use-cases and a transition from svn to git only make sense for some (motivated) teams.

wycats 16y ago
While there are quite a few different workflows, there are a number of similar operations (get a repository, get updates from a remote, push changes to the remote). My point was not to compare git (as a whole) to subversion, it was to demonstrate how the tools handle those operations. I think it's reasonable for people who are moving from subversion to git to expect that commands for these operations will exist (and they, of course do). Finally, even in my limited description, I managed to demonstrate a benefit of git (namely, that the slightly different default workflow handles the common problem of rollback much more elegantly)
j_baker 16y ago
I think it can be useful to compare git and svn. True, it is comparing apples and oranges. However, that's a reasonable thing to do when you're considering migrating from apples to oranges.
nfnaaron 16y ago
What are the different use cases? I would have thought they're both basically version control, since one of the decisions in version control is whether to use svn or git or something else. So what use cases are svn appropriate for (and not git), and what use cases are git appropriate for (and not svn)?

buro9 16y ago

This is incredibly timely and I for one appreciate the post. I'm just moving myself and a team from past-experience of SVN into the world of git. None of us know git, but we're all vaguely aware of it. Unfortunately the place we are at requires us to integrate with ClearCase and SVN, and to make matters worse we're all on Macs and Linux for which ClearCase tools don't appear to exist. Our proposed solution to bring sanity to this is to use git with git-cc and git-svn to act as bridges to the legacy systems, whilst putting all new work natively into git. Now... I'll be the first to admit that we're not full of confidence about this as it's the fear of the unknown, so if anyone else has solid advice on how to work with git and workflows and integrating into existing legacy systems I would be keen to hear it.

fragmede 16y ago
Are you trying to integrate ClearCase with svn (with git as the go-between bridge)? Thats a bit more than I've had to deal with (though I've heard of perforce->(git)->svn being done). As for git-svn itself, I'll say what I said on the other thread - what finally got me to switch is that with git-svn, my local copy is a real live Git repo. Which means the code I write, my actual work, is all still there and accesible via standard Git commands that I can look up. The fix for the worst-case scenario? I do a fresh svn checkout to a new directory, and I do git checkout, I copy the files out, I do an svn commit of that version of files. Far from ideal, but knowing that I could recover from worst the system could throw at me, put me quite at ease. (Yeah, yeah git svn dcommit, but we're talking about a fearsome worst-case scenario.)
- buro9 16y ago
  We all have experience with SVN, and that's been our preferred setup in our prior roles. Here, ClearCase is used by the back end services team and they use that to push things through the different environments too. So at some level we need to access their code, and to contribute code to their repository. SVN is used by other rogue developers to try and avoid ClearCase... very understandable really. So we also need to get some of their code and contribute to them. So neither holds all knowledge, and IBM doesn't provide ClearCase software for Mac OS X. So what we're looking at is a git-cc bridge to go in that direction, installed on a Windows box and then allowing us internally to use git to work and then just to periodically push upstream from the Win box. And as we'll be using git, it seems desirable (though not required) to use the git-svn bridge if that works well as then we only need to use the one tool daily. I've read a lot about how to setup the CC2Git bridge, and no solution seems great but all appear to be adequate enough for it to work at some level. I haven't checked out git-svn too much but what I had read was mostly good. The concerns we have are once we're in the git world, how do you use the thing? I've seen a lot mentioning the importance of understanding git and workflows, but not a great deal describing git for SVN users and then showing simple to follow guides that not just communicate the commands, but also a nice and solid workflow.

ivenkys 16y ago

"is that there are a set of high-level version control operations that you’d expect git to be able to handle in simple cases without a lot of fuss." True. git is a "particular kind of" swiss knife of Version Control - tonnes of options, not all of them intuitive but extremely powerful and useful if you like to work in the git way. I, for one am a bit surprised about all this noise on workflows of Version Control , you use what you think is best suited to you and your team. Its as useful as a language war , not all languages are equal but you use what suits your use-case and what you are most comfortable with. End of.

lincolnq 16y ago
The reason language and version control wars exist is because these are the mechanisms by which developers interoperate. It is worthwhile for me to convince you to use Git instead of Subversion, or Python instead of C++, because I might one day work with you and have to use your tools. If there's consensus about what the best tools are, then I am less likely to experience pain when moving. If we were talking about which editor to use, I am rarely bound to use a certain editor based on the team I'm on, so that's why editor wars are, indeed, largely noise.
- ivenkys 16y ago
  "I might one day work with you and have to use your tools. If there's consensus about what the best tools are, then I am less likely to experience pain when moving." Your point though correct in the abstract misses one crucial piece of information . Is it the best tool for the job i.e. it is not simply enough to say Use git or Python or <foo> etc. The context around it is very important. For e.g. in my current team everyone is comfortable using git as we have a largely de-centralised development model. On the other hand in my previous role it was a very centralised - one true copy of source code model - hence SVN. The comparisons and wars that come out are devoid of this context and just say , i use this and therefore you should do. My point is that there is no one true way and attempting to posit that even though interesting is largely futile.
  - lincolnq 16y ago

mhb 16y ago

I'm using git on AWS running Ubuntu Hardy. Is there a GUI tool I can use to look at my repository from a remote Windows box (where I use SecureCRT to access the instance)?

morbidkk 16y ago
smartGIT

codesink 16y ago

There's a free book about git available at http://progit.org/book/ http://progit.org/book/ Both the basics and advanced topics are clearly discussed.

morbidkk 16y ago
yes I agree. this was clear and easy to understand. Now I keep http://cheat.errtheblog.com/s/git http://cheat.errtheblog.com/s/git this open all the time for easy reference

mark_l_watson 16y ago

I like Yehuda's advice to use --rebase. I'll have to try that. I used to really like svn, but after using git for about a year I am now feeling some cognitive dissonance using svn on a customer project. Great tools are better than good tools.

knowtheory 16y ago
I understand why --rebase isn't the default, but in the overwhelming majority of cases, you want to --rebase when pulling. I always tell newbies that they should default to --rebasing.
- acqq 16y ago
  Why isn't --rebase default? Can anybody explain what it actually does and why it's not default, man pages are not clear to me? Every thing is explained by referring to a bunch of other things and there's not a trace of a simple explanation.
  - kemiller 16y ago
    I can't comment on the motivations of the maintainers, but in my experience normal merges can handle more conflicts cases smoothly than rebase. Rebase is also controversial because technically it's rewriting history. I think for the special case of pulling from remote, though, that the tradeoffs are often worth it, but nevertheless, merge is the safer default.
    - knowtheory 16y ago
      Not all history is sacrosanct. REMOTE history is absolutely sacrosanct (A remote being any repository that someone is going to pull from), but you can do whatever you like with your local repository, so long as you only push from it.
      - acqq 16y ago
        OK, but I believe remote repo is there only to be pushed to, so then is there any example of benefit of pull without --rebase if the pull is anyway only done locally? http://progit.org/book/ch3-6.html http://progit.org/book/ch3-6.html Says " If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble." but not how that can happen at all, provided you always "pull --rebase" and then "push", and if that can happen at all, then what to do.

vlucas 16y ago

I moved all my projects and code over to git from svn about a year ago. My workflow has improved tremendously as a result - especially working in larger teams. That being said, resolving conflicts in git has almost always been more difficult and counter-intuitive than resolving conflicts in SVN. With git, you have to learn the "right way" to do it, which typically involves several steps or a "git reset --hard origin". I can understand the frustration coming from the guy in the linked post that this post is a response to.

acqq 16y ago

OK now I know about: "git pull --rebase" If only somebody would explain what this really does! The man pages are not helpful! git-pull(1) Manual Page says: "--rebase: Instead of a merge, perform a rebase after fetching. If there is a remote ref for the upstream branch, and this branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. To make this the default for branch <name>, set configuration branch.<name>.rebase to true." Oh how clear. So let's try git-rebase: "If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch. All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD (or git log HEAD, if --root is specified). The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as git reset --hard <upstream> (or <newbase>). ORIG_HEAD is set to point at the tip of the branch before the reset. The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped)." I'm lost! Now can anybody explain so nice like Yehuda did about the workflow, what and why that git pull did "wrong", and what the hell is that that "--rebase" does "right." Especially as here and there "--rebase" is described as something that "doesn't keep history" and therefore "bad." Note that I put "bad" "wrong" and "right" in quotes. I know that's all relative, I just want to get some simple explanation what's going on without reading "recursion see recursion" man pages! Thanks in advance!

mgrouchy 16y ago
I don't think "git pull" does anything particularly incorrect. Its just that when you have merge issues with a git pull you have to resolve all merge issues at the one time(as in resolve all changes all together). Someone can correct me if I am wrong, but a "git pull --rebase" will put all your current local commits aside and then pull everything from wherever you are pulling, applies those changes to the tree without your local changes, then applies all your changes in order one by one, until you are current with both the remote and local changes. If there is a problem with a merge on one of your applied changes, your rebase pauses , you fix the conflict as you would normally and then continue your rebase(as outlined in the article). Essentially the rebase takes all your changes and applies them in order on top of the changes you are pulling. Once again, if I made any mistakes in this explanation, someone please correct me.

theBobMcCormick 16y ago

My two favorite resources for getting started with git: 1) Using Git with a central repository: http://toroid.org/ams/git-central-repo-howto http://toroid.org/ams/git-central-repo-howto 2) A succesful Git branching model: http://nvie.com/git-model http://nvie.com/git-model