Reputation: 10021
git workflow after commit
I have a local clone of a remote repository with master and branch1.
master was the latest until I did some work on branch1 that I committed (remember, all local). after committing my branch1 work, I’m kind of confused how to go about later steps.
My thinking is to switch to master, and do a git merge branch1, and then do a push of my local copy of master to remote (my local master is up to date with remote master). Is this correct or is there a better way to do this?
Upvotes: 2
Views: 180
Answers (4)
Reputation: 26066
I generally use this workflow. Assuming that a repo exists on your system’s home directory under the name my_project, go into it like this:
cd ~/my_project
Once in that project I do a check for branches:
git branch -a
That will list all branches. That step can be skipped if you know for sure there’s no other branches you want to deal with. Now, make sure you are on master like this:
git checkout master
Okay, good? Now let’s checkout a develop branch like this:
git checkout -b develop
And now you will simultaneously create and checkout a branch called develop.
Now in develop do whatever you want to do. Commit as appropriate and when appropriate. Just do your thing.
Now, when it comes time to merge with master checkout master like this:
git checkout master
And while in there, you now have two choices. You could do a standard merge like this:
git merge develop
So now master will be merged with develop. But man times I prefer to use the no fast forward (--no-ff) option like this:
git merge --no-ff develop
This site explains it in detail, but the long and short of it is that by using --no-ff you basically place an extra commit into the merge that marks when that merge happened. The main benefit of this is that if something screws up down the line and you need to investigate—or roll back—what happened, the --no-ff related commit is clear to spot and roll back to. Much easier than trying to decipher the tons of commits you might have in the repo.
The --no-ff becomes even more valuable as you work with others on a decentralized team. By everyone on the mean using --no-ff commits for merges, everyone’s life becomes easier when dealing with post-commit related issues.
That said, I often do the plain git merge develop when I am working on simple projects on my own where I make a new adjustment once in a blue moon.
Git is ultimately a source control management system, so how you handle commits basically rests on your comfort level in dealing with issues that will require rollback if/when the come along.
Upvotes: 3
Reputation:
When I am working on a project even solo I try to keep off of master for work. Resist the temptation.
Whether it is my own project or someone else's I have been cloning it, creating a new develop branch and working there and than merging develop into master.
I will also frequently create feature branches off of develop and I do this so that if I need to tweak something on the current running code, I can stash my changes, switch to develop, make the fix and merge that into master and still be able to go back to the feature I was working on.
My feature branches never get pushed to origin. Once the feature is merged into develop, I will delete the feature branch.
If I do work on the develop branch and have a feature branch I am working on, I will generally rebase my feature branch on the develop branch.
Upvotes: 3
Reputation: 7879
That is the correct way to merge changes from branch1 into your master branch. There is some good documentation on git merging here.
Upvotes: 1
Reputation: 37184
It all depends on your workflow. Do you have multiple devs working on the project or just you?
If you are the only developer working on the project, your suggestion is fine. You branch locally, perform your changes, merge, push.
Another approach is to create remote branches, push local to the remote branch, and then merge together (if you are using Stash, BitBucket, or some other remote hosting technology). The latter approach is nice if you are performing collaborative code reviews or need to share your work with a team. You can also push to the remote branch to have a backup.
Upvotes: 3