[Off-topic] SCM using git

[Chetan Nanda]

On Tue, Aug 18, 2015 at 3:16 PM, 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.
>
>
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