2

I'm new to Git and am trying to understand the basic workflow when working with other developers.

We have a remote development branch that the developers push to.

  1. Fresh pull of development remote branch to get new updates...

    git pull origin development

  2. Do a bunch of work in my development local branch

  3. Add and commit new work that I just did

    git add . git commit -m "completed x"

  4. Push changes to the development remote branch

    git push origin development

I'm wondering if there is a much more optimized and better way of doing this? Note that I'm only working with one or two other developers.

Improve this question
2
  • So what exactly do you mean by a "more optimized" and "better" way to implement your workflow? Commented May 9, 2014 at 20:46
  • I just want to say I'm sorry for my rather rude earlier responses. Commented May 13, 2014 at 2:19

4 Answers 4

Reset to default
3

No, there is no more "optimal" way to do this (I'm guessing you mean fewest steps?). What you've outlined above is the minimum number of required steps necessary for a typical git workflow.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

Assuming you're talking about working with a group and having some kind of development-release-deploy process, here's a good overview of two common workflows: Git Workflows For Successful Deployment.

I use the "git flow" pattern with my current team. The article discusses some of the pro's and con's.

Improve this answer

Comments

0

Working on your own feature branch and later merging the same with the main development branch is in my opinion a far better way to work. If you have main development branch, you can create a branch on top of it and push your changes.

For example, if I have a branch "master", and If I am working on a new feature Feature_A

I would do something like this.

git checkout -b feature_a

(The above command is given while I am on master branch)

I will make my changes and push the "feature_a" branch.

git push origin feature_a

Now when my feature is completed, my colleague managing the "master" branch would merge my branch into it.

git merge feature_a

(The above command is given while he is on master branch)

Even if you are working with a couple of other developers, it is always better to work on your own branches and merge the same after testing a feature completely. This will keep your releases more clean and organized.

Improve this answer

Comments

0 
# fetch everything from remote but don't modify anything local git fetch # checkout the development branch; # this will automatically track the remote branch git checkout development # do some work and commit it git commit -m 'whatever' # fetch changes and rebase the development branch against the remote changes git pull --rebase # push changes # (all branches by default but can be changed to just current branch) git push # continue to pull --rebase, commit, and push

There are some variations on this but you should consider rebasing against remote commits before pushing your local changes to remote. More mature OSS projects will generally insist on this and it is good practice. You can make rebasing the default pull behavior (normally it merges).

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.