Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git basic workflow [duplicate]

Tags:

git

push

Possible Duplicate:
git push error '[remote rejected] master -> master (branch is currently checked out)'

I am new to Git and trying to use it for a local grails project.
The steps I followed:

  1. create the grails project
  2. go to the project directory and git init
  3. Add all the files in the project in staging area and commit.
  4. The git status at the repo gives the below message

    BXX@BXX-PC /c/Work/Grails/projects/yyy/tables (master) $ git status # On branch master nothing to commit (working directory clean) 
  5. Trying to keep it as the master branch, make the changes by cloning the repo, and later push the changes back. For that

  6. In my IDE, checkout the project (IntelliJ).This actually clone the project to another dir.
  7. Make the changes and commit the project
  8. Push the local changes to master.

    15:41:56.249: git push -v origin master Pushing to c:/Work/Grails/projects/xxx/tables remote: error: refusing to update checked out branch: refs/heads/master         remote: error: By default, updating the current branch in a non-bare repository         remote: error: is denied, because it will make the index and work tree inconsistent         remote: error: with what you pushed, and will require 'git reset --hard' to match         remote: error: the work tree to HEAD.  

The cloned repo status is

$ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean) 

Please help me with understanding this. Is there a better workflow to follow. I may be able to initialize the repo through Intellij, and try to work on the main branch. Still not sure what is wrong above.

thank you.

like image 381
bsr Avatar asked Apr 19 '10 20:04

bsr


People also ask

What is the basic workflow to track a file in git?

Git tracks file changes by the user creating a save point, or in Git terms a commit. Each commit takes a snapshot of the current file system rather than storing just the changes made since the last commit. This allows a commit ot be extracted and the whole history not required to rebuild the file system.

Which one is the best branching git workflow to follow?

Git Flow. The Git Flow is the most known workflow on this list. It was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime: master — this branch contains production code.

How is the git workflow?

A centralized Git workflow enables all team members to make changes directly to the main branch, with every change logged in a running history. A centralized workflow involves every contributor committing to the main branch without using any other branch.

What is the first step in git workflow?

The first step is to stage the changes to commit using the git add command. You can add multiple files at a single time, separating their name by space. The last step is to commit the changes using the git commit command.


2 Answers

The problem is that you're trying to push to a non-bare repo. A non-bare repo is one which has an associated working tree (that is, the files are actually checked out to disk). By default, Git won't let you push to a non-bare repo; pushing to a non-bare repo only updates Git's internal data structures, and does not alter the working tree (the files on disk), which means that if you then go back to the repo you pushed to and start working on the files, you'll be working on older copies of the files. Naturally this will cause problems when you try to commit your changes.

The best way to do this is to push to a bare repository, which is one created by passing the --bare flag to Git when creating the repo:

$ mkdir new_repo $ cd new_repo $ git --bare init 

Of course, the bare repo won't have any files checked out, so you can't actually work it in (you'll have to clone it first).

If you're just using a Git repo for local development (and not sharing or serving the Git repo), you don't have to have a remote repo to push to; you can work on a single copy of a local, non-bare repo.

like image 120
mipadi Avatar answered Oct 03 '22 20:10

mipadi


First of all, you do not need to clone your local repository. You can use branches to divide development in the same repository.

Git is a Distributed VCS, and if you have experience with Subversion or CVS before it, you need to change your mind.

Git is a very agile and you can use different workflows with it. Cloning repositories is more needed for a team work, not for local development (IMHO).

Branches is a good alternative for you.

See. Let's set master branch of your repository for a production-ready code. Let's create another branch for development:

$ git checkout -b development master 

Now you are working on the development branch.

You could use different branches for each feature you want to develop. It's very easy and helpful.

Let's imagine you want to implement some new feature, you need to create a new branch:

$ git checkout -b newfeature development 

Now you can work with your code, add files, commit and so on.

Next you need to merge your new developed feature to the development branch:

$ git add . $ git commit -m "My last changes for the new feature" $ git checkout development $ git merge newfeature 

Now your new code from the newfeature branch merged into the development branch.

For sometime in the future when you decide that your code in the development branch get some milestone, you could merge all the changes from development to master branch.

It's a very basic workflow, it can be helpful for the many branches.

My advise for you now: read more about git, branching, stashing (very-very-very helpful for quick fixes). And after some time you will get a great effort from using git.

Good luck.

like image 22
Sergey Kuznetsov Avatar answered Oct 03 '22 20:10

Sergey Kuznetsov