I am new to git. I know few basic things about git and I have quite successful in using it.
So I have a master, develop branch. From develop I have branched out to a feature branch and a release branch. For branching out from develop I used the following commands.
jgitflow feature-start from develop
jgitflow:release-start from develop
Now I am done with the feature and I want to merge into develop. I am doing this for the first time. Now I am confused as to how to do it. Ideally I should be using the below command:
jgitflow:feature-finish
The other option I believe is doing a pull request.
Please let me know which is the correct options and what happens if there are conflicts while using jgitflow:feature-finish
Pull Request is essential as it would get the changes reviewed. However, if you merge from the PR, you would still be able to run jgitflow:feature-finish, albeit it will result in keeping the remote branch (if pushed before).
Ideal way would be to
Raise PR for the feature, get it approved.
Run the feature-finish command to merge the changes to develop and clean up the local
and remote feature branch.
To resolve conflicts, it is always better to pull from develop locally instead of merging through feature-finish as it can get messy.
The details are available at https://bitbucket.org/atlassian/jgit-flow/wiki/goals/feature-finish
Use the necessary flags like keepBranch, squash based on your requirements.
You should also use featureRebase as true. This will rebase the feature branch before merging from the origin which is develop in your case. This will allow you to handle conflicts in a better way.
The easiest way to avoid conflict when trying to finish a feature is to adhere to the following workflow before executing finish-feature:
git fetch: make sure your local repo copy is up-to-date
git checkout develop: go to develop
git merge origin/develop: make sure your local develop is up-to-date (origin being the remote's name here)
git checkout <feature-branch>: go to you feature branch again
git merge develop: Merge and solve conflicts, if any (on you feature branch)
mvn jgitflow:feature-finish you already solved the conflicts, so this will work
I would not recommend the featureRebase option which was mentioned in another answer since you said you only know a few basic things about Git. Rebase can complicate things if you have pushed your local feature branch and other people are working on it.
Rebase is only safe to use on local branches since it changes the history.
Regarding pull requests, see Gitflow Workflow With Pull Requests on https://www.atlassian.com/git/tutorials/making-a-pull-request/how-it-works
Related
Pretty new to Git - been using TFS and simple commit/push/branching, so any help appreciated - have spent all day reading and running tests and beginning to think my requirement may not be possible.
There are two of us in the office; Dev 1 doing mostly compiled C# server code, and Dev 2 mostly exclusively web page related work. However, as there are only two of us we do need to cross over fairly regularly, particularly with client Javascript functionality.
We've been doing the "mate I'm working on foo.js" method of source control for client side code, and its worked for a while, but we are doing bigger projects and it's becoming a liability.
Our set up is as below, all on an internal network:
Dev 1's machine
Dev 2's machine
Local Windows Server running IIS that serves the websites under development
Shared drive pointing to the IIS root
So, and this is the rapid development cycle I'd like to try and keep, Dev 2 browses to the site under development edits the script / css / html files on the shared drive, hits F5, and the updates are immediately visible. This is a huge benefit for fast working with client side code.
The problems usually occur when Dev 1 needs to make a change to some scripted functionality that happens to require a style change, the same files are opened and saved by both devs, and one of the change sets is lost.
So I'd like to prevent this! However as far as I understand, Git requires the devs to have local repositories so changes can be done without affecting anyone else at all, and then conflicts are merged on commit?
I have set up a test repository on the local server and tried a few scenarios, but as I kind of expected, the scenario where both devs save the same open file is not tracked because neither set of changes has been committed, so as before, only the last set of changes is visible anywhere.
Is there any way of having these type of changes to the same physical file tracked? Or if not, a setup that does track them properly but at least maintains a rapid workflow as close as possible to the above?
Use branches.
Git has a very good branch system. Just create a branch for the work you do - you can even create a branch for every feature you want to implement. And when you "finished" the implementation, merge the branch back to master. So both - and more - developers can work based on a working master version and add there code to the common codebase if it works.
So, the workflow could look like this:
Dev1 and Dev2 clone the repo: git clone ....
Dev1 works on feature A: git checkout -b A (this creates a lokal branch A)
Dev2 works on feature B: git checkout -b B
Dev2 finishes his work: git push (on the first call you get a error message about the upstream, the errormessage contains exactly the line you need to create correct upstream, just copy it)
git checkout master; git pull back to master branch and pull
git merge B this merges B into master
Dev1 need longer for the job and wants to update to newest codebase:
git checkout master; git pull; git checkout A; git merge master branch A of Dev1 is now on new codebase.
If you have to work on different features at the same time, there exists also a good system in git. Based from master branch, create a new branch in its own folder - so that both branches are checked out at the same time and there is no need to git checkout <branch> to switch between them:
git worktree add -b <branch> <path>, like git worktree add -b A ../A
now you can switch to it trough filesystem (cd ../A) and work on both (or others you created the same way)
If you use github or gitlab, you can protect the master branch and create rules to make merges into it (called pull requests). With appveyor, travis-ci and others there exists services where you can let unittests run and give the pull request free it the unittests do not fail. Based on such a workflow, every developer can work on a running codebase.
About conflicts: With the workflow up there they do not happen as long as both versions didn't modify the same line. But you get a message at the (local) merge, and in the files it is good explained what you can do:
(we create a file with a b c in each line, in master we edit b to e, in our branch A we edit b to d, we commit both and merge master into A)
a
<<<<<<< HEAD
d
=======
e
>>>>>>> master
c
Ideally, you would:
isolate the common files in one separate Git repository
separate source control (the remote Git repository) from deployment (files copied on IIS root)
That way, each of you can:
push to a common remote bare repository: configure it to deny any non-fast-forward push. In case of concurrent pushes, you will be forced to pull first, resolve any conflict locally, then push back: there won't be any change overridden or lost that way.
setup a server-side hook in order to (on the server) pull from said bare repository, through a post-receive hook (example here).
reference that common repository in your own development repo through a Git submodule.
The goal is to keep separate:
project-specific development from common client Javascript functionality.
versionning from deployment.
The problems usually occur when Dev 1 needs to make a change to some scripted functionality that happens to require a style change, the same files are opened and saved by both devs, and one of the change sets is lost.
…
Is there any way of having these type of changes to the same physical file tracked?
To get this you need some sort of collaborative editor, that's out-of-scope for any existing vcs I know of.
Or if not, a setup that does track them properly but at least maintains a rapid workflow as close as possible to the above?
You need separate files, separate saves (i.e. a vcs) and a workflow that automates as much as possible of the pull-and-push publishing loop.
Since you're not working on the same physical files, before publishing you need to sync your changes with whatever the other guy(s) on your team have published since last you looked. Decide how you want your final history to look; for small-team work like this rebasing onto a shared linear history is often a great place to start, so git config pull.rebase true. Then when you're ready to publish the changes you've saved, commit, pull, push is your cycle; if you and your buddy are making changes even in the same file it'll still apply cleanly in one go so long as the changes aren't immediately-adjacent or overlapping.
I used git branch -d myBranch to delete a branch. However, when I am on master and try to checkout a new branch with git checkout, myBranch still appears in the tab-autocomplete.
How do I remove the name myBranch from tab-autocomplete for git checkout?
git fetch --prune --all
Posting this as its own answer since it's a one-line fix, but if you vote be sure to vote for twalberg's answer.
twalberg's suggestion to git branch -a led me on the right track; my coworker suggested git fetch --prune --all to prune all the dead branches from all the remotes, which is useful when working with lots of devs with lots of forks.
One possible reason for this is that, if a remote branch (e.g. origin/myBranch) still exists, then git checkout myBranch will succeed as an alternative to git checkout -b myBranch origin/myBranch. This is intended as a convenience for the common case of checkout out a remote branch for the first time, creating an identically named local tracking branch.
There are other possibilities, too, depending on what exactly you are using for completion, but that's one of the first things I'd check. If you run git branch -a, and there is an origin/myBranch listed (or one for a remote other than origin, if you have such), then that's a likely culprit.
Depending on your setup, there is another source of what might look like old or deleted branches - your git-completion may also be suggesting tags along with branches.
I was fooled by this recently - our CI/CD pipeline tags all our builds, and even though certain branches would be released and/or deleted years ago, the tags persisted. Cleaning up old tags on the remote was the solution here (there is a guide here).
(I answered this here as well - not sure if it counts as a duplicate as it's on StackExchange...?)
I'm in the process of convincing my team to move to using git for version control (from svn). The major hurdle seems to be convincing them that it's not going to be too complicated for others. To alleviate that, I'm attempting to create clear documentation. I need some help though with Eclipse/EGit, since I'm not as familiar with them. Coming from a Linux background, I always use git from the command line, but this is a Windows shop and asking IT to install git on everyone's machine will be seen as another layer of complexity.
So far the process for starting a new project is logging into the (linux) development server and creating a bare repository in the appropriate directory. The bare repository is (obviously) empty at this point -- so no master branch yet. This is where the question diverges from the others I've seen on SO, and most of the documentation I can find.
My question is what is the best way to clone that bare, empty repository into Eclipse and set it so that it knows to push to origin/master? I can clone it in the Git Repositories view though it seems unhappy that there's no branch. Then I can switch to the appropriate perspective I'm using for development, create the project, then import the git repo, add files, and finally commit and push and it will finally create the master branch. However this seems convoluted. Is there a more straightforward way to do this?
Thanks for the help!
I'm trying to get a feel for how to do certain things in TortoiseGit that are pretty intuitive in TortoiseHG.
TortoiseHG has the Workbench which basically is my central tool to sync the local repository with remote ones: upstreams and origin.
It is easy to see what changes I'm missing locally (so I need to fetch them) or remotely (so I need to push them).
What is similar functionality in TortoiseGit?
How can I see a list of changes from a remote origin or upstream that I want to fetch locally?
How can I see a list of changes locally that want to push to the origin or upstream?
Maybe TortoiseGit does not have those; if not: please suggest tools that do.
My answer doesn't directly apply to TortoiseGit, but im sure you will find the equivalent features easily.
Git is a distributed version control system. In order to see the remotes changes, you need to fetch them first:
git fetch
Then you can use git diff to view the differences between your current branch, or even your current (dirty) working directory.
Alternatively you may use git merge --dry-run to see what has to be merged.
To see the things you have changed but not commited (uncommited changes) just type git status.
SourceTree can do this: without the need to fetching, it shows I'm 1 change behind on the upstream remote.
After pulling it, it shows the origin remote is 2 changes behind on master.
my Hg repo now needs to include a Git submodule (Restkit) as per the advised method in the site wiki.
However, I am not updating the git contents and should only be potentially reading/pulling in changes from the host.
It appears that when I came to make my first push of my main Hg repo it baulked at the Git one asking for a password. I think this may be because its attempting to authenticate against the Git site as well.
My questions are can I arrange this so that the Git repo is read-only(pull) or even static and/or get round the log in issue. Obviously the two different repos have different credentials.
Thanks.
P.S. using Atlassian SourceTree 1.5.3 on OS X 10.8.2, Xcode 4.5.1
I've just re-read this;
2.6. Synchronizing in subrepositories
Subrepos don't automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update.
Thus, updating subrepos is a manual process. Simply run 'hg pull' and 'hg up' in the target subrepo, test in the top-level repo, then commit in the top-level repo to record the new combination. The onsub extension can be used to automate that.
Assume this means its not pulling the sub? but I still have the above issue of the password request.
You moved in the right direction, but not finished all required steps.
You have to have subrepository, create it by hand... and don't mix real subrepository with a) independent b) nested repository
When you'll convert nested to subrepo push into master repo will not perform push to subrepo (except it requested)