Aug. 31, 2024, 3:03 p.m.
Issue 32 - Considering Management and Managing Git Commits
Code, Content, and Career with Brian Hogan
In this month's issue you'll explore if people management is right for you, and you'll look at how to take changes you've made to your code and split them into multiple commits.
Split Changes into Multiple Commits with Git
When working on a project, you might make several changes before you commit. However, these changes might relate to different features or bug fixes. For example, you might change a file to fix a bug, but you might see something else in the file that bugs you, so you fix it while you're there.
Note: If the code blocks and output are difficult to read, you can view this tutorial at the Small, Sharp Software Tools site.
Committing all changes at once can lead to a messy, hard-to-understand commit history or a more complex code review process. Git lets you selectively stage parts of your changes instead of adding the whole file. Using this feature, you'll get a cleaner history with smaller units of work for peers to review, as well as a chance to deal with any out-of-scope work you still want to keep but commit elsewhere.
In this tutorial, you'll explore this feature by creating a small HTML project and staging your changes interactively.
To start, create a new directory and initialize a Git repository:
$ mkdir interactive-commit-demo
$ cd interactive-commit-demo
$ git init
Then create a basic HTML file called index.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Interactive Commit Demo</title>
</head>
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
</body>
</html>
Add and commit the file to your repository:
$ git add index.html
$ git commit -m "Initial commit with basic HTML structure"
Now make two distinct changes to the file; change the title and add a new paragraph to the body of the page:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Interactive Commit Tutorial</title>
</head>
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
<p>This is a new paragraph we'll commit separately.</p>
</body>
</html>
You made two changes to this file, but putting them in the same commit might not be best. For example, the paragraph may be a change you can get approved quickly, but the page's title might need approval by SEO experts, and you don't want it to block the publication of the paragraph.
Run the following command to start an interactive commit:
$ git add -p
You'll see the patch on the screen:
diff --git a/index.html b/index.html
index 7b6e59a..0d63f4e 100644
--- a/index.html
+++ b/index.html
@@ -3,10 +3,11 @@
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
- <title>Interactive Commit Demo</title>
+ <title>Interactive Commit Tutorial</title>
</head>
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
+ <p>This is a new paragraph we'll commit separately.</p>
</body>
</html>
(1/1) Stage this hunk [y,n,q,a,d,s,e,?]?
Press s to split the patch into separate pieces. The screen updates to show just the title change:
Split into 2 hunks.
@@ -3,8 +3,8 @@
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
- <title>Interactive Commit Demo</title>
+ <title>Interactive Commit Tutorial</title>
</head>
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?
Now press y to stage the title change. The next change appears, which is the change to the paragraph:
@@ -7,6 +7,7 @@
</head>
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
+ <p>This is a new paragraph we'll commit separately.</p>
</body>
</html>
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
Press n to skip this change for now. You'll return to your prompt.
Use the git status command, and you'll see that there are staged changes as well as unstaged changes:
On branch main
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: index.html
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: index.html
Commit the title:
$ git commit -m "update title"
You'll see one line added and one line deleted, representing the title you changed:
[main 41d01ad] update title
1 file changed, 1 insertion(+), 1 deletion(-)
Now, use the same process again to add the paragraph change. Execute the following command:
$ git add -p
This time, the paragraph change patch appears:
diff --git a/index.html b/index.html
index e0059db..0d63f4e 100644
--- a/index.html
+++ b/index.html
@@ -8,5 +8,6 @@
<body>
<h1>Welcome to My Website</h1>
<p>This is a paragraph.</p>
+ <p>This is a new paragraph we'll commit separately.</p>
</body>
</html>
(1/1) Stage this hunk [y,n,q,a,d,e,?]?
Press y to stage the change.
When you return to your prompt, commit the change:
$ git commit -m "add paragraph"
Verify your commits with git log:
$ git log --oneline
You'll see your initial commit along with the two additional ones you made:
bb403d9 (HEAD -> main) add paragraph
41d01ad update title
aaa6f92 Initial commit with basic HTML structure
Using this approach, you were able to split the changes you made to a single file into two separate commits.
Sometimes, the lines may be too close together to use the automatic split feature, but you can manually edit the patch information. Consult the Git documentation on editing patches for more.
Splitting your changes into multiple commits gives you fine-grained control and lets you maintain a cleaner, more logical commit history, making your project easier to understand and manage.
Why You Should (Or Should Not) Manage People
As your career progresses, you might consider transitioning from an individual contributor (IC) role to a management position. The transition from IC to manager is a significant career change. It may seem like a promotion or the next step in your career ladder, but it's actually a shift to an entirely different set of responsibilities and skills. Being "the best performer on the team" doesn't mean you're the best choice to lead.
But if you're up for the challenge, it can be incredibly rewarding. Here are three reasons to consider making the jump:
-
You like helping people grow
If you find joy in helping others grow and succeed, you'll find success in management. As a manager, you'll have opportunities to mentor, coach, and guide your team members along their career paths. You'll be able to create an environment where people can thrive, learn, and advance in their careers. You'll be responsible for their success and accountable for their outcomes. -
You enjoy building relationships and getting things done with others
Management is all about collaboration and influence. You will find management rewarding if you're good at building relationships, fostering teamwork, and achieving goals through collective effort. You'll be the bridge between different teams, stakeholders, and your own team members, facilitating communication and driving projects forward. -
You enjoy shaping strategy and direction
As a manager, you'll have more influence over the strategic direction of your team and potentially the entire organization. If you're excited about setting a vision, defining goals, and steering the ship, management allows you to have a broader impact beyond your individual contributions.
Management is about getting work done through others. Since you won't be able to accomplish the work yourself, you have to think about processes, procedures, strategies, and tactics that allow the people you're responsible for to do their best work.
You're also accountable for your team's performance and impact, and that can be challenging since you're not directly doing the work you'll be accountable for. With that in mind, here are some reasons you might want to stay on the individual contributor career path:
-
You like being hands-on
If you love diving deep into technical problems, writing code, or creating things yourself, you will find management frustrating. Managers typically spend less time on hands-on work and more time on people and process management. And when you do have a moment to jump into the details again, your attempts to be helpful can undermine others' work because of the power imbalance or block people because you'll get something halfway done before you have to put it on hold again. If you're not ready to step back from the day-to-day technical work, you might be happier remaining on your current path. -
You think you know the best way to do things.
You have much experience that others can learn from, which gives you confidence. While confidence is important, believing you always know best will cause problems. Effective managers need to be open to diverse perspectives, willing to listen to their team members, and able to change course when necessary. As time passes, you'll become less familiar with the day-to-day work than your team. Your experience becomes less relevant. If you're not prepared to trust your team and support their ideas, management might not be the right fit. -
You like working independently, or you avoid conflict
Management requires constant interaction with others, including handling disagreements and conflicts. If you thrive on independent work and find interpersonal conflicts draining or uncomfortable, you'll struggle in a management role. Managers need to be comfortable addressing issues head-on and mediating disputes within their team and across the organization. Remember, you're responsible and accountable for your team's impact. That means you need to maintain relationships inside and outside of the team so that you can get things done with speed and quality.
There's no shame in deciding that management isn't for you. Many organizations offer dual career tracks that allow ICs to advance and increase their impact without ever moving into management. The key is to choose the path that aligns with your strengths, values, and long-term career goals.
You can prepare yourself before making the decision by trying to get a taste of management responsibilities in your current role. This could involve mentoring junior team members, leading a project, or shadowing a manager you admire. These experiences can give you valuable insights into whether a management role is the right fit for you.
Ultimately, the best managers genuinely want to be in that role, not those who see it as the only way to advance. Whether you choose to become a manager or to excel as an IC, the most important thing is to find a path that allows you to do your best work.
Things to Explore
This month, I'm looking at this Ruby script by CJ Avilla that can record and transcribe meetings and summarize them. Many tools do this, but it's nice to see a script showing how to combine local tools with an OpenAI API request.
You can find the script at https://github.com/cjavdev/meeting_transcriber/tree/main.
Parting Thoughts
Here are a couple of prompts for you to consider for the next month:
- Can you think of some times when you've accidentally changed something that was out of scope for the issue you're fixing, and
git add -pwould have helped? What did you use instead? - Think about the most effective manager you've had. How do you think they do when it comes to trusting people, building relationships, and nurturing the team?
- Now think about that manager you've had that wasn't ready to lead. How did they act?
Thanks for reading this month's issue.
I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!
Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.