Re: [git-users] Branches and workflow
Thanks Yawar That looks good. Roddie On 26/05/2013 06:23, Yawar Amin wrote: Hi Roddie, On 2013-05-25 10:50, Roddie Grant wrote: Thank you Alex and Paul. It's been useful to hear the pros and cons. I'm thinking of trying a front end (perhaps Tower) to see if that makes atomic commits easier. I wonder if you've looked at `git gui', the graphical commit tool that comes with standard git. It makes it pretty easy to stage specific files or portions of a file for a commit. Not only that, it's lightweight so you can open it, do some staging, and exit multiple times, really fast, and drop down to the command line any time. Give it a shot the next time you have some unstaged changes: $ git gui HTH, Yawar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Branches and workflow
Thank you Alex and Paul. It's been useful to hear the pros and cons. I'm thinking of trying a front end (perhaps Tower) to see if that makes atomic commits easier. Roddie On 24/05/2013 15:46, Alex Lewis wrote: I'd agree branching is all that and should be the way to do development, it's more of a question of /how many/ branches you go with and being sensible about it. As your branch count proliferates then it can become more complicated to keep track of what is going on, what's being done where, etc. I'm not saying it's difficult to pull things back into line or clean up the branches once you know what you want to achieve and Git is incredible, if not sometimes almost magical, at doing that. The point is really that you have to find the branching model that fits your development process and strikes the balance between time spent in the VCS compared to getting things done and striking that balance sometimes takes a little thought and practice. You may find that as you become more proficient and comfortable with Git and branching that you would benefit from some extra branches, if so then get branching. It's all about experimentation and finding out what works for you and its a true testament to Git that it can lend itself to so many situations, to be so flexible and versatile. On Friday, May 24, 2013 3:16:37 PM UTC+1, Paul Smith wrote: On Wed, 2013-05-22 at 20:02 +0100, Roddie wrote: This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do? I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in. I've read the replies here but unless I'm misunderstanding the problem they seem more complex than necessary. Yes, of course, ideally in the real world you'd have perfect foresight and every change would be self-contained and made on an individual branch and you can just use git merge to pull them together. But life is not perfect, and for sure foresight is not perfect. Suggesting that you can't use branches unless you gain such foresight, or that it's more painful to branch than not in the real world, is doing branching (and Git) a disservice. The first thing to do is get into the habit of making individual commits that constitute single, relatively atomic changes. It's not always easy to retrain yourself but it will pay off big-time. This is made a LOT easier if you have a decent front-end for Git: if you use Emacs I can't recommend magit enough for this. With the right front-end, creating commits is trivial; it will even let you choose individual patch hunks to commit while leaving the rest of the file for later commits. You can make lots of changes, then go through later and commit them in parts. If you've done that, then if you decide you need one of those commits on another branch, you can use the git cherry-pick command to trivially grab a commit from another branch and apply it to your current branch. But what if, for whatever reason, you just want the contents of a file or two from another branch, but not an entire commit? It's trivial; see this Git tip: http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ (TL;DR: use git checkout otherbranch file1 file2 ...) What if you only want parts of the other file, or the other file is changed locally so you want to merge it, not just replace it? This is also trivial, see this SO discussion (a shame no one accepted the answer :-/): http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits (TL;DR: use git checkout --patch otherbranch file1 file2 ...) Upshot: branches definitely _ARE_ all that and you should be using them as much as possible. They do not have any problems whatsoever handling the complexity of the real world. Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit
Re: [git-users] Branches and workflow
I'd agree branching is all that and should be the way to do development, it's more of a question of *how many* branches you go with and being sensible about it. As your branch count proliferates then it can become more complicated to keep track of what is going on, what's being done where, etc. I'm not saying it's difficult to pull things back into line or clean up the branches once you know what you want to achieve and Git is incredible, if not sometimes almost magical, at doing that. The point is really that you have to find the branching model that fits your development process and strikes the balance between time spent in the VCS compared to getting things done and striking that balance sometimes takes a little thought and practice. You may find that as you become more proficient and comfortable with Git and branching that you would benefit from some extra branches, if so then get branching. It's all about experimentation and finding out what works for you and its a true testament to Git that it can lend itself to so many situations, to be so flexible and versatile. On Friday, May 24, 2013 3:16:37 PM UTC+1, Paul Smith wrote: On Wed, 2013-05-22 at 20:02 +0100, Roddie wrote: This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do? I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in. I've read the replies here but unless I'm misunderstanding the problem they seem more complex than necessary. Yes, of course, ideally in the real world you'd have perfect foresight and every change would be self-contained and made on an individual branch and you can just use git merge to pull them together. But life is not perfect, and for sure foresight is not perfect. Suggesting that you can't use branches unless you gain such foresight, or that it's more painful to branch than not in the real world, is doing branching (and Git) a disservice. The first thing to do is get into the habit of making individual commits that constitute single, relatively atomic changes. It's not always easy to retrain yourself but it will pay off big-time. This is made a LOT easier if you have a decent front-end for Git: if you use Emacs I can't recommend magit enough for this. With the right front-end, creating commits is trivial; it will even let you choose individual patch hunks to commit while leaving the rest of the file for later commits. You can make lots of changes, then go through later and commit them in parts. If you've done that, then if you decide you need one of those commits on another branch, you can use the git cherry-pick command to trivially grab a commit from another branch and apply it to your current branch. But what if, for whatever reason, you just want the contents of a file or two from another branch, but not an entire commit? It's trivial; see this Git tip: http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ (TL;DR: use git checkout otherbranch file1 file2 ...) What if you only want parts of the other file, or the other file is changed locally so you want to merge it, not just replace it? This is also trivial, see this SO discussion (a shame no one accepted the answer :-/): http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits (TL;DR: use git checkout --patch otherbranch file1 file2 ...) Upshot: branches definitely _ARE_ all that and you should be using them as much as possible. They do not have any problems whatsoever handling the complexity of the real world. Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Branches and workflow
On 22/05/2013 20:24, Magnus Therning wrote: On Wed, May 22, 2013 at 08:02:50PM +0100, Roddie wrote: I'm fine with Git and branches when it's simple, but as soon as things get a little complicated, I get baffled and frustrated. snip This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. snip BTW, I'm familiar with the diagram from nvie.com, but it doesn't answer this problem - its feature branches are completely independent until merged into the develop branch. In my experience the world is not that neat and tidy. I'd appreciate any advice. With the risk of sounding a bit patronising it seems you've forgotten the other side of the coin -- merging. If, and this is a big if, your changes to your work on the home page template file is contained in self-contained patches, then you can merge those changes from 'memlogin' to 'adverts'. If that's not possible you might be facing the risk of having to progressing 'memlogin' to a point where it can be deployed. Merge it into 'master' and then restart 'adverts' from there. I think feature branches are the bee's knees too, but they aren't as easy as in all the examples one reads -- they require some up-front thinking. In particular it's problematic when dependencies between features emerge during development. In essence you then only have two options, finish them in order of dependency, A then B, or don't. If you don't you'll probably end up hacking up certain aspects of B just to make it good enough, then when A is finished you can revisit B. Unfortunately not an answer to What should I do? Because that's really only an answer you, or your project manager, can answer. But hopefully it aids in thinking about the trade-offs of your options. /M Thanks Magnus. That's really reassuring to know that I'm not missing that point and branches aren't necessarily easy. I do use merging, but avoiding dependencies might result in so much merging that there is no point in having separate branches. It's a good point about there being trade-offs to consider. Thanks Roddie -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Branches and workflow
On Wed, May 22, 2013 at 08:02:50PM +0100, Roddie wrote: I'm fine with Git and branches when it's simple, but as soon as things get a little complicated, I get baffled and frustrated. For example... I've set up a members' log in system for a website, including a log-in form on the home page. The template for the home page was amended in the process. That's all committed on branch memlogin. That work is on hold because I have to get adverts on the home page, and I've made a new branch - adverts. This was branched from the master branch, so does not include any of the work on memlogin. But I need the revised home page template file because the log-in form affects the position of the adverts. This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do? I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in. BTW, I'm familiar with the diagram from nvie.com, but it doesn't answer this problem - its feature branches are completely independent until merged into the develop branch. In my experience the world is not that neat and tidy. I'd appreciate any advice. With the risk of sounding a bit patronising it seems you've forgotten the other side of the coin -- merging. If, and this is a big if, your changes to your work on the home page template file is contained in self-contained patches, then you can merge those changes from 'memlogin' to 'adverts'. If that's not possible you might be facing the risk of having to progressing 'memlogin' to a point where it can be deployed. Merge it into 'master' and then restart 'adverts' from there. I think feature branches are the bee's knees too, but they aren't as easy as in all the examples one reads -- they require some up-front thinking. In particular it's problematic when dependencies between features emerge during development. In essence you then only have two options, finish them in order of dependency, A then B, or don't. If you don't you'll probably end up hacking up certain aspects of B just to make it good enough, then when A is finished you can revisit B. Unfortunately not an answer to What should I do? Because that's really only an answer you, or your project manager, can answer. But hopefully it aids in thinking about the trade-offs of your options. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgp9vP1eZei5A.pgp Description: PGP signature
Re: [git-users] Branches and workflow
If you start you new branch without the content of changes from other branches, I suppose there is the possibility to use git rebase to change your mind later on. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/i-DBuTasVxEJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Branches and workflow
A questions about branches and workflow... I've done several weeks' work on a website feature, with the code all on the dosomething branch. This code has now been transferred to my test server for the customer to test. So the branch is not finished and there will almost certainly be more work done on it, even if just refinements. While the customer is testing that feature I need to start work on the next, and my instinct was to create a new branch. But where should it branch from? If I branch at the point where dosomething was started none of the quite-far-reaching work done in the last few weeks will be in the new branch and that could get quite confusing. OTOH, if I branch from the current state of dosomething I'm branching off unfinished work. Can anyone advise on the best way forward? Thanks Roddie Grant -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Branches and workflow
I am not a git expert but I would reset the doSomething branch ( without --hard ) to the commit when the code was uploaded to the server. Then stash the changes and merge the doSomething into master branch. Then create a new bugfix branch from master. After fixing the bugs and commiting in bugfixes branch, checkout doSomething and apply the stashed changes. Later also merge bugfixes into master. Also, please take a backup of your work for safety as even I am still in the process of learning git :) Here is a nice branching model to follow in future http://nvie.com/posts/a-successful-git-branching-model/ On Fri, Aug 26, 2011 at 2:16 PM, gitlist gitl...@myword.co.uk wrote: A questions about branches and workflow... I've done several weeks' work on a website feature, with the code all on the dosomething branch. This code has now been transferred to my test server for the customer to test. So the branch is not finished and there will almost certainly be more work done on it, even if just refinements. While the customer is testing that feature I need to start work on the next, and my instinct was to create a new branch. But where should it branch from? If I branch at the point where dosomething was started none of the quite-far-reaching work done in the last few weeks will be in the new branch and that could get quite confusing. OTOH, if I branch from the current state of dosomething I'm branching off unfinished work. Can anyone advise on the best way forward? Thanks Roddie Grant -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscribe@** googlegroups.com git-users%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/** group/git-users?hl=en http://groups.google.com/group/git-users?hl=en. -- Vineet Naik -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Branches and workflow
On Fri, Aug 26, 2011 at 2:16 PM, gitlist gitl...@myword.co.uk mailto:gitl...@myword.co.uk wrote: A questions about branches and workflow... On 26/08/2011 10:36, Vineet Naik wrote: I am not a git expert but I would reset the doSomething branch ( without --hard ) to the commit when the code was uploaded to the server. Then stash the changes and merge the doSomething into master branch. Then create a new bugfix branch from master. After fixing the bugs and commiting in bugfixes branch, checkout doSomething and apply the stashed changes. Later also merge bugfixes into master. Here is a nice branching model to follow in future http://nvie.com/posts/a-successful-git-branching-model/ Thanks for the reply. It's not really bugfixes that's the issue, it's how to handle overlapping development of two features. Feature 1 is being tested by the customer; I need to start work on Feature 2. But where to begin the Feature 2 branch? What I've realised today is that it's quite possible that Feature 2 (much simpler) could be tested and deployed long before Feature 1 - IOW overtake it. I can't risk any of the unfinished code from Feature 1 going on the production server, so I have to start Feature 2 from the current master, as deployed, even if that means having to pull out some work which is on the Feature 1 branch. I suppose I should not have allowed so much work to build up on the Feature 1 branch. I've saw the nvie model some time ago and found it very useful in establishing a workflow. It's just this overlapping it doesn't seem to address. Thanks Roddie Grant -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Branches and workflow
On Friday, August 26, 2011, gitlist gitl...@myword.co.uk wrote: Thanks for the reply. It's not really bugfixes that's the issue, it's how to handle overlapping development of two features. Feature 1 is being tested by the customer; I need to start work on Feature 2. But where to begin the Feature 2 branch? I would think master, or the most stable point that has all the changes Feature 2 needs. What I've realised today is that it's quite possible that Feature 2 (much simpler) could be tested and deployed long before Feature 1 - IOW overtake it. I can't risk any of the unfinished code from Feature 1 going on the production server, so I have to start Feature 2 from the current master, as deployed, even if that means having to pull out some work which is on the Feature 1 branch. I suppose I should not have allowed so much work to build up on the Feature 1 branch. Indeed, it sounds like in hindsight that work wasn't really part of Feature 1, and maybe should have been on its own branch. -- -PJ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
