Question

I'm pretty new to Git. Right now I only have a master branch for a repository. I'm starting to collaborate with another individual and I'm very confused as to how I can make adjustments at the same time as this person. I'm using Tower so I don't really need to learn anything on the command line -- I'm really just looking for a process description.

My instinct is to each have our own branches that we're separately working on. Is this the right approach? Do we just merge these branches with our master once the work is completed?

Let's say this other person makes a change and commits it to the master branch while I've been working on something else in my branch -- how do I merge his work with my own?

Was it helpful?

Solution

If you both work on the same branch, and he pushes his changes, you won't be able to push your changes. But what you can do is to pull the changes into your local copy, which will merge your and his changes. If there are some conflicts, you will have to resolve them manually. You can then push the result of that merge, which will contain both sets of changes.

In general, it probably doesn't make sense to have one branch for you and one for him. What makes sense is to create “feature branches”. If you are working on feature A, create a branch for it. When you're done, merge it back to master. This allows you for example to make emergency bugfixes to master even while your feature is unfinished.

OTHER TIPS

One person has to push first, then if you try to push, you'll get an error, that there are some changes and pushing to the repo would overwrite those changes. If that happens, you need to fetch those changes and merge them into your work, then push to the repo and it should be accepted. Other people have to do the same.

You have to pull updates merging them with your changes ( possibly resolving conflicts ) before you can push your changes to the remote if it has diverged ( someone else has pushed ) from the last time you pulled.

This is not unique to Git, every VCS requires you to pull changes, deal with merging and conflicts before you can push to the central/remote repository.

There is nothing magically about this workflow.

The difference with a D(istributed)VCS like Git is that every repository is a remote and the idea of a central repository is a convention, unlike CVS or Subversion ( and others that are centralized ).

Git is just really good at dealing with merging in a very sophisticated way so it minimizes conflicts most of the time.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top