Is it possible to transfer changes from one branch to another, without conflict.

I want to do this, I have 2 boards (2 branches) on which I can debug the algorithms, the boards differ only in the initialization file (or initialization commit, there may be several files)

After adding changes to one branch, I want to transfer only the changes made to another branch. The cherry-pick command does this with a conflict, as there are changes in the initialization files.

Well, I will describe a little more in detail, I do embedded programming and use git purely for myself, to create test branches of all different peripherals, and not to lose (spoil) the main project.

So, regarding the boards, you correctly understood this printed circuit boards, with the connection of all peripherals to the processor and the connection is just a little different, but there are algorithms that are completely independent of hardware, so I want to drive them, then on one board, then on the other to the board, and I want to make all the changes that I made, on one board it was possible not to transfer my head to the other, and continue there.

My program has a modular ( .с , .h files) composition, initialization of each periphery, is in its module, so that you can throw two files into another (new) project and not to look for how to turn it on later. (But here Iā€™m already considering the option to put all the initialization functions in a separate file).

But in this version, this is not appropriate because, in addition to the initialization files, for each board it was necessary to make some minor changes to several modules (due to differences in the size of flash in the processor, the page size changed, and on one board it changed the data transfer functions The transfer method without using DMA) although it can be put into the configuration file, but still something new can come out, such as with a change in the transfer method.

The player one comment, suggested to me that I should make my own repository for each module, and in the new project we should combine them all with the help of submdule, I donā€™t know what this will lead to, I havenā€™t been digging much in this direction.

But I think it should turn out that if I found some kind of bug in one module, it will automatically be eliminated in new projects, and the old ones wonā€™t crawl if you donā€™t specifically download the module, and make these changes, this is fine with me, I have long wanted to do this but did not know which way to dig.

  • 3
    Did you open a file that leads to a conflict? If I'm not mistaken, all the contents of the merged branches are added to the conflict files. Something like this: <<<<<<< *HASHofFIRSTCOMMIT*:mergetest This is my third line ======= This is a fourth line I am adding >>>>>>> *HASHofSECONDCOMMIT*:mergetest - Sanek Zhitnik
  • Yes, I opened it; itā€™s not difficult in the trailer, Iā€™ll fix everything, but I plan to go there to jump between branches, and every time I donā€™t want to <<<<<<< HEAD 1) Main branch ======== 1) I changed the configuration on this fee 2) made changes -> this piece should be transferred to the main program >>>>>>> 3a796a6 ... Š Ń™Š Ń•Š Ń˜Š Ń‘Š” ā€šŠ”Šƒ Š Ń‘Š  Ā· Š Ń˜Š ĀµŠ Š…Š ĀµŠ Š…Š Ń‘Š”ŠŠ Ń˜Š Ń‘ - Max
  • When you tried to apply changes from one commit to another branch, git was in ā€œsuspendedā€ state and stopped at the conflict file. As soon as you resolve all conflicts and CONTINUE to merge, you will not need to edit the file each time you switch to different commits or branches) If I am wrong, please correct me. PS call the git status command to better understand what the git wants from you. - Sanek Zhitnik
  • four
    You are looking for the wrong side. IMHO the solution to the problem should be sought in the proper organization of the repository and workflow. Environment-specific configuration files should not be stored in the repository. If you have such a situation, then remove the configs from version control and the problem will disappear. If by ā€œinitialization fileā€ you mean some kind of compiled code, then you might think in the direction of some division of the project into modules. For example, two separate repositories specific to each board, and one repository with common code, which is connected to the first two via git submdule. - player one
  • Thank you all for helping the campaign I needed git submdule to figure out how to use it. - Maxim

1 answer 1

I completely agree with the player one comment: you ask a technical question, but it arises due to improper organization of the workflow. And it would be right to recommend you to put things in order in the working process, and not to explain how to cut the Gordian knot with a specific technical issue.

Judging by your description, you have two branches in the project, almost completely identical. You are duplicating a very large number of files, in addition to one configuration file and perhaps several more files. And you constantly switch from branch to branch, "jump."

Don't you think that you have essentially TWO projects, and not ONE? And you need two repositories, one project = one repository?

The problem of duplication immediately emerges: these will be two repositories that are so identical that it is imperative to recall the DRY principle (Don't repeat yourself) and recommend thinking about removing unnecessary duplicates.

Without knowing the details of the project it is difficult to recommend something concrete. I would suggest putting the common part in the 'core' ("engine") and connecting it to my two projects (it turns out three repositories: the root, with a common part and two small repositories with differing parts). I donā€™t know how this fits your project; in general, the word ā€œboardā€ causes association with printed circuit boards, I donā€™t know how they are stored in git.

And here about the configuration file here, I also strongly recommend that you think about taking these files beyond the scope of version control through the .gitignore mechanism.

So at least itā€™s taken as a convenient process of joint work of several people (everyone can make their own settings and they will not get into git, they will not conflict with each other), on different environments (development - stage - production).

  • one
    It depends on what kind of configuration. If the second motherboard developer needs the same configurations, then it is more logical to store them in git - a.chugunov