3

I want to ask if the following workflow is correct! It is referring to a small private team. There is a master branch where no one merges there ( except the maintainer ), a development branch and individual branches for every user. So,every user will push to development branch.

So:

* clone the repo to your local machine
  git clone https://github.com/username/project.git

* cd project

* git remote add upstream https://github.com/group/project.git

* git checkout userbranch 
* git add files
  git commit -m ".."

* git push origin userbranch ( I am not sure if this step is necessary since I 

* Merge into development and push your work to development
  git checkout development
  git merge --no-ff userbranch
  git push origin development

* Update local master to apply changes from master to the local  repository.
  git checkout userbranch  ( or checkout local master? )
  git fetch upstream
  git merge upstream/development

* git push origin development

I am not sure if all the sequence is right (I don't want to make any mistakes!). Also, I am not sure about the steps where I say Update local master to apply changes from master to the local repository and Merge into development and push your work to development if they work as expected.

And at the last step do I have to checkout on my branch or my local master?

And finally , (if the above is correct ) at which point do I fetch and merge from master branch?Generally,how can I combine master and development branches?

migrated from stackoverflow.com May 3 '16 at 10:30

This question came from our site for professional and enthusiast programmers.

3

Your question should involve description of your delivery and development process, and then you could decide which branches you need to maintain.

I assume a classical set-up. You have a main development branch - where everything is developed by default, and a release branch, which is what you are preparing to publish as a release to customers.

For a default development branch is better to use master branch, as it is default branch, so developers could work on it straight away. For releases create a branch release. The workflow for a developer is following:

  1. git clone https://github.com/username/project.git

  2. cd project

  3. git add files/git commit

  4. git pull, git push

  5. go to 3.

For a release manager during release:

  1. git checkout release

  2. git merge master

  3. git tag v1.2.3.4

  4. git push && git push --tags

"Userbranches" will be local branches in dev's clones (or in forks), so usually you don't need to do anything special about it, no special names. It's easier when branch names match.

This is the very basic scenario, if you need some more options, e.g. doing hotfixes or feature branches, you could build all of it on top of this base.

If you need a code-review (only a designated person could merge code from devs into master), then you need forks. The forks in github are for pull-requests. So, user pushes his work into a fork and sends a pull request to the designated person.

  • :Thanks for the answer but I was hoping for someone to use my approach and correct me and answer to my questions. – George May 3 '16 at 23:13
  • @George "Your question should involve description of your delivery and development process, and then you could decide which branches you need to maintain." :) – Tim Malone May 4 '16 at 7:43
  • @George If you not sure what exactly do you need, just start with the base I described and then ask questions how to solve particular issues if you have any. Your approach could be correct (there are dozens correct workflows!), but looks overcomplicated for "a small private team". – kan May 4 '16 at 8:53
  • As I said , everyuser will develop on his own branch.Then every user pushes changes to development branch and then ( maybe only one or two users or everyone (we haven't decided yet) ) pushes to master.So, I want to be able to push to development branch and to fetch and merge from development and from master branches.And I am not sure which comes first and if the steps I described are correct.Thank you. – George May 4 '16 at 9:41
  • @George In this case you could just follow github workflow. A "master" branch in a dev's fork is already dev's branch. Each dev could push into their fork's master. After the push, they should raise a pull request via github web-interface, so the main repo maintainer (i.e. project owner) will accept the pull requests merging the changes into main master branch. See here help.github.com/articles/fork-a-repo – kan May 4 '16 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.