| author |
|---|
Sotiris Papadopoulos |
The best resource to look for info is probably this book (don't worry, its' content is available for free):
https://git-scm.com/book/en/v2
What follows are some very basic stuff to get you started.
First things first! Create a directory for your project.
Then, assuming you are in this directory, run:
git init
But, it is important that you have created a project online too! So, go to your account, and add new project.
Some info are displayed! Use them!!! Most certainly you need to run:
git remote add origin git@<the_new_project_path>
Then, if you already have an ssh key for this git service run, e.g.:
ssh-add ~/.ssh/id_rsa_gitlab
Your password is required.
If you have not done any of this before, you can refer to: https://docs.gitlab.com/ee/ssh/
From this point on, most everyday stuff are easy!
Create a new file containing stuff that you want to upload to your project's repository or edit an exsiting file.
Then, add local files to your remote repository*:
git add <file1> <file2> ... (you may also add all files with git add .)
git commit -m "some info about the commited files"
git push origin main (could be "master" instead)
Alternatively, if you have only edited pre-exsting files, you can run:
git commit -am "some info about the commited files"
git push origin main (could be "master" instead)
If you want to delete them, use either:
git rm file1.txt
git commit -m "remove file1.txt"
git push origin main
or:
git rm --cached file1.txt
git commit -m "remove file1.txt"
git push origin main
The later option, keeps the local file (do you think you will need it the future???)
To undo a local commit first see the history of commits using:
git reflog
The, identify the commit code (first str of each entry) and use:
git revert <commit_code>
Retrieve remote changes in local repository^:
git pull origin main
*If collaborating with others, or working from multiplre PCs, it's probably a good idea to first pull from the remote repository, before applying any changes. This way you will avoid dealing with conflicts. Or, you can start using branches!
Branches allow you to work on ideas and changes on the existing code base without messing up what you have done so far. They are divergent, parallel histories of your repository that you can opt to adopt or discard when you are done with your tests.
To create a new branch:
git checkout -b <branch_name>
Apply whatever changes to your file(s)...
Push local branch to remote repo:
git commit -"blah blah blah"
git push origin <branch_name>
At this point you will be presented with some info on how to create a merge request online, should you need to do so. The message will look like this:
remote: To create a merge request for my-new-branch, visit:
remote: https://gitlab.example.com/my-group/my-project/merge_requests/new?merge_request%5Bsource_branch%5D=my-new-branch
To switch back to main branch*:
git checkout main
Simple merge of branches (first checkout to the branch the merge will be applied to; usually that's "main"):
git merge <branch_name>
If a branch is no longer useful, delete it (rempotely && locally):
git push origin --delete <branch_name>
git branch -d <branch_name>
Finally, to only merge specific files from a target branch to the current one:
git checkout <branch_name> <file_name_1> <file_name_2> ...
More generally use git checkout <branch_name> to navigate between branches.
However, when you do so you may need to use ** git stashes*.
Another option is to rebase a branch on top of another. Essentially, this takes all changes that were commited on one branch and replays them on the other.
git checkout <target_branch>
git rebase <source_branch>
If different changes have been already commited to the two branches you will have
to resolve them manually. Note that the files are parsed serially, therefore
sometimes the rebase command will not detect all possible conflicts from the
very first run.
Once all conflicts have been resolved you should continue the process like so:
git add <conflict_file_1> <conflict_file_2> ...
git rebase --continue
If you want to push the local changes on a remote server, first make sure that the two point to the same reference. If not, just perform a forcefull push.
Finally you can optionally fast-forward the source branch.
git checkout <source_branch>
git merge <target_branch>
To locally save changes of some files without committing or merging them run:
git stash
This should allow seamlessly switching between branches while a set of changes is not yet ready to be merged.
To aplly the changes saved in a stash, use:
git stash apply
To delete a local stash:
git stash drop
To apply and delete a stash in one go:
git stash pop
Tags mark important milestones in your code. They behave a bit like branches, in the sense that you can easily navigate between different versions of your code.
However, unlike branches, they only constitute snapshots of your project in specific time points, and are not meant to be used for testing out potential changes.
To create a new tag:
git tag -a <tag_name> -m <commit_message>
To push it:
git push origin <tag_name>
To delete a tag (rempotely && locally):
git push --delete origin <tag_name>
git tag -d <tag_name>
Still, it may so happen that you need to apply some changes and maintain the same tag. In this case the tag can be updated to the latest or any commit (optional) on the working branch:
git tag -f <tag_name> <commit_hash_code>
Then, a forcefull push is also required:
git push -f origin <tag_name>
A submodule acts kinda like a symbolic link or a desktop shorcut. It is a static pointer to another repository.
Changes in that repository will not be automatically reflected in the submodule. You will need to manually update it.
Add a submodule to your repository:
git submodule add https://<repo_adress>
Update a submodule:
cd <repo>/<submodule>
git checkout main
git pull
cd ..
or
cd <repo>
git submodule update --remote <submodule>
and then,
git commit -am "Message"