On August 18, 2015 5:46:38 AM EDT, amit mehta <gmate.amit@xxxxxxxxx> 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. > >Thanks, >Amit > >_______________________________________________ >Kernelnewbies mailing list >Kernelnewbies@xxxxxxxxxxxxxxxxx >http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Personally, in young code I find long lived branches hard to work with. For new features I prefer to work first on the integration related code with a stub that gracefully does nothing or fails. So at the start of adding a new feature that will be implemented via a subroutine,write the invoking code a stub that gracefully does nothing. Often the invoking code and the stub can be written in 10 minutes or less. Then push/pull that into master immediately. Then I would use an ifdef to work on a real subroutine to implement the feature. ie. #ifndef FEATURE_X_TESTING /* Declare a a stub to use until the code is stable enough for master */ int new_function() { return(TRUE); } #else /* This is unstable code I am still writing */ int new_function() { /* New code */ } #endif Then in my local makefile (or via a environment variable, I set FEATURE_X_TESTING true. Now my new unstable code will have no negative impact on master, so I push it to master often. Probably at least once a day. When I'm ready to first enable it in master, I just define FEATURE_X_TESTING in master. Greg _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
