Git is a popular version control system made by Linus Torvalds.
choco install git --params "/WindowsTerminalProfile"
# PPA for the latest stable version. sudo add-apt-repository ppa:git-core/ppa sudo apt update sudo apt install git git-lfs
# Clone or download a repository git clone <url> [<foldername>] # cd into the cloned folder cd <foldername> # Note that some repos have submodules which will also need to be cloned git submodule update --init --recursive # Stage your changes git add <my files> # Or stage all files # git add . # Make a commit git commit -m "My commit message" # Push your changes to the repository git push # Pull the latest changes from the repository # Equivalent to git fetch && git merge FETCH_HEAD git pull
Branches allow you to work on the repository without creating new forks and using more disk space.
You can use them to create and test changes from a static copy of the code repo.
You can also discard a branch if you decide the feature is no longer needed.
Once the feature has been fully developed, you should rebase the branch onto the head of the main branch.
Then you can merge the branch to add the feature to main/master.
# Make a branch git checkout -b my_feature # Add and commit to this branch git add . git commit -m "My commit message" # Push git push --set-upstream origin my_feature # Checkout a branch git checkout my_branch # Checkout a single file from another branch git checkout my_branch -- other_file.txt
Patches are a way to represent and share changes without actually making commits or new branches.
# For unstaged changes git diff > changes.patch # For staged changes git diff --cached > changes.patch # You can also add --binary to include binary files # Apply the patch git apply changes.patch
See create git patch
Pull requests are a way to submit changes to repositories you do not manage.
First, you fork the repository to create a working-copy for yourself to develop on.
Once your changes are finished, you create a pull request asking the original repo to incorporate your changes.
It's easiest to just use the web interfaces of GitHub or GitLab for this.
To do this manually, see Git Book: Contributing to a project.
How to migrate repositories to another Git server
git clone --mirror <original_repo> cd <repo> # Run the following lines only if you're using lfs git lfs fetch --all git lfs push --all <new_repo> git push --all <new_repo>
Changing Remote URL
You will need to change the remote url if it is changed on the server. E.g. if you change the project name.
git remote set-url origin <new-url>
.gitignore is used to ignore certain files to make sure they do not get accidentally pushed to the remote git repo.
You can find a collection of .gitignore files on Github's gitignore repo.
Or you can create a custom .gitignore file at gitignore.io.
.gitattributes are used to give attributes to paths.
They can be used to assign programming languages to filenames.
They are also used to identify which files should be stored in the lfs.
Here is an example to store video and images in the lfs.
git clean to delete untracked files.
-x to also delete gitignore'd files.
# Force delete any untracked files and directories git clean -fd
Git Large File Storage (LFS)
- Note that Github charges for LFS so it's best to keep binary files outside of GitHub.
If you're interacting with a monorepo like google-research/google-research, you may be interested in git sparse checkout.
See Git - git-sparse-checkout Documentation and Bring your monorepo down to size with sparse-checkout | The GitHub Blog.
This is a relatively new feature so be sure to use an updated version of git.
git clone --no-checkout $url cd $project git sparse-checkout init git sparse-checkout add $folder