[Off-topic] SCM using git

[Greg Freemyer]

On August 18, 2015 5:46:38 AM EDT, amit mehta <gmate.amit at 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.
>
>Thanks,
>Amit
>
>_______________________________________________
>Kernelnewbies mailing list
>Kernelnewbies at kernelnewbies.org
>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