How to create git ignore file and what is the use of this gitignore file?
BY hariram.s
4 years ago
comments comment

Ignoring files:From time to time there are files you don't want git to track. There are a few methods of telling git what files to ignore. In which .gitignore file method is one of the popular method

    # Files to be ignored by Git

    # Ignore configuration files that may contain sensitive information.

    # Ignore paths that contain user-generated content.

This is a code written in one site where they mentioned the files which they want to ignore. Here they mentioned settings.php and the user changing files which is not needed to add in the git repository since it is a changeable

If you create a file in your repository named .gitignore, git will use its rules when looking at files to commit. Note that git will not ignore a file that was already tracked before a rule was added to this file to ignore it. So once the repository is created you have to add the .gitignore file or else you have to remove the files which you added before you adding the gitignore file

This file can be committed into the repository, thus sharing the rule list with any other users that clone the repository. Sometimes an empty .gitignore file is used as a placeholder for an empty path



on 01st March 2012 / by Anto
So what is this whole article about? Good question!!! Well this one is on Git. And before you ask the obvious next question, let me assure you, Git is not another unwieldy acronym. It is just another meaningless name that arose from the mind of one ‘funny’ man - Linus Torvalds - the creator of Linux .For want of another "creative" name,he coined "Git",or ,so we presume... Well, a by-the-book answer to the previous question would be that Git is a Version Control System (or maybe better put, a Revision Control System). So that brings us to the whole question of what Version Control System is all about... No worries.Let me break it down for you.... To know what Version Control System means, you first need to know what is the scenario that we are trying to address here: Developers (serious ones - the ones who wrote, ate and slept volumes of code), from the beginning of time, always faced one issue with the ever-prevailing need for change of code.They always had to modify, add to existing code and keep a track of all these changes/additions. It was difficult. People started using different versioning mechanisms to denote a ‘state’ of the code at a particular instance of time. They started naming the versions using numbers such as 1.0, 2.0, … or using timestamps (a numeric representation of time and date at a particular instance) such as 20111230.1830, and so on. People manually maintained separate copies of each version of code. They just had to remember the versions names to find which code folder contained the required version of code. This was all well and good when the number of versions were very few. But as the volume and complexity of the code grew, even this would become difficult. When the number of changes became too many, the number of versions became too many. They had to keep a track of all these versions, and this became even more complex, requiring yet another system for tracking and controlling versions. Even more complicated was the requirements that rose up when multiple people started working on the same piece of code. Collaboration was necessary to complete big projects. And if not done right, collaboration could be a nightmare! There had to be a system that could handle all this. This was the scenario that gave birth to Version/Revision Control Systems. We shall see more about these version control systems in Part II of our series on Git. Web Development Drupal Git Version Control System Leave a reply Your email address will not be published. Required fields are marker *

on 01st June 2012 / by sujith.s
When a server is managed by more than one admin, it’s always a challenge to keep track of the changes made to the configuration. And when in a multiserver environment managed by more than one admin, this is going to be more complex. It would have been much saner if there was a utility to handle all this. The ones that we found were quite complicated and was made for handling huge numbers. All we wanted was a very simple utility to do just the job, without much bells and whistles. And so, we started out on our own. Here’s what we have now. We were using the Git for our Drupal code base version controlling. We thought the same could be made use of for system configuration file versioning. We created a bash script that did just that and scheduled it to execute once every hour. The script compares configuration files with the ones we have in the git repo, and if changes are found, it copies them to a directory called conf and adds the changes to git. It reads the details of files to be tracked from a configuration file kept for the same. Cron was used for scheduling jobs. The script can run both as root as well as any normal user. If the script finds any difference it sends out an email to the recipient address stored in the script. The script requires that you have a git server and that you have already created a repo for the same. Here is the script (you might have to modify the email, hostname variables):. You can also follow this at #!/bin/bash DEBUG=0 LOG_FILE="log.txt" email_to_address="" email_cc_address="" # Debug function function db { if [ $DEBUG -eq 1 ]; then echo "$1" fi } # Log function function log { # If there are parameters read from parameters if [ $# -gt 0 ]; then echo "[$(date +"%D %T")] $@" >> $LOG_FILE db "$@" else # If there are no parameters read from stdin while read data do echo "[$(date +"%D %T")] $data" >> $LOG_FILE db "$data" done fi } # Change to the dir this script resides in script_path=`readlink -f $0` script_dir=`dirname "$script_path"` cd "$script_dir" # Run copy operations if run as root if [ $(id -u) -eq 0 ]; then db "Running copy operations" # Copy files to the conf folder while read path do # Ignore comments and empty lines echo "$path" | egrep '(^\s*#)|(^\s*$)' >/dev/null 2>&1 && continue db "$path read from the file" source="$path" destination="./conf/`hostname`$path" if [ -f "$source" ]; then # If file then copy param='-f' elif [ -d $source ]; then # If folder then deep copy param='-fR' destination="`dirname \"$destination\"`" # Create the destination folder if it does not exist if [ ! -d "$destination" ]; then log "$destination does not exist. Creating dir" mkdir -p "$destination" fi else log "$path: Illegal path found." # Continue on to the next path continue fi db "Copying $source to $destination" (nice cp $param "$source" "$destination" 2>&1) | log done < ./`hostname`.conf db "Changing ownership of conf/`hostname` to metheuser" chown -R metheuser: metheuser "conf/`hostname`" # Run git operations if run as normaluser else db "Running git operations" # Run git diff to find changes file_diff=`git diff --no-prefix` diff_lines=$(($(echo -n "$file_diff" | wc -l))) # Run git status to check if untracked files are present git status|grep untracked > /dev/null if [ $? -eq 0 ]; then has_untracked=1 git_status=`git status` fi # If there is a difference if [[ $diff_lines -gt 0 || $has_untracked -eq 1 ]]; then log "$diff_lines line(s) of difference found" log "Has untracked = $has_untracked" # Get latest changes from other servers log "Pulling changes (if any) from server" (git pull 2>&1) | log # Commit the difference on the machine (git add -A 2>&1) | log (git commit -m "Adding changes from $(hostname)" 2>&1) | log (git push 2>&1) | log db $file_diff subject="[CONFIG-TRACK] `hostname` - Status Report - $(date)" git_differences="`echo -e "$file_diff\n$git_status"`" log "Sending differences via email" log "$git_differences" echo -e "$git_differences" | mail -s "$subject" -c $email_cc_address $email_to_address 2>&1 | log else db "No differences found" fi fi Linux System Administration Server Administration Git Version Control System Leave a reply Your email address will not be published. Required fields are marker * Anonymous (not verified) access_time 24 May 2019 - 13:41 Thanks it is exactly what I'm looking for. Add new comment

on 31st July 2012 / by Anoop John
If you own a VPS or a dedicated server or a hosting server which allows you to have shell access then you can easily set up your own git server with as many users and as many repositories as can be stored in the space on your server. All you need to do this is a bit of system administration skills and a hosting server that allows you shell access. Read on to see how you can set up your own git server. The server software that will allow you to do this is gitolite. Another alternative is gitosis but the capabilities offered by gitolite is way ahead of gitosis. The main advantage of gitolite over gitosis is the ability to control user permissions on a branch basis in each repository. This is very critical to enforce git based development workflows. The installation of gitolite is very simple. git clone git:// gitolite/install You can then create a symlink to the gitolite script to one of the paths in your $PATH variable. Now copy over your public key from your local machine to a file on the server and run gitolite setup -pk This will create the gitolite admin repository and set you as the administrator. Now all you have to do is to clone the admin repo on the machine from where you took your public key from and then make changes in the gitolite.conf to create repositories and set permissions to people work on the repositories or the branches in these repositories. More documentation on gitolite can be found at the gitolite project site. If you don't already have a VPS or a shared server we would recommend one of the following providers for your VPS / Dedicated server needs - Linode, WiredTree or Innohosting. We have hosted with all of these and have been pretty satisfied with the services of these providers. Linux Server Administration Git Version Control System Leave a reply Your email address will not be published. Required fields are marker *
Leave a reply
Your email address will not be published. Required fields are marker *

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type='1 A I'> <li> <dl> <dt> <dd> <h2 id='jump-*'> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
The content of this field is kept private and will not be shown publicly.
CAPTCHA This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.