git
git is an open-source version control system used for tracking changes in source code during software development. Git gives every developer a local copy of a project. After a developer has made his changes, they create a new commit and then push it to a central repository. Other developers can then pull that commit from the central repository into their local copy. Git makes branching (creating a separate line of development) and merging (combining changes from different branches) easy.
Installation
on Windows
Go to git-scm.com/download/win and click on Click here to download which will automatically download the latest (64bit) windows version
Double-click on the exe file when the download has finished to start the installation.
You will get asked a bunch of stuff. I usually keep the default settings but feel free to change the default values to fit your needs.
on Linux
If you are on a distribution (like Fedora or CentOS) that comes with dnf, then use this command:
For distributions (like Debian or Ubuntu) that come with apt, then use this command:
on macOS
If you have the Xcode command line tools installed on your machine, then you already have git.
You can check if it is already installed using this command:
If it is not yet installed, you can visit git-scm.com/download/mac to see all the options. My favorite way of installing git is via brew using the following command:
check what version is installed
Use the following command in your VSCode terminal (or favorite command line tool):
initialize git
To initialize a git project locally, you first need to use the following command:
I will use GitHub as the origin, but you could use any other Git cloud service, like GitLab.
Next, go to GitHub and create a new repository by clicking on the "+" icon on the left of your user avatar (in the top right section of the page), then select "new repository".
Then use the following command to add the origin to your local git setup:
If you are using the git credential manager and have multiple users, then you may want to set the default. To do so, add your DEFAULT_GIT_USER_NAME to the URL like this:
Choosing a Git Branching Strategy
There are a lot of different approaches when it comes to managing code using branches, some popular Git branching strategies are for example Git Flow, GitHub Flow, GitLab Flow, Trunk-based development and many more.
There is no right or wrong when choosing a Git branching strategy, the goal is NOT to use the most popular Git flow, the goal is to find and use the one that best suits your workflow. I recommend checking out the above links and familiarizing yourself with the different workflows, then try the one out that you (your team) think is best suited, and if it does not fit perfectly you can still adjust the rules and make your own Git flow 😉.
Also don't overthink it, you can still switch to another git flow later. Why not just start with a rather simple Git flow with only two branches. The main branch a second branch that you could name preview (some prefer to call it staging or testing). When you develop locally you do in the preview branch and then commit your code updates into the remote preview (on GitHub, Gitlab). If you have a CI/CD pipeline in place should trigger an automatic deployment. After testing the preview deployment you are ready to make a pull request (PR) to merge the code into the main branch, the main branch will then get deployed in production.
If you work with others on your blog project, to avoid having to deal with merge conflicts regularly, you might want to create a branch per feature (hence called feature branches) and use that branch for development, before merging your code into preview (and later into main)
Cloning a repository
To clone a repository first get the HTTPS web URL of the repository, and then use the following command:
If you are using the git credential manager and have multiple users, then you may want to set the default. To do so, add your DEFAULT_GIT_USER_NAME into the URL like this when cloning:
If you have already cloned the repository and want to add or change the default user, then use this command:
git status
To list the local files that differ from the ones in the remote repository and list files that are not tracked, use the following command:
switch to another branch
To switch to another branch, use the following command:
Or you can use the new git switch, like so:
shortcut to return to the previous branch
There is a shortcut to switch back to the previous branch:
Or using the new switch:
Stash your changes before switching
If you want to switch to another branch but have uncommitted changes, then either commit them or stash them away using this command:
Now, if you want to see the changes that are currently stashed, use this command:
Finally, to restore the files, use the following:
Create a new branch
To create a new branch (and stay on the current branch), use the following command:
To create a new branch and also switch to it, use the checkout command with the -b
option, like so:
Or use the new git switch with the -c
option, like so:
renaming a branch
rename a local branch
Renaming a local branch is easy if you haven't pushed the branch yet. Just use the following command in your terminal (command line tool):
Renaming a remote branch
To rename a remote branch (a remote branch that has already been pushed), first use the command from the previous chapter to rename it locally.
Then use the following command in your terminal (command line tool) to push it:
The -u
(alias for --set-upstream-to
) option tells the local branch to track changes from the remote branch.
Now, the branch with the new name is also available remotely, but git has copied the branch to rename the old one, meaning the old branch is still present remotely, you work alone on the project skip the next step but if you work with others don't delete the old branch just yet.
At this point, if you work with others on the project now is a good time to let everyone on the team know that you renamed the branch, as they might still have open commits. Tell them to execute the following commands so that they, too, switch to the new branch (those are the commands GitHub recommends after you rename a remote branch on GitHub):
First, they use checkout to switch to the old branch, then they rename their own local branch too, using branch -m command, then they fetch the origin to fetch the ref of all branches in origin, then they need to use the branch -u (which is an alias for set-upstream we used earlier) to tell the local branch to track the origin/NEW_BRANCH_NAME.
If it is the default branch that got renamed, also update origin/HEAD:
After the other members of your team have updated their local environment, too, then you can go ahead and delete the old branch using this command:
Update the list of remote branches (locally)
To update/refresh the list of remote branches locally, use this command:
Get an overview of all local and remote branches
To get an overview of all branches that exist remotely and locally, what local branches track remote branches, ... use this command:
Delete a local branch
Windows: git ignorecase configuration option
If you rename a file on Windows and only change the case, for example, you change a file with all small letters to camelCase, then that change will NOT trigger a commit
Usually, something like this will lead to the problem: you are developing on Windows, where filenames are case agnostic, so importing a file on Windows and using all small letters (filename.ext) for a filename uses camelCase (fileName.ext) will NOT cause an error in your local development environment. Everything will be fine until you deploy your code on your staging (testing) environment, where you will probably use a Linux-based operating system. On staging, your import will trigger a file not found error. So now you want to fix your error and update the filename to use only small letters, but after editing the fileName, you realize there is no commit waiting to be done
To tell git to also commit changes where only the case of the filename changed, you have 2 options:
Option 1: Using the config command
In your terminal, go to the root of your repository, then use the following command to change the ignorecase configuration for your current repository:
If you want to make that change for all repositories (globally), then add the --global flag to the command:
Option 2: Edit the configuration file (manually)
Edit the git config in your repository, change ignorecase from true to false, and then save the change