<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 3:16 PM, amit mehta <span dir="ltr"><<a href="mailto:gmate.amit@gmail.com" target="_blank">gmate.amit@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello All,<br>
<br>
This query is not about Linux kernel, but is rather generic query on<br>
development framework with git. Since, Linux Kernel project is<br>
significantly large, with astonishing number of people involved and<br>
large number of branches, I'm assuming that people have faced<br>
similar situation and your advice and guidance would be of great help<br>
to me.<br>
<br>
I'm currently pursuing Masters program and also working in a small<br>
tech Startup in the IOT domain. I'm involved in Firmware Development<br>
on ARM based SOCs and our team comprise three Engineers.<br>
We use git for SCM. Since we are in a very early phase and have<br>
very little turnaround time, from the requirement to final integration,<br>
we do not have a proper review process and hence everyone is allowed<br>
to commit in the master branch, or create, delete a branch, or a tag<br>
at will. We also do not have much insight into, how long a feature<br>
based branch would last. In last couple of months, I've seen some<br>
stale branches on which the development stopped quite early and<br>
some very active branch as well. Without much insight and probably<br>
due to not so well defined process, It is already becoming difficult<br>
to properly maintain the code consistency, filtering etc across<br>
several branches. For example, I create a feature remote branch<br>
(say origin/featureX) on which I continue my development and soon<br>
I realize that part (There is no way to pick partial commit) or a<br>
full commit that I recently made for the featureX should also go into<br>
another branches such as master and say featureY branch as well.<br>
But since, my colleague has been working on master, I get conflicts<br>
when I try to cherry-pick (At this moment, I do not want to rebase<br>
or merge two branches, I only need few of the commits from featureX<br>
branch to go into master and featureY). I resolve the conflicts and<br>
life goes on, but problem happens again later in future, if the two<br>
branches divert too much and a further need for cherry-picking or<br>
rebasing or merging is required.<br>
<br>
The point is that I also believe that it is a very good idea to maintain<br>
separate branches, based on feature or some other requirements, but<br>
it is also a n00bs nightmare when the conflicts are very high. There<br>
are also incidents when somebody forgot to add a particular commit<br>
to another branch and realized only later, when he was faced with<br>
debugging a issue and had to go through the git history, to figure<br>
out the issue. It would be nice, If for example a particular commit<br>
can be automatically propagated to other branches in this case.<br>
<br>
Please pitch in your suggestions, rule of thumb, tools and your way<br>
of countering such issue with less pain.<br>
<br></blockquote><div> </div><div>Few suggestions: </div><div><br></div><div>1. Better to have a proper review process in place, gerrit is one of the best tools I have used so far for reviewing,</div><div>2. Keep a master branch always compilable (run able) and merge rights should be only to integrator.</div><div>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) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Amit<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div><br></div></div>