0

Notice: This is not a duplicate of this, so also no duplicate of this. Also not duplicate of this

Abstract:

I'd like to edit two files within the same branch(?) (both open in same IDE; both compiling to the same executable), while being able to commit/push/pull them on individual branches.

Concrete Example

Scenario steps:

  • I'm creating a Computer component in file computer.file. I manage it in branch component/computer.
  • I figure out, I will need to implement a Mouse component in file mouse.file. I also manage it in branch component/computer
  • I will be working on Computer and Mouse simultaneously (adjusting Mouse to what Computer needs).
  • I'm doing regular local commits to save my progress.
  • While I'm still working on both components, other team members like to also use the Mouse component in it's current version.
  • The Mouse component should best be shared in the main branch (develop branch). But as the Computer component is long before finished, develop branch should not know about it.

Problem:

Computer.file and Mouse.file are worked on within the same branch (component/computer), so merging that with develop, will also add Computer.file into develop (which is unwanted)

What I want:

I'd like to be able push/merge only Mouse.file into develop (regularly).
My idea of the solution is to have Computer.file on branch component/computer and Mouse.file on branch component/mouse, while being able to edit both branches in one IDE and branch and being able to commit/push/merge both branches independently.

DarkTrick
  • 2,447
  • 1
  • 21
  • 39

1 Answers1

0

Your proposed solution of editing each file on its own branch is correct. Conceptually you have two different features that are being worked simultaneously, but imagine they are being worked by two different people as well. Someone else is working on Mouse while you work on Computer and Computer depends on Mouse. In that case you would have to coordinate closely and regularly bring the changes from Mouse (or develop if you're willing to wait until they land there) into your branch, either with rebase or merge.

The fact that you happen to be developing both of these features together, means that you get to decide how to "coordinate closely" with yourself. You could maintain two branches and only put changes to the proper feature on each branch, and then keep rebasing component/computer onto component/mouse every time you make a change to component/mouse that component/computer needs. I would probably find that a little cumbersome though. In the past when I've done something similar I would work on a single branch (let's call it component/computer) and then do one of these:

  1. Simply make sure you never put changes to both features in the same commit. Later, when you're ready to Pull Request one set of those commits into develop you would create the component/mouse branch and cherry-pick the set of commits you want from component/computer. Afterwards, drop those commits from component/computer. (Note you can use interactive rebase to quickly do both of those actions.) This way you don't have to keep switching branches back and forth all day long and continuously rebasing component/computer onto component/mouse (or merging, etc).
  2. If you're willing to squash your commits later and the changes are always separated by files, you could skip #1 and just commit all your changes as you go whenever you feel like it. When you're ready to PR something into develop, git reset your branch back to where you started, and then only stage and commit the files you wish to PR into develop. Create a branch at that single commit called component/mouse and push it. Then stage the remaining files and create a second commit and call this component/computer.

Repeat either 1 or 2 for each PR you wish to make with Mouse changes into develop, starting with where you left off on component/computer.

TTT
  • 22,611
  • 8
  • 63
  • 69