On Tue, Aug 18, 2015 at 3:16 PM, amit mehta [off-list ref] wrote:

Hello All,

This query is not about Linux kernel, but is rather generic query on
development framework with git. Since, Linux Kernel project is
significantly large, with astonishing number of people involved and
large number of branches, I'm assuming that people have faced
similar situation and your advice and guidance would be of great help
to me.

I'm currently pursuing Masters program and also working in a small
tech Startup in the IOT domain. I'm involved in Firmware Development
on ARM based SOCs and our team comprise three Engineers.
We use git for SCM. Since we are in a very early phase and have
very little turnaround time, from the requirement to final integration,
we do not have a proper review process and hence everyone is allowed
to commit in the master branch, or create, delete a branch, or a tag
at will. We also do not have much insight into, how long a feature
based branch would last. In last couple of months, I've seen some
stale branches on which the development stopped quite early and
some very active branch as well. Without much insight and probably
due to not so well defined process, It is already becoming difficult
to properly maintain the code consistency, filtering etc across
several branches. For example, I create a feature remote branch
(say origin/featureX) on which I continue my development and soon
I realize that part (There is no way to pick partial commit) or a
full commit that I recently made for the featureX should also go into
another branches such as master and say featureY branch as well.
But since, my colleague has been working on master, I get conflicts
when I try to cherry-pick (At this moment, I do not want to rebase
or merge two branches, I only need few of the commits from featureX
branch to go into master and featureY). I resolve the conflicts and
life goes on, but problem happens again later in future, if the two
branches divert too much and a further need for cherry-picking or
rebasing or merging is required.

The point is that I also believe that it is a very good idea to maintain
separate branches, based on feature or some other requirements, but
it is also a n00bs nightmare when the conflicts are very high. There
are also incidents when somebody forgot to add a particular commit
to another branch and realized only later, when he was faced with
debugging a issue and had to go through the git history, to figure
out the issue. It would be nice, If for example a particular commit
can be automatically propagated to other branches in this case.

Please pitch in your suggestions, rule of thumb, tools and your way
of countering such issue with less pain.

Few suggestions:

1. Better to have a proper review process in place, gerrit is one of the
best tools I have used so far for reviewing,
2. Keep a master branch always compilable (run able) and merge rights
should be only to integrator.
once a feature is developed (on a feature branch) and ready to get into
master, create a new commit for master branch for merging (of course after
validating against the new head)

Thanks,
Amit

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150819/19de2655/attachment.html