create a new directory, open it and perform a
git init
to create a new git repository.
git checkout repository
create a working copy of a local repository by running the command
git clone /path/to/repository
when using a remote server, your command will be
git clone username@host:/path/to/repository
in case you have submodules inside repo
git clone <REPO_URL>
cd <REPO_NAME>
git submodule init
git submodule update
your local repository consists of three “trees” maintained by git. the first one is your Working Directory which holds the actual files. the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you’ve made.
yay -S gitflow-avh
Setup a git repository for git flow usage. Can also be used to start a git repository.
git flow init -d
to initialize git-flow repo
Start new featrue,optionally basing it on <base> instaed of current branch
git flow feature start <FEATURE_NAME>
Publish feature branch <name> on origin.When <name> is omitted the current branch is used, but only if it’s a feature branch.
git flow feature publish <FEATURE_NAME>
You can propose changes (add it to the Index) using
git add <filename>
git add *
This is the first step in the basic git workflow. To actually commit these changes use
git commit -m "Commit message"
If you want to remove all files before pushing them to index use -n to perform dry-run or -f to remove them
git clean -n
# or
git clean -f
Now the file is committed to the HEAD, but not in your remote repository yet.
Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
git push origin master
Change master to whatever branch you want to push your changes to.
If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
git remote add origin <server>
Now you are able to push your changes to the selected remote server
Branches are used to develop features isolated from each other. The master branch is the “default” branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.
create a new branch named “feature_x” and switch to it using
git checkout -b feature_x
switch back to master
git checkout master
and delete the branch again
git branch -d feature_x
delete remote branch
git push origin --delete feature_x
a branch is not available to others unless you push the branch to your remote repository
git push origin <branch>
rename branch
git branch -m old_name new_name
delete remote branch
git push origin :<feature_x>
to update your local repository to the newest commit, execute
git pull
in your working directory to fetch and merge remote changes. to merge another branch into your active branch (e.g. master), use
git merge <branch>
in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
git add <filename>
before merging changes, you can also preview them by using
git diff <source_branch> <target_branch>
it’s recommended to create tags for software releases. this is a known concept, which also exists in SVN. You can create a new tag named 1.0.0 by executing
git tag 1.0.0 1b2e1d63ff
the 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the…
removing remote tag ‘TagName’
git push origin :refs/tags/TagName
or
git push --delete origin TagName
removing local tag ‘TagName’
git tag -d TagName
in its simplest form, you can study repository history using.. git log You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:
git log --author=bob
To see a very compressed log where each commit is one line:
git log --pretty=oneline
Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
git log --graph --oneline --decorate --all
See only which files have changed:
git log --name-status
See who commited some file
git blame <FILENAME>
These are just a few of the possible parameters you can use. For more, see git log –help
In case you did something wrong, which for sure never happens ;), you can replace local changes using the command
git checkout -- <filename>
this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.
If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
git fetch origin
git reset --hard origin/master
set HEAD to some commit
git reset --hard <commit>
push changes to remote branch git push origin <remote_branch> -f
git checkout <feature_branch>
pull changes from <destination_branch>,if master <destination_branch>
git pull origin master
remove ««,»» and ==== from conflict file
git add <filename>
git commit -m'commit message'
git push origin <feature_branch>
built-in git GUI
gitk
use colorful git output
git config color.ui true
show log on just one line per commit
git config format.pretty oneline
use interactive adding
git add -i
how all records when the tips of branches were updated locally
git reflog --all
stash commands
git stash save "something new" // Save stash with a save name
git stash list // Get list of stashes
git stash apply STASH-NAME ^{/someth} // You can use a regular expression to address that stash.Applies the changes leaves a copy in the stash
git stash pop STASH-NAME // applies the changes and removes the files from the stash
git log --diff-filter=A --numstat --pretty='COMMIT: %H %cd' -n 10
Configure ~/.ssh/config as
Host github-org
User git
Hostname github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/KEY
IdentitiesOnly yes
clone repo as
GIT_SSH_COMMAND="ssh -i ~/.ssh/KEY" git clone github-org:user/repo.git
GIT_TRACE_PACKET=true GIT_CURL_VERBOSE=true GIT_TRACE=true git push -v
https://stackoverflow.com/questions/20433867/git-ahead-behind-info-between-master-and-branch
Here’s a trick I found to compare two branches (any two) locally and show how much commits each branch is ahead of the other (a more general answer on your question 1):
git rev-list --left-right --count master...test-branch
From https://stackoverflow.com/questions/20433867/git-ahead-behind-info-between-master-and-branch
Structuring application code, application configuration and infrastructure in Git repositories is sometimes not the easiest thing to do, and there are not a single correct solution, instead it sometimes depends on how you want to work and what tools you use e.g. monorepo with monorepo tools or one repo per app.
The classic book Continuous Delivery touches on this topic. From my own experience working full time with this problem for a few years on a Kubernetes platform I can confirm that it helps to follow the structure from that book to some extend, but again it also depends on how you want to work. If you use Kubernetes, the 2nd edition of Kubernetes Up & Running has a new chapter 18 about how to structure code and manifests in repositories.
The Continuous Delivery book use a repository for application source code and a separate repository for application configuration. The repo for application configuration contains the environment specific configuration for the app, for each environment (e.g. test, staging and prod). When apps are deployed using some for of IaC e.g. Terraform or Kubernetes manifests, this lives in the repo for application configuration. If you are using Kubernetes, Kustomize with manifests and overlays for each environment is useful to use.
The reason to the separation of the source code and configuration here, as explained in the book, is that they have different lifecycles, e.g. they change at different points in a pipeline. An example, you typically don’t want to run all your integration test if you only want to change a value in the configuration repo, e.g. a feature-toogle or when you do rollback to a previously working version.
App Build Pipeline
App Deployment Pipeline
Infrastructure Pipeline
Above I have explained how custom developed applications is deployed using IaC. But there are also other kinds of infrastructure and IaC, like e.g. Kubernetes clusters, load balancers or Kafka clusters. These are typically pre-built software, where your responsibility mostly is about configuration. Pipelines for this kind of infrastructure are similar to App Deployment Pipeline but you may want to run tests and integration tests on Pull Requests to this repository. The book Infrastructure as Code: Dynamic Systems for the Cloud Age is good about this kind of systems, tests and pipelines.
Terraform Module Pipeline
If you use Terraform, it is common that you want to compose your own modules. This may perhaps be similar for AWS Cloud Formation Stacks. Changes to these modules should be tested in a pipeline and result in a unique version of the module using a git tag.
In the end, it all depends on how you want to work. Maybe you want to work with less process and PRs. Or maybe all your app soruce code is in a big monorepo, then you might want to work in a workflow and structure that fits with the tools you use.