As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow should be, so I don't screw up the upstream repo by pushing something to the wrong place. :-)
I know enough that I should be using local branches to develop my changes, so I want something like: git checkout master git pull git checkout -b <branchNameHere> <modify and add new files> git commit -m "My commit message1" <modify and add new files> git commit -m "My commit message2" <modify and add new files> git commit -m "My commit message3" <all done!> At this point, I get a little confused. :-) I know to submit my patch for review, I'll want to squash my commits down into one patch, but how does one do that? Should I do that now or only when I'm ready to push this change to the upstream repo or ??? Do I need to even do that? Also, when I'm ready to push this "change" upstream to trunk, I'll need to move this over to my master and then push. What are the recommended commands for doing that? I assume I need to rebase my branch to current upstream master, since that probably has moved forward since I checked my code out. Also, at what point do I write my final commit message, which is different than the (possibly simple) commit messages above? Is that done after I've pulled my local branch into my master? ...or before? ...or during the merge over? ...and this is just for changes going to trunk. How does all this change when I want to push changes to a release or vendor branch? I guess I'm just looking for some simple workflow commands for both trunk and release/vendor branches I can follow until I'm a little more confident in my git knowledge. I'm guessing I'm not the only one who would like this info, so maybe someone can add this to our wiki? Peter
