CODEWITHSUNDEEP
gitversion-control
C-Otto
C-Otto

Reputation: 5843

git: Updating branches that depend on each other

Situation I think a picture is a better explanation:

enter image description here

As you can see, we have several branches, most of them solution-xyz-foo for varying numbers xyz. solution-12 builds on solution-11 and so on. There also are some deviations from this rule, e.g. the branch hystrix-dashboard-demo.

Motivation The code in the branches is used by course participants in a classroom style course. As such, participants solve the exercises and, at the end of the course, end up with code similar to what we provided in the solution-24 branch. In case a participants gets outpaced or faces some other issue, he can easily checkout the corresponding branch and continue with the rest of the exercises.

Furthermore it is possible to look at the solutions of each exercise, which are provided as a single commit.

In other words, for the course participants the branches/solutions building on top of each other serve a big advantage which we would like to keep (this builds on feedback of multiple courses held so far).

As a developer of the course (preparing the exercises and solutions, presenting the content to the participants etc.) we need to update parts of the code from time to time. For example it could be the case that we want to fix an issue in solution-3. In order to make this fix visible in solution-4 etc., we need to either merge/rebase/cherry-pick the commit containing the fix. In order to avoid a huge mess, we decided to squash all updates of each solution into a single commit, and then re-build the somewhat linear structure shown in the picture using a few rebases.

Issue As you might have guessed, doing the rebases is a lot of work. Even with a helper script (that re-attaches the branches to the commits after a rebase, but needs to be maintained in case of new/changed branch names) we still need to do the rebase, fix conflicts, re-attach the branches, and push the changes back into the repository (using a force push).

In addition to the actual work involved, this is something only team members with lots of git experience are confident to do. In other words, those that are not as confident complain about the procedure (which I clearly understand).

As a side note, we lose the obvious advantage of git: there is no change history (and old versions are lost). Furthermore, developers need to collaborate and communicate changes to the code.

Question Can you recommend ANY tag/branch/rebase/... workflow that solves the following issues?

As a note, you may assume that the code does not change while a course is in progress (so no git remote update is necessary on the participants' computers).

Upvotes: 1

Views: 101

Answers (2)

Gregg
Gregg

Reputation: 2624

Instead of accessing each 'solution-xyz-foo' commit as separate branches, Try accessing it as a searched ancestor commit in the chain.

git checkout -b MyWorkingBranch remotes/origin/LAST_COMMIT_IN_COURSE^\{/solution-xyz\}

then checkouts subsequent to 'rebase --onto IMPROVED_COMMIT' will produce branches based on the IMPROVED_COMMIT

see 

git help revisions

if you use tags instead of branches, you can use 

git filter-branch --tag-name-filter <rename command>

to update all the tags that reference all the changed commits. See 'git help filter-branch'. Again students could get branches directly from the tag names with 'git checkout -b TAGNAME' and the history would be available.

Upvotes: 1

David Neiss
David Neiss

Reputation: 8237

So it sounds like a surgical rebase in the middle of the chain to fix up some commit followed by another rebase of the (previously) following commits --onto the newly fixed up commit. So I'm confused by the comment "...Even with a helper script (that re-attaches the branches to the commits after a rebase, but needs to be maintained in case of new/changed branch names)...". That would seem to be (possibly) as simple as a rebase --onto your updated commit, so there is no need to maintain it for new/changed branch names - all that stuff is carried through with the rebase, no?

Upvotes: 0

Related Questions