91 lines
No EOL
6 KiB
Markdown
91 lines
No EOL
6 KiB
Markdown
---
|
||
id: 228a5a0a-eded-11ee-9840-8b8ae5e4b6f0
|
||
title: |
|
||
Let's Save the (Git) Trees
|
||
status: ARCHIVED
|
||
tags:
|
||
- read-later
|
||
- Newsletter
|
||
date_added: 2024-03-29 13:55:23
|
||
url_omnivore: |
|
||
https://omnivore.app/me/let-s-save-the-git-trees-18e8b23331a
|
||
url_original: |
|
||
https://omnivore.app/no_url?q=b542dc42-874d-446c-84a7-6c02bf819f29
|
||
---
|
||
|
||
# Let's Save the (Git) Trees
|
||
|
||
## Highlights
|
||
|
||
We start using something called **interactive rebase** on our feature branches. It’s really just a way to clean up our commit history before we merge it into the main branch. This might change the history, but since it’s just on our own feature branches, it doesn’t mess up anything for everyone else.
|
||
|
||
[source](https://omnivore.app/me/let-s-save-the-git-trees-18e8b23331a#0f14f09a-7965-46bd-bc32-d4eede7e821c)
|
||
|
||
---
|
||
|
||
Here’s a quick guide on how to do it:
|
||
|
||
1. **Start on Your Feature Branch:**`git checkout -b my-feature`
|
||
2. **Grab the Latest Main Branch Updates Without Switching:**`git fetch origin main:main` (using `main:main` is a trick to fetch remote main changes to the local copy without switching back and forth)
|
||
3. **Interactive Rebase Time:**`git rebase main --interactive` \- This lets us pick and choose which commits to keep or squash, change the commits you want to `s` to make sure git squashes them into the parent commit, while keeping the changes.
|
||
4. **Safely Update the Remote Branch:**`git push --force-with-lease` \- This flag makes sure we don’t accidentally overwrite anyone else’s work.
|
||
5. **Prepare to Merge:**`git checkout main`
|
||
6. **Merge Without Extra Commits:**`git merge --ff-only -` \- Keeps our history straight by avoiding merge commits.
|
||
7. **Push it Up:**`git push` \- And we’re done!
|
||
|
||
[source](https://omnivore.app/me/let-s-save-the-git-trees-18e8b23331a#abe6a553-9d96-4f41-aba2-73ad21e3e86a)
|
||
|
||
---
|
||
|
||
## Original
|
||
|
||
Hi friends,
|
||
|
||
You know how companies use merge commits when working on projects?
|
||
|
||
Just go to one of your work projects and checkout the history of the main branch. It may look tidy (or not) but it’s bad for the environment (the real-world one 😉)
|
||
|
||
|
||
|
||
Lots of merge commits
|
||
|
||
While that’s pretty standard, it actually makes things messy.
|
||
|
||
Every time we do this, it stops us from keeping our commit history nice and clean all the way through from development to production.
|
||
|
||
Here’s why that’s a bit of a problem: if we’ve already **built and tested** a commit, **installing dependencies** in the process and **storing** all its details, there’s really no need to go through all that again.
|
||
|
||
It’s like doing the same work twice, which wastes time and resources, which translate to environmental effects that compound and another financial waste if that’s not enough.
|
||
|
||
Plus, a cleaner git history makes it easier for us to figure out issues. It helps us use tools like `git bisect` much more effectively to find bugs. But we’ll talk more about that another time.
|
||
|
||
So, what’s the solution?
|
||
|
||
==We start using something called== **==interactive rebase==** ==on our feature branches. It’s really just a way to clean up our commit history before we merge it into the main branch. This might change the history, but since it’s just on our own feature branches, it doesn’t mess up anything for everyone else.==
|
||
|
||
|
||
|
||
Rebasing 3 commits into one with interactive rebase
|
||
|
||
==Here’s a quick guide on how to do it:==
|
||
|
||
1. **==Start on Your Feature Branch:==**`==git checkout -b== ==my====-feature==`
|
||
2. **==Grab the Latest Main Branch Updates Without Switching:==**`==git== ==fetch== ==origin== ==main====:main==` ==(using== `==main:====main==` ==is a trick to fetch remote main changes to the local copy without switching back and forth)==
|
||
3. **==Interactive Rebase Time:==**`==git rebase main== ==--interactive==` ==- This lets us pick and choose which commits to keep or squash, change the commits you want to== `==s==` ==to make sure git squashes them into the parent commit, while keeping the changes.==
|
||
4. **==Safely Update the Remote Branch:==**`==git push --====force====-====with====-lease==` ==- This flag makes sure we don’t accidentally overwrite anyone else’s work.==
|
||
5. **==Prepare to Merge:==**`==git checkout main==`
|
||
6. **==Merge Without Extra Commits:==**`==git== ==merge== ==--ff-====only== ==-==` ==- Keeps our history straight by avoiding merge commits.==
|
||
7. **==Push it Up:==**`==git== ==push==` ==- And we’re done!==
|
||
|
||
By making this part of what we do every day, our git trees will stay clean and easy to work with.
|
||
|
||
Hope you find this helpful! Always happy to hear your thoughts or answer any questions.
|
||
|
||
Enjoy your weekend!
|
||
|
||
_**Whenever you’re ready, here’s how I can help you**_
|
||
|
||
* [Follow me on X / Twitter](https://click.convertkit-mail2.com/qduo9vo0l2f7h7pwe7eulhnpxowkk/wnh2hghw84rpw8h7/aHR0cHM6Ly90d2l0dGVyLmNvbS9kZXZvcHN0b29sYm94) for the occasional tips and tricks on better workflows
|
||
* [Building a Second Brain with Neovim in Under 90 Minutes ](https://click.convertkit-mail2.com/qduo9vo0l2f7h7pwe7eulhnpxowkk/reh8hoh0n7qr0ka2/aHR0cHM6Ly9sZWFybi5vbWVyeHguY29tL2NvdXJzZXMvc2Vjb25kLWJyYWluLW5lb3ZpbQ==)My first course, discussing the basics of building a second brain using the PARA and CODE methods, combined with Obsidian and Neovim as an editor. Join 200+ enrolled students here
|
||
|
||
[](https://click.convertkit-mail2.com/qduo9vo0l2f7h7pwe7eulhnpxowkk/08hwh9hdqxm5dvul/aHR0cHM6Ly9jb252ZXJ0a2l0LmNvbS9mZWF0dXJlcy9lbWFpbC1tYXJrZXRpbmc%5FdXRtX2NhbXBhaWduPXBvd2VyZWRieSZ1dG1fY29udGVudD1lbWFpbCZ1dG1fbWVkaXVtPXJlZmVycmFsJnV0bV9zb3VyY2U9ZHluYW1pYw==) |