Git Flashcards
To Create a branch
git checkout -b feature/newLocalbranch origin /originBranch
.gitkeep
.gitkeep isn’t documented, because it’s not a feature of Git.
Git cannot add a completely empty directory. People who want to track empty directories in Git have created the convention of putting files called .gitkeep in these directories. The file could be called anything; Git assigns no special significance to this name.
There is a competing convention of adding a .gitignore file to the empty directories to get them tracked, but some people see this as confusing since the goal is to keep the empty directories, not ignore them; .gitignore is also used to list files that should be ignored by Git when looking for untracked files.
To create a new branch and push the changes
create your feature branch from origin/develop, it should have the angular changes
The Git commands for your reference:
git fetch -a (fetch all the remote branch changes to your local remotes)
git checkout -b feature/yourFeatureBranchname origin/develop (to create a new feature branch from origin/develop)
git branch –unset-upsteam origin/develop (to remove linking to origin/develop upstream branch )
git push –set-upstrem origin feature/yourFeatureBranchname (to set remote branch and push your changes to VSTS)
Git commands to merge from develop branch
Git commands to merge from develop branch , just for your reference:
git fetch -a (to get all the remote changes into your local remote)
git merge origin/develop (to merge your local branch with origin develop; Note: you might need to commit your local changes before merging)
git rm –cache
git rm –cache =If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our .gitignore file then use –cache:
- to unstage from the staging directory
- this also moves the file to untracked status ; it means it is removing the file from the directory
- but the file still exists in the Repostity (local commits)
- we need to commit to add the changes of deleted file in the staging of the repository into the local repo commits
git reset 7digitSHA
to go to previous commits
Creating an upstream branch and Push your branch to the remote repository
git push -u origin feature_branch_name
git fetch –prune
to delete the local remote branches that are deleted in VSTS
Untrack files already added to git repository based on .gitignore
Have gitignore chagnes first commited and pushed. Then work on removing the files
Do not do gitignore changes and removing files from remote simultaneously
Let’s say you have already added/committed some files to your git repository and you then add them to your .gitignore; these files will still be present in your repository index. This article we will see how to get rid of them.
Step 1: Commit all your changes
Before proceeding, make sure all your changes are committed, including your .gitignore file.
Step 2: Remove everything from the repository
To clear your repo, use:
git rm -r –cached .
rm is the remove command
-r will allow recursive removal
–cached will only remove files from the index. Your files will still be there.
The . indicates that all files will be untracked. You can untrack a specific file with git rm –cached foo.txt (thanks @amadeann).
The rm command can be unforgiving. If you wish to try what it does beforehand, add the -n or –dry-run flag to test things out.
Step 3: Re add everything git add . Step 4: Commit git commit -m ".gitignore fix" Your repository is clean :)
Push the changes to your remote to see the changes effective there as well.
http://www.codeblocq.com/2016/01/Untrack-files-already-added-to-git-repository-based-on-gitignore/
gitignore tutorial
https://www.atlassian.com/git/tutorials/saving-changes/gitignore
git add git commit git diff git stash .gitignore
Git sees every file in your working copy as one of three things:
tracked - a file which has been previously staged or committed;
untracked - a file which has not been staged or committed; or
ignored - a file which Git has been explicitly told to ignore.
Ignored files are usually build artifacts and machine generated files that can be derived from your repository source or should otherwise not be committed. Some common examples are:
dependency caches, such as the contents of /node_modules or /packages
compiled code, such as .o, .pyc, and .class files
build output directories, such as /bin, /out, or /target
files generated at runtime, such as .log, .lock, or .tmp
hidden system files, such as .DS_Store or Thumbs.db
personal IDE config files, such as .idea/workspace.xml
Ignored files are tracked in a special file named .gitignore that is checked in at the root of your repository. There is no explicit git ignore command: instead the .gitignore file must be edited and committed by hand when you have new files that you wish to ignore. .gitignore files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.
Ignoring files in Git Git ignore patterns Shared .gitignore files in your repository Personal Git ignore rules Global Git ignore rules Ignoring a previously committed file Committing an ignored file Stashing an ignored file Debugging .gitignore files Git ignore patterns .gitignore uses globbing patterns to match against file names. You can construct your patterns using various symbols:
Pattern Example matches Explanation* **/logs logs/debug.log logs/monday/foo.bar build/logs/debug.log You can prepend a pattern with a double asterisk to match directories anywhere in the repository. **/logs/debug.log logs/debug.log build/logs/debug.log but not logs/build/debug.log You can also use a double asterisk to match files based on their name and the name of their parent directory. *.log debug.log foo.log .log logs/debug.log An asterisk is a wildcard that matches zero or more characters. *.log !important.log debug.log trace.log but not important.log logs/important.log Prepending an exclamation mark to a pattern negates it. If a file matches a pattern, but also matches a negating pattern defined later in the file, it will not be ignored. *.log !important/*.log trace.* debug.log important/trace.log but not important/debug.log Patterns defined after a negating pattern will re-ignore any previously negated files. /debug.log debug.log but not logs/debug.log Prepending a slash matches files only in the repository root. debug.log debug.log logs/debug.log By default, patterns match files in any directory debug?.log debug0.log debugg.log but not debug10.log A question mark matches exactly one character. debug[0-9].log debug0.log debug1.log but not debug10.log Square brackets can also be used to match a single character from a specified range. debug[01].log debug0.log debug1.log but not debug2.log debug01.log Square brackets match a single character form the specified set. debug[!01].log debug2.log but not debug0.log debug1.log debug01.log An exclamation mark can be used to match any character except one from the specified set. debug[a-z].log debuga.log debugb.log but not debug1.log Ranges can be numeric or alphabetic. logs logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log If you don't append a slash, the pattern will match both files and the contents of directories with that name. In the example matches on the left, both directories and files named logs are ignored logs/ logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log Appending a slash indicates the pattern is a directory. The entire contents of any directory in the repository matching that name – including all of its files and subdirectories – will be ignored logs/ !logs/important.log logs/debug.log logs/important.log Wait a minute! Shouldn't logs/important.log be negated in the example on the left
Nope! Due to a performance-related quirk in Git, you can not negate a file that is ignored due to a pattern matching a directory
logs//debug.log logs/debug.log
logs/monday/debug.log
logs/monday/pm/debug.log A double asterisk matches zero or more directories.
logs/day/debug.log logs/monday/debug.log
logs/tuesday/debug.log
but not
logs/latest/debug.log Wildcards can be used in directory names as well.
logs/debug.log logs/debug.log
but not
debug.log
build/logs/debug.log Patterns specifying a file in a particular directory are relative to the repository root. (You can prepend a slash if you like, but it doesn’t do anything special.)
** these explanations assume your .gitignore file is in the top level directory of your repository, as is the convention. If your repository has multiple .gitignore files, simply mentally replace “repository root” with “directory containing the .gitignore file” (and consider unifying them, for the sanity of your team).
In addition to these characters, you can use # to include comments in your .gitignore file:
# ignore all logs *.log You can use \ to escape .gitignore pattern characters if you have files or directories containing them:
ignore the file literally named foo[01].txt
foo[01].txt
Shared .gitignore files in your repository
Git ignore rules are usually defined in a .gitignore file at the root of your repository. However, you can choose to define multiple .gitignore files in different directories in your repository. Each pattern in a particular .gitignore file is tested relative to the directory containing that file. However the convention, and simplest approach, is to define a single .gitignore file in the root. As your .gitignore file is checked in, it is versioned like any other file in your repository and shared with your teammates when you push. Typically you should only include patterns in .gitignore that will benefit other users of the repository.
Personal Git ignore rules
You can also define personal ignore patterns for a particular repository in a special file at .git/info/exclude. These are not versioned, and not distributed with your repository, so it’s an appropriate place to include patterns that will likely only benefit you. For example if you have a custom logging setup, or special development tools that produce files in your repository’s working directory, you could consider adding them to .git/info/exclude to prevent them from being accidentally committed to your repository.
Global Git ignore rules
In addition, you can define global Git ignore patterns for all repositories on your local system by setting the Git core.excludesFile property. You’ll have to create this file yourself. If you’re unsure where to put your global .gitignore file, your home directory isn’t a bad choice (and makes it easy to find later). Once you’ve created the file, you’ll need to configure its location with git config:
$ touch ~/.gitignore
$ git config –global core.excludesFile ~/.gitignore
You should be careful what patterns you choose to globally ignore, as different file types are relevant for different projects. Special operating system files (e.g. .DS_Store and thumbs.db) or temporary files created by some developer tools are typical candidates for ignoring globally.
Ignoring a previously committed file
If you want to ignore a file that you’ve committed in the past, you’ll need to delete the file from your repository and then add a .gitignore rule for it. Using the –cached option with git rm means that the file will be deleted from your repository, but will remain in your working directory as an ignored file.
$ echo debug.log»_space; .gitignore
$ git rm –cached debug.log
rm ‘debug.log’
$ git commit -m “Start ignoring debug.log”
You can omit the –cached option if you want to delete the file from both the repository and your local file system.
Committing an ignored file
It is possible to force an ignored file to be committed to the repository using the -f (or –force) option with git add:
$ cat .gitignore *.log $ git add -f debug.log $ git commit -m "Force adding debug.log" You might consider doing this if you have a general pattern (like *.log) defined, but you want to commit a specific file. However a better solution is to define an exception to the general rule:
$ echo !debug.log >> .gitignore $ cat .gitignore *.log !debug.log $ git add debug.log $ git commit -m "Adding debug.log" This approach is more obvious, and less confusing, for your teammates.
Stashing an ignored file
git stash is a powerful Git feature for temporarily shelving and reverting local changes, allowing you to re-apply them later on. As you’d expect, by default git stash ignores ignored files and only stashes changes to files that are tracked by Git. However, you can invoke git stash with the –all option to stash changes to ignored and untracked files as well.
Debugging .gitignore files
If you have complicated .gitignore patterns, or patterns spread over multiple .gitignore files, it can be difficult to track down why a particular file is being ignored. You can use the git check-ignore command with the -v (or –verbose) option to determine which pattern is causing a particular file to be ignored:
$ git check-ignore -v debug.log.gitignore:3:*.log debug.logThe output shows:
: :
You can pass multiple file names to git check-ignore if you like, and the names themselves don’t even have to correspond to files that exist in your repository.
Ready to learn Git?
gitignore vscode
add below lines to gitignore file:
#ignore all the .vscode files
.vscode/
-- commit the code and push to repo -- git rm -r "specifyfolderstucture/\vscode" --cache rm = to remove from remote -r = to remove whole folder --cache = to maintain the files locally with out tracking ------------- git commit the changes -- git push --set-upstream origin feature/yourbranch the gitignore takes into effect
Debugging .gitignore files
If you have complicated .gitignore patterns, or patterns spread over multiple .gitignore files, it can be difficult to track down why a particular file is being ignored. You can use the git check-ignore command with the -v (or –verbose) option to determine which pattern is causing a particular file to be ignored:
$ git check-ignore -v debug.log
.gitignore:3:*.log debug.log
The output shows:
: :
You can pass multiple file names to git check-ignore if you like, and the names themselves don't even have to correspond to files that exist in your repository. git check-ignore -v .vs .vscode output: .gitignore:35:.vs/ .vs .gitignore:360:.vscode/ .vscode
Personal Git ignore rules
.git/info/exclude
You can also define personal ignore patterns for a particular repository in a special file at .git/info/exclude. These are not versioned, and not distributed with your repository, so it’s an appropriate place to include patterns that will likely only benefit you. For example if you have a custom logging setup, or special development tools that produce files in your repository’s working directory, you could consider adding them to .git/info/exclude to prevent them from being accidentally committed to your repository.
git subject and git body
git commit -m “Title” -m “Description ……….”;
Build Expired and not able to complete the pull request to merge the changes
“Build Expired” is a feature of branch policies. Set a build expiration to make sure that updates to your protected branch don’t break changes in open pull requests.
Always require a new build
This option sets the build policy status in a pull request to “failed” when the protected branch is updated. You must re-queue a build to refresh the build status. This setting ensures that the changes in pull requests build successfully even as the protected branch changes. This option is best for teams that have important branches with a lower volume of changes. Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated.
Require a new build if older than … hours
This option expires the current policy status when the protected branch updates if the passing build is older than the threshold entered. This option is a compromise between always requiring a build when the protected branch updates and never requiring one. This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
Don’t require a new build
Updates to the protected branch do not change the policy status. This reduces the number of builds for your branch, but can cause problems when closing pull requests that haven’t been updated recently.
Where system, global and local Windows Git config files are saved
https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Where-system-global-and-local-Windows-Git-config-files-are-saved
One of the five basic Git commands beginners need to learn is git config, if for no other reason than they can perform a commit without the Git tool pestering them for a username and email address.
But the required git config command that sets up a username and email address typically employs a –global switch, which tends to have Git beginners start to ponder about alternate scopes and asking questions about where all of these Windows git configuration files are saved.
System, global and local Git config files
Git provides three different scopes for storing configuration data. Accordingly, when using the git config command, one of these three scopes can be specified:
Local
Global
System
The scopes are cascading, so system scope trumps global scope and local scope trumps global scope.
Names of Windows Git config files
Just to make life a bit more complicated, the Git configuration files all have different names. Furthermore, Windows Git config files are each stored in different locations.
The extensionless system Git config file is named gitconfig.
The global Git config file has no name, but is instead just an extension. The global Windows Git config file is named .gitconfig.
The local Windows Git configuration file is simply named config, and like the system Git config file, it has no extension.
Where are Git config files stored?
As for the location of these three Windows Git configuration files, here is where you’ll find them:
The system Git config file is found in the mingw32\etc folder of the Git installation.
The global Git configuration file is found in the root of the user’s local profile or home directory (C:\Users\git-user).
The local Git config file is stored inside the .git directory of the repository in which you are working.
Can’t find the global git config file .gitconfig?
Sometimes users go looking for the global git config file, .gitconfig, and can’t find it. That’s because Git doesn’t actually create it until it’s used for the first time. Even just asking Git to edit the file will force its creation, but until that happens, efforts to find the .gitconfig file will be fruitless.
A quick command to force the creation of the .gitconfig file follows:
/c/ global/windows git config files (master)
$ git config –edit –global
