werner wrote:
Need some tips on git - I know OT but as it is for Phoenix:).
By following above I resync'ed my fork and local copy with Robin's, no
problem here.
Now I make three changes:
- one to conf.py, which might be of interest to Robin
- one to ignore, which he won't care, my Wing project files
- some small doc changes, which should be in the pull request
- committed them individually but when I start the pull request I see
that all are included and it doesn't allow me to cherry pick.
I like to do two pull requests, one for the conf.py and one for the doc,
but how?
I guess I should work with branches, but how?
Yep, each distinct change or group of changes should be done on a separate branch. They are not too hard to manage, from the command line you can do something like this:
git checkout -b my-new-branch master
That does a series of things for you. 1. changes to the master branch if you are not already there, 2. create a new branch from master, 3. changes to that new branch. (If you are already on master you can leave off the last parameter.)
GUI tools for git will have the same ability, although you may have to ensure that you switch to master (or are already there) first, and then make the branch. To switch back to master, or to some other branch, you run a command like this:
git checkout master
Once you have switched to a branch then any changes you commit will be saved on that branch. When you are ready to submit the changes you can push your branch to your github account (probably the 'origin' remote unless you've set things up differently) and then when you look at your github repository you will be able to choose that branch for a PR. If you need to make additional changes for that PR then you can make the updates in your local workspace, commit them, and then when you push that branch to origin again the PR will automatically be updated with the new commits.
One oddity that you'll need to deal with in our case is that since the changes will be going to a subversion repository before coming back to the git repository, then it will look like your changes were duplicated on master instead of being merged into master like is normally done with git. At that point you can just delete your branch, both in your local repository and in github. That will help unconfuse your local repository and nothing will be lost since the changes are now in master where you wanted them to be anyway.
One more tip: If you are working on more than one branch at a time, and want to test them all together before submitting them as a PR, then I suggest making an additional branch (like 'devel' or 'testing' or whatever) from master and merging the other branches to that branch. If you find that you need to make an additional change to one of the branches then you can either make the commit on the testing branch and cherry-pick it back over to the original branch where it needs to go, or make the commit on the original branch and then merge it back over to testing to run the tests again. If this sounds too confusing, don't worry, it will probably make sense when you need it and actually do it once or twice.
···
--
Robin Dunn
Software Craftsman
