On Tue, Aug 18, 2015 at 3:16 PM, amit mehta <gmate.a...@gmail.com> 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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies