Peter Gordon <peter@xxxxxxxxxxxxxxxxxx> writes:
> ... When we have finished
> working on the branch, we move back to the HEAD, with
> git-checkout master, do a
> git-pull
> and then git-cherry-pick sha1.....
> ...
> 1) Is this the normal way to work with git.
It does not look "normal" in that I do not see anything that pushes
your change back so others can build on top of it. Also cherry-pick is
valid but it probably is easier to use "git rebase" frontend.
You need to answer one policy question at the project level. Do you want
the shared central repository to be a place for your developers to also
share their not-quite-ready-for-master-work-in-progress?
Assuming you don't, for the sake of simplicity for now, you can simplify
the workflow by dividing it conceptually into two levels:
* shared repository 'master' branch is where everybody meets. Birds-eye
view of what you do is:
(0) git clone;
(1) work locally to advance your 'master';
(2) "git fetch origin", followed by "git rebase remotes/origin" to make
sure your changes come on top of whatever others have done while
you were working in step (1);
(3) "git push origin master", which pushes back your 'master', so that
others can build on what you did in step (1);
(4) go back to (1) to work further.
* because you always push your 'master' in step (3) above, as long as you
have what you want in your 'master' at that point, it does not matter
_how_ you work towards that state in step (1) above.
You can employ local topic branches (or you can use guilt patch stack),
and nobody else needs to know about it. If you have a long-running
work that won't be ready for the shared 'master', you may locally:
(a) "git checkout -b my-topic master";
(b) work locally whenever you find time;
(c) "git checkout master" if you get interrupted and have more urgent
things to do;
(d) "git checkout my-topic" to continue, but from time to time, it
would be a good idea to "git rebase remotes/origin" while on that
branch, and when you are finally done with my-topic, then
(e) after making sure with (2) above that your 'master' is up-to-date,
"git checkout master", "git merge my-topic".
(f) then finally "git push origin master".
But you can consider these steps (a)-(e) merely "implementation
details" of how you would perform (1) above.
Once you got comfortable with the workflow without topics, more advanced
developers among you would find local topic branches handy way to organize
their work. But you do not have to. And if you do not use local topics,
there is no reason to avoid working directly on 'master'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
