Comments (5)
Also we should use "Labels" and "Milestone" of Github in issue tracker so that we can filter the issue by type.
from teaching-app-dev-swift.
Thanks for the suggestions! I am going to leave the labels and milestones empty for now because there just aren't that many issues. (In other words, I'll add them when it starts to become worth it.)
Regarding the branches, I hear you. On the one hand, it is just as easy to check out a tag as it is a branch. However, I definitely think you are on to something, because using branches may make maintaining the changes we make to each lesson easier.
Right now, if I rebase to make changes to a particular tag, I have to delete and recreate each tag since rebasing changes the commit history but doesn't update the corresponding tags without some manual work (example.
Let me think about this, and practice this strategy with a deployment repo I have.
from teaching-app-dev-swift.
I've now investigated this quite a bit, and while it seems at first like a better approach. It isn't. The problem arises when changes are made in earlier commits that would then force a rebase of all child branches. Unfortunately, when rebasing each branch off the new parent HEADs, we get merge conflicts for all subsequent commits.
With a single branch, we can make an earlier change in the history, and just do an interactive rebase. When replaying the history over the earlier change, we don't have to manually handle the differences per each commit in the original history.
In other words, having a single branch timeline (on master), and rebasing/rewinding/playing back on top of the changes on that one branch are far more sane that having to rebase multiple branches.
The tradeoff is that, once the history is rewritten, we have to manually delete and recreate the tags. But that doesn't require much thinking, whereas dealing with merge conflicts across multiple rebased branches does.
from teaching-app-dev-swift.
However... the problem with tags is that we have to rewrite the history - which is terrible.
So, in fact, using branches really is the way to go. It doesn't provide a magic solution to managing the changing lessons, but it is a better long-term solution to managing the lesson projects.
When we want to change the commits that represent a particular lesson, we simply check out that branch, and make the changes. We have to manually apply those same changes to each subsequent branch. For example, if I make a code change in branch lesson04, then I have to make sure that the code in all subsequent branches (e.g. lesson05, lesson06, etc) reflect those changes too.
from teaching-app-dev-swift.
I've deprecated all tags in favor of branches.
from teaching-app-dev-swift.
Related Issues (20)
- L4 Journal Lesson 5: JournalEntry NSDate API changes
- L4 Journal Lesson 6: Journal external parameter names; controller property API change
- L4 Journal Lesson 8: prepareForSegueSender API change
- L4 Journal Lesson 10: NewJournalEntryViewController ext. param name and API change
- L4 Journal Lesson 11: JournalTableViewController viewWillAppear ext. param name
- L4 Journal Lesson 11: JournalTableViewController prepareForSegueSender api change
- L4 Journal Lesson 11: NewJournalEntryViewController cancel/save API change
- L3 FingerPainter Lesson 6: clearImage external param name
- L4 Flashcards Lesson 5: TermController#prepareForSegue:Sender: external param name and segue destination API change
- L4 Flashcards Lesson 6: TermController viewWillAppear external param name
- L4 Flashcards Lesson 7: DefinitionController prepareForSegue:Sender: external param name, segue destination API change
- L4 Flashcards Lesson 7: SearchController String and URL API changes
- L4 Flashcards Lesson 8: SearchController String API changes
- L4 RSSReader Lesson 1: UIApplicationMain / command-line API change
- L4 RSSReader Lesson 6: NSURL & JSON API changes
- L4 RSSReader Lesson 8: loadImageFromURL ext. param name, NSURL API Change
- L4 Journal Lesson 1: main.swift UIApplicationMain API change
- L4 Journal Lesson 3: Table view data source api change
- L4 Journal Lesson 4: Table view data source api change
- L4 Journal Lesson 5: Table view data source api change
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from teaching-app-dev-swift.