0

We've been using git for a couple of months now where only one developer is working per project. This has been great and I get the concept of topic branches, release branches the merging and push & pull to a remote server.

However, when we have more than one developer working on the same repository, I get very confused. I have error messages indicating that I really don't know what I'm doing...

So what do I try to achieve; The main developer is working on a repository or System A. He created a 'Version 2.0_Alpha' branch on which he is working locally and push regularly to our git server. The master is the current released version. I want to help him out and do a specific feature. I created a local branch 'Feature_15' based on the remote branch 'Version 2.0_Alpha'. I do my work, I commit to the local repository and my colleague keeps working on his local repository, but pushes also to the server.

When it is time for me to push my changes to the server, I was hoping that I could just push my 'Feature_15'. Then my colleague can keep working on his code, and when he is ready checkout what have done, if all OK, go back to his branch 'Version 2.0_Alpha' and merge in my 'Feature_15'.

But this does not work as git is determined to have my first pull the latest 'Version 2.0_Alpha', and then I get lost in my knowledge and understanding.

Can somebody let me know if I'm on the right thinking path but just missing some steps, or am I going about this the wrong way.

We're using the limited functionality git-gui, but when needed happy to use gitExt or the Git-batch.

Zombo
  • 1
  • 62
  • 391
  • 407
user2063073
  • 3
  • 2

3 Answers3

0

You probably created a local branch (Feature_15) that tracks a remote branch (Version 2.0_Alpha) while you need to create a new separate branch. If it's true then you are trying to push your local branch to the remote 'Version 2.0_Alpha' branch instead of creating a remote 'Feature_15' branch, which is wrong and doesn't work for you. See How do you stop tracking a remote branch in Git? on fixing that (note that you don't need to delete your local branch, just remove the tracking).

Community
  • 1
  • 1
wRAR
  • 25,009
  • 4
  • 84
  • 97
  • Thanks wRAR, I think you are correct. I thought I created a new branch OFF the remote Version 2.0_Alpha while, I probably instead created a tracking branch TO the remote Version 2.0_Alpha. So what I would have done is create a tracking branch to the remote Version 2.0_Alpha, then create a new branch from this being Feature_15. Then after the work is done, push feature_15 to remote. Is that the way to go? – user2063073 Feb 15 '13 at 06:08
0

Everything you are saying sounds good and correct (to me at least).

If you are getting some error, maybe you could show exactly what error you are getting.

A couple of things you can do also, check what branch you are on when you commit your files (it will show in the git status output). Check the history of commits, either use some GUI tool (I use gitk on Linux but there are plenty of others) or through the command line:

git log --graph --pretty=oneline --abbrev-commit --decorate=full --all

You can replace the --all at the end with a list of the branches you want to see, for example:

git log --graph --pretty=oneline --abbrev-commit --decorate=full origin/Version 2.0_Alpha origin/Feature_15

The only thing you have to handle with git is when you need to push changes to a branch where somebody already pushed something since you last pulled, but as long as you and your coworker work on separate branches, it should not be an issue.

Matthieu
  • 16,103
  • 10
  • 59
  • 86
-1

You start like this

A--B--C  Version 2.0_Alpha
       \
        X--Y--Z  Feature_15

Then he makes changes

A--B--C--D--E--F
       \
        X--Y--Z

You need to rebase your changes onto his HEAD so that he can do a clean merge

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

ref

Zombo
  • 1
  • 62
  • 391
  • 407
  • Rebasing is unnecessary and may (and will) cause confusion and data loss for inexperienced git users. The only advantage of rebasing is keeping the history linear which is not even an advantage for some people. – wRAR Feb 12 '13 at 00:59
  • @wRAR Firmly disagree. If this team does not learn to rebase they are in for a world of hurt. There are more advantages to rebasing than "keeping the history linear": merge commits suck and are hard to debug; you are forced to deal with conflicts at the appropriate point in the history; and interactive rebasing provides a bunch of great tools to help keep your history clean. – Josh Leitzel Feb 12 '13 at 01:11