Git workflow after commit
I have a local clone of a remote repository with master and branch1
.
master
was the last one until I did some work on branch1
which I did (remember, everything is local). after doing my job branch1
, i'm a little confused as to how to go about the next steps.
My thinking is to go to master
and do git merge branch1
and then push my local copy master
to the remote (my local is up to master
date with the remote master
). Is this correct or is there a better way to do it?
source to share
It all depends on your workflow . Do you have multiple developers working on a project or just you?
If you are the only developer working on a project, your proposal is fine. You submit locally, commit your changes, merge, push.
Another approach is to create remote branches, connect to the remote branch locally, and then merge (if you are using Stash, BitBucket, or some other remote hosting technology). The latter approach is good if you do co-op reviews or need to share your work with a team. You can also push to the remote branch to have a backup.
source to share
When I work on a project even solo, I try to keep myself from the master at work. Resist temptation.
Whether it's my own project or someone else, I cloned it by creating a new branch develop
and working there, not merging develop
into master
.
I also often create feature branches from develop
, and I do it in such a way that if I need to change something in the currently running code, I can hide my changes, switch to develop
, fix and merge that into master
and still be able to return to the function. which I was working on.
My feature branches never hit their original state. After the feature is merged into development, I will delete the feature branch.
If I am working on a branch develop
and I have a feature branch that I am working on, I usually rebase the feature branch on the branch develop
.
source to share
I usually use this workflow. Assuming the repository exists in the systems home directory with a name my_project
, navigate to it as follows:
cd ~/my_project
Once in this project, I check out branches:
git branch -a
This will be a list of all branches. You can skip this step if you know for sure that there are no other branches you want to deal with. Now make sure you are on this host:
git checkout master
Good good? Now, let's checkout the branch develop
like this:
git checkout -b develop
And now you will create and checkout a branch named at the same time develop
.
Now in development, do whatever you want. Take action as and when needed. Just do your thing.
Now, when it comes time to merge with master
checkout master
like this:
git checkout master
And while you're there, you have two options. You can do a standard merge like this:
git merge develop
So now master
will be merged with develop
. But at different times, I prefer to use the fast forward ( --no-ff
) option like this:
git merge --no-ff develop
This site explains this in detail , but the long and short is that with the help --no-ff
you basically place an additional commit in the merge that marks when that merge happened. The main advantage of this is that if something is spinning the line down and you need to investigate or roll back - what happened, the associated message is --no-ff
clearly visible and rolled back. Much easier than trying to decrypt the tons of commits that can occur in the repo.
--no-ff
becomes even more valuable as you work with others in a decentralized team. Everyone in the middle, using --no-ff
, is merging, all life becomes easier when dealing with communication problems.
However, I often do simple git merge develop
when I myself work on simple projects where I do a new setting once in a blue moon.
Git is, after all, a source control system, so how you handle commits mostly relies on your comfort level when dealing with problems that will need to be rolled back if and when they come.
source to share