Search code examples
gitgit-workflow

Is it true that when using Git to try for 2 or 3 solutions, we have to use 2 or 3 branches with commits?

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.

Solution

  • 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:

    1. 3 different directories on the server: From a Git point of view, I would actually consider this a subset of Option #2 or #3. I don't think you need 3 separate copies of the repo; just one would suffice. But you could still have the 3 different sets of code deployed into 3 different directories on the server, each one represented by a different commit. If it's easy enough, instead of changing which directory the endpoint uses, you could set up 3 endpoints at the same time so that the audience can see all 3 without any delay (or even try each one themselves at any time).
    2. 3 different commits on the same branch: this is actually how many people develop code naturally: Make a new branch to work on. Try something and commit it. Tweak it or completely redo it and make another commit. (Note right here you don't have to comment out the previous try, just replace it completely since it's already saved in the previous commit.) Tweak some more and commit it. If you do this, for your demo purposes, you can either 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).
    3. 3 different branches: note that a branch basically just points to a commit ID, so whether the 3 commits are on the same branch or different branches doesn't really matter. The main difference is if you use different branches, you get the benefit of checking out with a nice text name: 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.