+1
This is something I've been thinking about for some time but my git
skills have made me to avoid it. I'm particularly interested the
workflows for:
1) Updating the branch from master
2) Merging the branch back into master
Since we are informally a CTR (Commit Then Review) project I guess we
don't need a strict policies about the merging to master. However since
this will typically be used for larger more "destabilizing" work we may
want to suggest at least a [DISCUSS] thread prior to the final branch merge.
Policies aside I'd like to see the suggested branch workflow described
in the Contribution Process wiki page.
https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process
I ask this as much as an aid for myself as anything else.
On 12/29/14 9:03 PM, larry mccay wrote:
Thanks, Sumit - I agree on all points - jira id as name is fine - I don't
know that we need to be strict about that point but it is a good general
guide.
+1
On Mon, Dec 29, 2014 at 3:20 PM, Sumit Gupta <[email protected]>
wrote:
I would like to seek opinions on using Git branches (remote branches) for
features that are relatively significant in size. The workflow is a well
established one with Git and the benefits are the obvious ones:
1. Work on sizable code without breaking the master branch.
2. Have a place to keep code other than on a laptop.
3. Easy way to collaborate, get code reviews, do iterative development etc.
I have tried out the basic workflow of creating a local branch and then
pushing it remote. Making a simple change in the remote branch and then
merging it locally and pushing that change to master. Instead of the merge,
we could also create patches if that is more appropriate.
For example, I started working on feature KNOX-481, so I did the following:
git checkout -b KNOX-481
then, pushed the branch remote, (this command also sets up the remote
tracking),
git push -u origin KNOX-481
From here it is regular git commit+push workflow until you are ready to
merge.
To merge, checkout master,
git checkout master.
Then, git merge KNOX-481. Although, like I said, a patch could also be
created easily.
If branches sound like a reasonable idea for features, do we also want a
convention around the naming? I used the Jira issue Id in my example. Also,
what is the life of the branch? Once all the code for the feature is merged
we should probably delete it to prevent clutter.
Sumit.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
