We have three developers working on a microsoft visual studio project that is being hosted on Github but we are using the VS Github extension tool.
We are a little confused about how many branches are necessary for our project.... This is what we have right now.
Master Branch -> Development Branch.
The idea that we are currently working with, is that we will each individually make changes, and then push up to the Development Branch to test with. When Coder 1 makes a change, Coder 2 and 3 will see the change and can merge their projects with the Dev branch and vice versa- so we stay in sync.... Then when we are comfortable with the changes, we merge Development Branch into Master Branch.
We are wondering if we need more branches, or if more branches would be userful....
For example what if we had:
Master Branch -> Development Branch -> Coder1 Branch, Coder2 Branch, Coder3 Branch.
Is there any benefit to adding more branches? We only have three coders and are wondering what the setup should look like.
Thanks!
With only three programmers, I believe everyone can work on the development branch at the same time as long as there's proper communication on what parts each are working on. Everyone can work on the development branch and when it's time to push their own changes, I advise:
git stash, which will put your changes into a temporary stash and revert back to HEAD, pretending like you did not change anything
git pull, which will pull the others' changes
git stash pop, which will bring back your own changes. This way, you can build "on top" of other people's changes. If there's a merge conflict, "local" will be the other person's changes and "remote" will be your own changes.
But if you really want to be safe and formal, separate branches for each person can work, and using GitHub's page, it's easy to implement a pull request and do code review.
All in all, it just depends on how formal you want it to be.
Related
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I am pretty new to Git and I am using sourcetree as a client.
I know that in Git two developers work on the same branch at a time since they have local copies of the remote branch.
So here is a scenario :
A and B are working on a branch feature/release1.0
A commits code to local branch.
Now B commits the code and pushes it to the remote branch as well.
Now A will have to push his changes as well as Pull changes made by B.
So what will A do in this case ?
In this case, A should pull B's changes down first, make sure everything works, commit, and push.
Generally we (my team) don't work quite like that.
When we have two developers working closely on a feature, we work on separate branches and merge into a shared feature branch.
Among the advantages of this is that you can commit and push on your own schedule, which means that you can make your code work without worrying about the other developer's changes and your code makes it to the server quicker. That is, it's somewhere other than your own machine, somewhere that's probably backed up.
A must git pull first (some merge may be needed) and than push the code.
If A try to push his code in the first place, git will tell that the remote and local branches have diverged and instruct the developer to pull the code first.
If you pay attention to git commit error messages (and git status messages) you will always know what to do.
As you said, A has to get the changes from B (git pull) before pushing her changes. It is likely she has to deal with some conflicts, which should be resolved locally before pushing the code.
Apart from that, you should probably reconsider your branch scheme to avoid this kind of conflicts. Would it be possible to work in different branches? For instance, by redefining the tasks, to be more fine-grained.
Moreover, it is weird, at least for me, the name or the branch feature/release-1.0. Looks like there are releases by features basis, os something like that. Take a look at http://nvie.com/posts/a-successful-git-branching-model/. See how the release branches are fed from the developing branch, and this one receives the commits from the features branches.
Hope it helps!
We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I'm relatively new to github (I've pushed my rails app to a repo and I push it up regularly to keep it updated, with a 'commit' message, which is very handy to see where I am) and I just want to check I'm about to do the next stage correctly, without messing it all up.
Some history: a few months ago a software development company sent me the source code of the project, which I tasked them to do. It's called Project_v_1. Over the months I've been making css/javascript/html changes - models and controllers not for me yet!
But I have done a substantial amount of work and, as I said, I update it regularly. Project_v_1 is the master branch (the only branch in the repo, in fact)
Now I'm about to receive Project_v_2 from the software company. I want to put the best of my changes I made to Project_v_1 into Project_v_2. Do I have to manually seek out the changes in the files I made and copy/paste them into P_v_2?
Or can I do something like:
create a new branch in my repo: P_v_2
put P_v_2 into that branch.
merge P_v_2 and my master (P_v_1).
Am I scr**ed? It just seems a bit miraculous to think there's a simple resolution to my problem.
Thanks,
C
git merge will merge every commit in v1 to v2. I suggest you to use cherry-pick which is useful to apply same commits between branches :
Checkout the v2 branch and git cherry-pick <your-best-commit-id>