How to Make Git a Developer’s BFF
Alice Brosey is a big fan of Git and the Hitachi Solutions America senior developer thinks other developers should love Git, too.
“Our goal here is to make it your best friend,” Brosey told an audience at Code PaLOUsa 2022, a regional conference for developers held in Louisville, Ky. “It should not just be something that you’re using because your work told you to use it. It should be something that’s making your life easier every single day because of what you get to do with it.”
Brosey, who now works with Dynamics 365 but has extensive experience as a React developer, outlined how the distributed version tracking tool works in a way that can “save you over and over and over, but only if you let it be the tool you want to use instead of just the objects that you’re using to submit your changes.”
If you’re new to Git, you may want to first check out this tutorial by Michelle Gienow.
Git as a Snapshot
A Git is a collection of snapshots of your project, with each commit being a snapshot of your code at a given moment, Brosey pointed out.
“Git allows us to have distributed version tracking. Every computer is a full fledged repository with a complete history and this is what makes Git so powerful,” she said. “Git can save you over and over and over, but only if you let it be the tool you want to use instead of just the objects that you’re using to submit your changes.”
Think of it one giant list of tags, she added, with branches, tags and stashes all just labels on the tree. Stashes are changes made to a working copy so the developer can work on something else, and then back and re-apply them later on. Some tools, like Github Desktop, only let you have one stash at a time — Brassy said she’s not sure why, because Git allows as many stashes as you want.
However, commits are important for developers to use frequently because they can serve as a back up that can be used to identify issues in the code and to roll back the code if necessary. This can be done on the developer’s PC without sharing it with others, she added.
“That’s one of the things that’s super important, is just understanding that committing often does not mean you have to necessarily be sharing it with others or have it be ready for consumers,” Brosey said. “It means that you are making spaces where you have a snapshot you can go back to, and you have this opportunity to be able to figure out where you’re introducing issues in your code as we go.”
Heads and Detached Heads
Heads are one thing a lot of people don’t understand, she added. Heads are where you are right now in the Git repo. A detached head is simply when you have checked out a specific commit that is not the top of a branch.
“If you are there and you make some changes, there’s usually all sorts of warnings [that] you can’t do this. You can’t commit to a detached head, because it doesn’t know how to roll that,” she said. “But all you have to do is give it a label at the detached head, create a branch, commit that branch, and suddenly you have your space right there.”
Using that allows you to go back to any commit anywhere, rather than just at the top of the branch.
“You can go back several layers [to] figure out […] when did this bug get introduced? Go back several layers, check them out, see if the code runs there,” she said. “Move forward again, going back and forth, frequently in your repo [it] allows you to figure out what happened, rather than spending a lot of time trying to figure out where an issue is.”
Additionally, because Git has everything locally on the developer’s computer, that function can be used without having to do it on the remote server, so “your co-workers don’t need to know what happened,” she said.
Parameters for Pushing on Git
It’s important to figure out how the developer’s employer has set up the Git. In some cases, developers may not be able to remove their own branches, although Brassy has generally found that employers restrict the main branches — not what can be done with one’s own branches. While developers can opt to not push frequently, this is where it can create problems, she added.
“If something happens to your peer, and you’re going to lose a whole lot of code, it’s better if you also have pushed frequently,” she said. “If you own your own branches, and have the ability to remove them, or the ability to clean them up, and, and all of those things, then you can feel more confident pushing to your server that is shared with your teammates, so long as they understand what you’re doing also, that this is not consumable.”
The challenge comes if you’re working for an employer who wants everything to be perfect, she said.
“If you work for an employer who wants everything to be perfect, you’re going to need to figure out a different way to handle this and maybe not be pushing all of your work as you go, but you can still use Git for you as your friend on your computer, and not be restricted by what your employer expects out of things that are pushing,” she said.
In that case, she suggested using a work-in-progress tag to indicate code that’s not ready for to be built or run through automations, so you can push code out and not lose work — but not create red flags or problems.
