Stream: committers/git-help
Topic: Maximizing efficiencies
Michelle (Moseman) Miller (Oct 13 2018 at 22:03):
Per @Grahame Grieve announcement (https://chat.fhir.org/#narrow/stream/139-committers.2Fannounce/topic/Task.2Fgit.20cycle) to commit as granularly as possible (e.g. 1:1 task/commit), I'm trying to determine how to do this as efficiently as possible. Prior to this announcement, I would normally apply all tasks from the past week or two, which would be a local build time commitment of ~1 hour. If I have to start committing each task separately, then X tasks would be X hours of local build time (vs 1 hour previously). Is there a more efficient way to do this where I am only doing a single local build despite needing to commit separately? For example, does the following work?
1- Pull from master (sync)
2- Create branch 1
3- Make changes for N trackers
4- Build locally ONE time
5- Commit to local branch 1, push to GitHub branch 1, PR (selecting only a subset of files related to #1)
6- Switch back to master (my local files still reflect changes that haven't been committed yet, correct?)
7- Create branch 2
8- No need to build again (since I built earlier and haven't made any changes)
9- Commit to local branch 2, push to GitHub branch 2, PR (selecting a different subset of files related to #2)
10- repeat (steps 6-9) as needed up to N
11-switch back to master
12-Pull from master (only when done committing all changes)
If the tasks are in different files, then the above might help (assuming it works). However, if multiple trackers impact the exact same file, then can I commit those trackers together so I only have to build once locally?
Lloyd McKenzie (Oct 13 2018 at 22:18):
You can't "commit to a branch" in Git. You can switch to a branch, make changes, then commit, then switch back. But you can't carry your changes with you when you switch without stashing and unstashing which gets messy.
Lloyd McKenzie (Oct 13 2018 at 22:22):
Grahame's arguing for granular commits, but there's no need for granular branches. My leaning is to actually have the norm in HL7 be to have one branch per person. The only reason to have "special" branches is if: a) you're working on something that you need to share with others before it gets committed; or b) you're working on a set of changes you want to keep completely separate from a different set of changes you're working on. Both of those are unusual workflow in HL7. I don't see any benefit to maintaining granular branches if you're not doing either of those things. Beyond "that's the Git way", is there any reason to have granular branches that makes sense in the way HL7 manages our publication process?
Michelle (Moseman) Miller (Oct 13 2018 at 22:34):
I don't mind creating a new branch each time I sit down to do some work (let's just say bi-weekly). I'm just trying to avoid doing N number of local builds for N tasks that I'm working on in one single sitting. The time it takes to do N local builds is going to dramatically decrease my productivity/efficiency.
Lloyd McKenzie (Oct 13 2018 at 22:37):
Sure. But is there a benefit to branching each time you sit down to work? If there's no benefit, no reason to make you (or anyone else) jump through the hoops.
Michelle (Moseman) Miller (Oct 13 2018 at 22:39):
Sure. I'm just focused on the really time-consuming local builds over the pin-pricks of managing branches. I'm picking my battles :)
BTW, I clarified what I meant in step 5, but @Lloyd McKenzie I think you are saying that when I switch back to master, I will lose my non-committed changes.
Grahame Grieve (Oct 13 2018 at 22:40):
Right. I said nothing about the granularity of branching or making pull requests. What you would change in that workflow is that you make mutilple commits to the local branch, for each task... though with that work flow, it’s pretty hard not to group changes to a single file. In fact, what I do is commit as i go while I’m in the branch.
Michelle (Moseman) Miller (Oct 13 2018 at 22:46):
@Grahame Grieve I think you are suggesting a flow like follows, correct?
1- Pull from master
2- Create branch for N trackers and switch to that branch
3- Make changes for N trackers
4- Build locally ONE time
5- Commit to local branch (selecting only a subset of files related to task 1)
6 - Commit to local branch again (selecting a different subset of files related to task 2)
7 - Commit to local branch again (selecting a different subset of files related to task N)
8 - Single push from local to GitHub when all local commits are done
9 - single PR to merge to master
10-Once PR builds successfully, merge the PR and delete branch
11-In local version, switch back to master and delete branch
12-Pull to grab your changes back from master
I can do this, but there is still a risk of a single commit containing multiple tasks when those tasks touch the same file.
Lloyd McKenzie (Oct 13 2018 at 22:49):
#2 should be create branch and switch to branch for N trackers
Lloyd McKenzie (Oct 13 2018 at 22:50):
10. Once PR builds successfully, merge the pull request and delete the branch
11. In your local version switch back to master and delete the branch
12. Pull to grab your changes back into master
Grahame Grieve (Oct 13 2018 at 22:51):
Yes, if you do it that way... yes you have to do that. But what I do is:make the change, and commit immediately if it’s pure text. Or star a bulls and then commit once I see the build succeed. This helps keep the commits granular, and I don’t build up too many problems with thins that don’t run.
Lloyd McKenzie (Oct 13 2018 at 22:57):
Only issue is that if you make a change that breaks something when you fix it in your local build, you'll have to associate your fixes to the specific tracker number too - so you may end up with multiple commits per tracker # - but that should be ok.
Michelle (Moseman) Miller (Oct 13 2018 at 22:59):
@Lloyd McKenzie That is why I do the local build before I commit.
#2-- yep, I know, it was my short hand notes (since the TortoiseGit UI lets me do both in a single step) -- I'll edit for clarity in case others reference it.
Michelle (Moseman) Miller (Oct 13 2018 at 22:59):
In sum, it sounds like I can make a single commit for multiple tasks impacting the same file (e.g. commit all condition-spreadsheet changes together), but I should start committing more granularly where possible (e.g. don't commit condition and procedure changes together).
Grahame Grieve (Oct 13 2018 at 23:01):
Y
Last updated: Apr 12 2022 at 19:14 UTC
