top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to deal with concurrent changes in a project when using GIT

+1 vote
527 views

I'm having difficulty understanding how I should use git when I have multiple independent changes in a project. I have a local git repository for various windows & linux machines and I work on different parts of the project on different machines. The situation I have is that I am part way through some changes on one part of the project. On the same machine, I have made some quick changes to another part of the project and I would like to commit those changes and push them to the origin, _without_ having to commit the other changes that I am still working on. Surprisingly, I don't seem to be able to do this with git.

  • I can commit the completed changes without committing the uncompleted changes ok.
  • If I try to push the changes, git complains that I have unstaged changes and I should do a local merge.
  • I can't even seem do a local merge without pulling other changes from the origin.

So now I've ended up with part-finished changes on the master. Not what I wanted! What should I be doing here?

posted Jul 2, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

0 votes

Do I get it right, and you have only two repos, one on the linux and one on the windows machine, and you dont use an intermittent repository, like a git server, Gitorious or Github? If so, you MUST commit or stash your changes in "origin", before pushing your changes there. Or, you may set up the other repository as a remote on "origin", and pull from there (maybe with rebase).

answer Jul 2, 2013 by anonymous
0 votes

What I would do is this. First, I would do a "git stash".

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

The modifications stashed away by this command can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash apply. Calling git stash without any arguments is equivalent to git stash save. A stash is by default listed as "WIP on branchname …", but you can give a more descriptive message on the command line when you create one.

The latest stash you created is stored in refs/stash; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. stash@{0} is the most recently created stash, stash@{1} is the one before it, stash@{2.hours.ago} is also possible).

Do a "git status" to find out what is staged to be committed (i.e. is in the index). For each program which is staged in the index which you don't want (a "git add" has been done but not yet committed), do a "git reset HEAD file" to remove the changed, but not committed, file from the index. This does not affect the contents of the file in the working directory (it goes to untracked). When a "git status" shows only the files what you want to commit in the section with the heading: "Changes to be committed:", you can do the "git commit"
followed by a "git push". To get back to where you were, do a "git stash pop".

answer Jul 2, 2013 by anonymous
Similar Questions
+1 vote

Perhaps my git workflow is wrong.

I have committed numerous times in order to complete a task, but when the code is to be reviewed, Id like to show a non-contiguous view of my changes, which do not include the commits other developers have made. Is this possible?

Or should I be creating a branch and showing the differences from the master and my branch when it comes to a code review?

+2 votes

One practice of using git to have one feature per branch.

Let's say a developer has worked on many small features in many branches. Then he sends one pull request to the central (not controlled by him) for each feature he has developed. While he is waiting for all the features be merged into the central repository, he needs to use all these feature locally.

To do so, he may need to merge the changes in these branches to his local master branch. But this can be tedious when he has many branches.

Is there a way to somehow setup a branch so whenever something is committed to the branch, the changes will also be simultaneously committed to the local master branch? By this way, the develop can avoid having to merge changes from many branches.

0 votes

I want to work on a visualization program for git. I was hoping there was a library that would allow me to monitor a git repo for changes. Consider it like inotify, but for a git repository (in fact, I think it would probably have inotify under the hood).

This hypothetical library would trigger an event any time the repository was modified, i.e. any time the graph that represents history was changed.

Is there such a library? If not, is there a better way to monitor the repository so that I wouldn't need to write it myself? Would anyone else be interested if I wrote it myself?

...