SfePy GitHub development workflow

14 views
Skip to first unread message

Alec Kalinin

unread,
Sep 2, 2012, 9:19:39 AM9/2/12
to sfepy...@googlegroups.com
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.

(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?

(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".

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?

(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"?

(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?

[1] http://sfepy.org/doc-devel/dev/gitwash/development_workflow.html

Sincerely,
Alec Kalinin

Robert Cimrman

unread,
Sep 2, 2012, 3:07:18 PM9/2/12
to sfepy...@googlegroups.com
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

Md. Golam Rashed

unread,
Sep 2, 2012, 3:47:51 PM9/2/12
to sfepy...@googlegroups.com
Additionally, you can look into this cool Git tutorial to get some basic ideas.

Alec Kalinin

unread,
Sep 3, 2012, 8:29:53 AM9/3/12
to sfepy...@googlegroups.com
Yes, at this moment I think I have the right understanding of the development process. So I will try to do something useful. ;)

Alec.

Robert Cimrman

unread,
Sep 4, 2012, 10:56:29 AM9/4/12
to sfepy...@googlegroups.com
On 09/03/2012 02:29 PM, Alec Kalinin wrote:
> Yes, at this moment I think I have the right understanding of the
> development process. So I will try to do something useful. ;)

Great, thanks! I have fetched the pull request, but this week I am on a
conference, so I am not sure how quickly I will be able to merge it - I
have no wifi at the hotel, only at the conference site. So be patient :)

r.

Robert Cimrman

unread,
Sep 5, 2012, 9:32:20 AM9/5/12
to sfepy...@googlegroups.com
On 09/04/2012 04:56 PM, Robert Cimrman wrote:
> On 09/03/2012 02:29 PM, Alec Kalinin wrote:
>> Yes, at this moment I think I have the right understanding of the
>> development process. So I will try to do something useful. ;)
>
> Great, thanks! I have fetched the pull request, but this week I am on a
> conference, so I am not sure how quickly I will be able to merge it - I
> have no wifi at the hotel, only at the conference site. So be patient :)

FYI: I have commented the pull request...

r.

Alec Kalinin

unread,
Sep 5, 2012, 11:37:37 AM9/5/12
to sfepy...@googlegroups.com

FYI: I have commented the pull request...

r.

Thank you, Robert. Your changes look reasonable. So, from wokrflow point  of view, should I apply you patch on top of my tutorial-FEM-notes branch in my forked repository and reapply the pull request?

Robert Cimrman

unread,
Sep 5, 2012, 11:48:08 AM9/5/12
to sfepy...@googlegroups.com
Yes, I would apply the patch and amend the commit, and force-pushed the result. Then there is no need to repeat the pull request - just let me know it's done and I will merge it.

Thanks!
r.
--
You received this message because you are subscribed to the Google Groups "sfepy-devel" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sfepy-devel/-/p1EQNDS0tPUJ.
To post to this group, send email to sfepy...@googlegroups.com.
To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.

Alec Kalinin

unread,
Sep 5, 2012, 4:10:35 PM9/5/12
to sfepy...@googlegroups.com
Robert, could you send me the patch by e-mail? The html formatting in the github comment little broke the patch content.

Alec
Reply all
Reply to author
Forward
0 new messages