On 09/02/2012 03:19 PM, Alec Kalinin wrote:
> Hello!
>
> Could you, please, explain me some moments about SfePy git workflow
> process? I will start with my own understanding of the workflow process. In
> general, to do a development we need 4 branches:
>
> * upstream/master,
> * origin/master,
> * local/master,
> * local/patch,
>
> where upstream/master is the SfePy primary GitHub branch, origin/master is
> the my GitHub clone of the SfePy primary branch, local/master is the clone
> of the origin/master on my machine and local/patch is the branch inherited
> from the local/master to do a patch.
Yes.
> (1) Question 1.
> We are on the "local/master" branch. Before we start a patch branch we need
> to get the latest changes. In documentation [1] I see the command "git
> fetch upstream" for it. But why not "git pull"? "git fetch" only retrieve
> the changes and does not do a merge. So will the "local/master" contain the
> latest commits in this case?
It's almost always good to see what the changes are before merging. But
in this case, as you develop in a feature branch (local/patch), your
local/master can usually be fast-forwarded to upstream/master, so after
fetch just do pull.
Then, just rebase local/patch onto local/master. So the state will be
that all masters are the same, and local/patch is some commits ahead. If
working on something bigger, do not rebase, just work on local/patch and
push it to origin/patch.
> (2) Question 2.
> We make a branch "local/patch" form "local/master", made the patch and did
> the commit. Now the "local/patch" is 1 commit forward then "local/master"
> and "origin/master". Next we push the changes from "local/patch" to the
> "origin/master". And now "local/patch" and "origin/master" are 1 commit
> forward then the "local/master".
No, push local/patch to origin/patch.
> But, what we need to do with "local/master"? We can switch to
> "local/master" and pull changes from "origin/master". Or we can switch to
> "local/master" and do the local merge with "local/patch". What is the right
> action?
See above, master should just track the upstream.
> (3) Question 3.
> We make a branch "local/patch" form "local/master" and are working on the
> code. In this moment somebody made a commit to the "upstream/master". Now
> "upstream/master" is the 1 commit forward than all our branches. What is
> the right way to obtain these changes: directly pull changes from
> "upstream/master" to the "local/patch" or pull changes to the
> "local/master" and then do the merge from "local/master" to the
> "local/patch"?
1. pull upstream to local/master
2. for small things (like this case): rebase local/patch on the new
local/master. Do not merge.
> (4) Question 4.
> We make a branch "local/patch" form "local/master" and did a patch. Before
> push our changes we checked if there are any new commits in the
> "upstream/master" and found, for example, two new commits. What we need to
> do? Always pull the changes, rebase and than push? Or we can push our patch
> without pulling the changes and rebasing?
See (1). You do not push at all to upstream/master, just to your own
origin/master and origin/patch :) Then you ask for the review by using a
pull request [2], and I (or someone) will check it, and if it is ok, I
will merge it to the upstream (using fast forward in this case, as it
will be a single patch rebased to the current upstream/master). Then you
can delete your local/patch and origin/patch and update the master.
Next time, rinse and repeat - as the upstream master might have changed
considerably, I would just force (if necessary) local/master and
origin/master to correspond to upstream/master. :)
Does it help?
Cheers,
r.
> [1]
http://sfepy.org/doc-devel/dev/gitwash/development_workflow.html
> [2]
http://sfepy.org/doc-devel/dev/gitwash/development_workflow.html#ask-for-your-changes-to-be-reviewed-or-merged