For one problem, we may want to solve it by 3 ways. Sometimes we can just comment out the code and try for the 3 methods, but what if we want to have 3 snapshots of working code, easy to switch in a couple of seconds? (and so that the React website can just "hot reload", such as to show the three solutions to the manager or coworkers).
I could accomplish that if I git clone
3 times, and edit each directory to however I want. In this case, we don't have to do any commit at all. The catch is that, if it is a React app, for example, we have to stop the server and restart the server in another directory. (instead of dynamic reloading of the site...)
Then is the other way, to create a branch
git checkout -b easy-way
and do our changes and git commit
. Now if the second solution is to build on top of solution 1, then
git checkout -b more-complicated-way
and do our changes and git commit
.
And then if our 3rd solution is to be based on the original code on the server, then:
git checkout 3f564c # check the ID from the git log for the original code
git checkout -b the-third-way
and then make the changes and git commit
again, and so now, we could switch between the 3 versions by:
git checkout simple-way
git checkout more-complicated-way
git checkout the-third-way
? Is this the only way to make it work? Somehow I felt weird to do these commits because there could be console.log()
and commented out code every where. So to git commit
when the code is still messy feel weird.
Specifically,
Is it true that when using Git ... we have to ...?
Is this the only way to make it work?
Well, no. There are multiple different ways to do it, even in Git. But both of the ways you specifically asked about, are (IMHO) decent workable solutions, but perhaps could use some minor (conceptual) tweaking.
Side Note: you didn't state it explicitly, but you implied that you intend to serve your app out of a directory inside of the repo. I tend to avoid doing this. Instead, I would have the repo off to the side and use deployment scripts to move the appropriate subset of files to the served location. The benefits of this is you can pick and choose exactly which subset of files are served, and, perhaps more importantly, the served location is more likely to be clean. For example, when a Git repo is in the middle of an operation that has conflicts which require manual intervention, it is oftentimes not in a usable state. That being said, many people serve out of a repo and (AFAIK) it works for them.
As for some ideas:
git reset --hard [commit-id]
or git checkout [commit-id]
to switch between the states of the specific commits you want, and deploy that to the served directory (if you aren't already serving out of the repo).git checkout cool-feature-test1
or git checkout cool-feature-test2
, etc. Note, you could actually do something similar even if the commits are on the same branch, by instead tagging the commit IDs with a nice name, and then just checking out the nicely named tag instead of the commit ID. I might avoid using tags though on stuff that is likely going to be thrown away at some point. If you were about to tag commits on the same branch just for this reason, then I'd instead make new branches from each of those commits, and you end up at #3 anyway.If it were me, I'd probably combine #3 (separate branches) and #1 (multiple endpoints). I prefer #3 so I don't have to remember exactly which commit IDs to switch back to, and #1 so I could just give the testers the URLs and ask them for feedback on their own time. (#1 is also nice if deployment takes a while in a live demo, particularly if any code requires compilation.) With #3 you also get an added benefit of being able to tweak each try separately if you intend to make additional edits to more than one attempt after the demo.
Again, any of these should work just fine. I wouldn't stress out too much about which way to go. Pick something and try it, and then adjust if you find the need.