Git is by far the most used source control management tool out there.
It is basially an essential to know. And this justifies knowing a few of the most important git commands you need in your daily work.
Here are 19 that any developer should know.
A thread. ↓
1. Initialize a repository
git init is the most basic command.
It initializes a new repository in your current folder and starts the version control flow for your repository.
2. Clone a remote repository
You don't necessarily need to create a new repository.
Sometimes you just want to download an existing repository and contribute to it.
This is where git clone comes in.
3. Stage files for commit
Git requires you to actually tell it which directories and files you want under version control.
With git add, you tell git: "The next time I commit, take care of this file/directory."
4. Commit files
To create a new "version" of your repository, you need to commit your previously staged changes.
This creates a unique hash that you can always rewind your repository to.
git commit is how you do it.
5. Add a remote repository
If you have started with a local repository and now want to upload your code to a remote server, like GitHub or GitLab, you need to add a remote repository.
With git remote add ... you do exactly this.
6. Fetch remote changes
git fetch tells git to go to the default remote repository or to one you specified and download all changes you don't have in your local repository yet.
It doesn't merge those changes into your local branches.
7. Fetch and merges remote changes
git pull is like git fetch, but it also merges remote changes into your local branch directly.
8. Rebase your changes
git rebase like telling git:
"I actually want you to take my current work and replay all changes based on a branch or commit hash, I tell you."
git then replays all your changes, one by one, and applies them, pausing when it encounters conflicts.
9. Interactive rebase
Interactive rebasing (git rebase -i) is one of git's most powerful commands.
You can rearrange commits, squash them, and do much more black magic with it.
10. Reset your local branch
git reset --hard is one of the most used commands when you somehow hit a wall and want to start freshly from your latest commit.
It throws everything away that you haven't committed yet, and gives you a new chance.
11. Create a new local branch
git checkout -b or git switch -c is git's way of letting you create a new branch.
Imagine multiple copies of an image where you change different things on different copies. But they are still linked and can be merged.
12. Push a local branch to a remote repository
Git is a remote SCM. This means that you can upload your work to make it accessible for more developers and to keep it safer.
git push or git push -u is your way to tell git to upload your code.
13. Forcefully push local changes to a remote repository
When you push changes to a remote, but someone made changes that you currently don't have, a normal push fails.
This is where the parameters --force and --force-with-lease come in.
They let you overwrite the remote.
14. Switch your current branch
Git branches are great because you can switch between them whenever you like.
git checkout / git switch lets you effortlessly switch to another branch whenever you like to.
15. Stash your uncommitted changes
Sometimes, you don't want to commit your current work but need to switch to another branch.
This is where git stash comes in. It's like a stack where you place your current changes on top.
You can then recall them or throw them away later.
16. Rename a branch
Renaming a branch is a common operation. Sometimes CI/CD reacts to certain branch names, or you made a typo.
No matter the reason, git branch -m or the rename push are your friends for this use case.
17. Apply a commit from one branch to another one
Cherry-picking is the process of taking any commit and applying it to another branch that does not yet contain this commit.
Great, when you fixed a bug that you also want to include in your new release branch.
18. Show a commit log
Although many modern IDEs and editors have a graphical git view, git log is your way to show all commits in descending order, beginning from where you currently are.
Great if you want to get a quick overview.
19. Show a graph of your commit log
This command is a little advanced, and it makes sense to make an alias for it, but it turns the boring git log into an actual graph that shows branches, where they originate from, and which branch they were merged into.
20. Thread end
That's it for this thread. 💛
I hope you found something useful in it for you. 🙏🏻
If you enjoyed this thread, consider dropping a like, retweet the first tweet, and follow me (@oliverjumpertz) for more content like this.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
They are what you think but very often not what was really requested or expected.
By not asking questions, you put everything at risk.
This is a story of how assumptions nearly killed a multi-million dollar project.
A thread. ↓
0. Foreword
I can't tell you everything because this is a story that really happened.
I would break several laws and NDAs by giving you names and too many details.
Still, I will do my best to give you this as an example of why you should turn assumptions into knowledge.
1. The story
Some time ago, a medium-sized financial software company got a contract to develop a multi-million dollar wealth management system for a European private bank.
Wealth management systems are software systems that automatically manage your money.
I regularly get asked which language or framework someone should learn.
Here is my advice for aspiring software developers, asking themselves the same question, unsure what to learn to enter the industry, as someone who works as a tech lead in the industry.
A thread. ↓
1. You have two choices
You basically have two choices when deciding which language or framework you want to learn.
These choices are:
- Learn what's in demand
- Learn what you'd love to work with
Both choices bring advantages and drawbacks with them, and they will both extend and limit your opportunities.
But, it's also only a temporary choice. If you decide that you want to do something different later, you can still make the switch.
A super simple yet highly effective trick helps you increase your chances after tech interviews and keeps you a little safer:
The follow-up email.
A thread. ↓
1. What is a follow-up email?
A follow-up email is basically an email you send after a meeting.
You should usually send it within a day after that meeting.
This email gives you a chance to:
- Summarize what you understood or talked about
- Pick up points that were left undiscussed
- Give answers you promised to or couldn't deliver
- Ask additional questions
- Show overall more interest in the process
Did you know that there is a strategy that can make you 100% more likely to achieve your goals?
It is simple, yet highly effective, and it works for software developers learning how to code, for starters in business, and martekers alike.
A thread. ↓
1. Most people set goals
We all have dreams and goals.
- Learning how to code
- Earning a million dollars in a year
- Starting a highly successful business
- Finding our dream partner
- Closing a million-dollar deal
- Getting the promotion we deserve
There are so many goals out there that we couldn't count them all, even if we wanted to.
It's great to have goals because they are our drive. They make us leave our comfort zone and explore the unknown to reach them.